Re: [boost] [fusion] matrix?

From: Andy Little (andy_at_[hidden])
Date: 2006-09-11 02:01:50

"Larry Evans" <cppljevans_at_[hidden]> wrote in message
news:ee26mm$bu7$1_at_sea.gmane.org...
> On 09/05/2006 08:36 AM, David Abrahams wrote:
>> "Andy Little" <andy_at_[hidden]> writes:
>>
>>
>>>Hi Boosters,
>>>
>>>Is it possible to use fusion to do a compile time matrix?
>>
>>
>> Not directly, but there are at least two good ways to build one on top
>> of fusion:
>>
>> 1. use a fusion vector of fusion vectors.
>> 2. use a fusion vector augmented with a row length (assuming it's row-major).
>>
>>
>
> The file array.cpp in vault/Template Metaprogramming has an array
> of types (can be any rank) which maybe useful to Andy.  One problem
> is that there's no way (yet) to create a value from the array of types.
>
> The array of types is specified with a shape vector(
> mpl::vector_c<unsigned, T0, T1, ..., Tn> ) where
> n is the rank-1 of the array of types.  The array<Shape,TypeArray> has a
>
> BOOST_CLASS_REQUIRE2(Shape,TypeArray) clause from the boost concepts
> library which assures the TypeArray has the shape specified by Shape
> (i.e. the vector_c<unsigned,...>).
>
> Andy, please let me know if you'd be interested in using this or what
> I'm planning on next.

FWIW I think that the combination of compile time programming, fusion and
matrices has got a lot of potential.
My own personal goal was to create a matrix capable of holding my quan physical
quantity types, and in order to do that I have to use tuples rather than arrays,
which is why fusion come in very handy. I wasnt (initially) too concerned about
performance

Now... the other aspect of matrix calcs is of course that they are never fast
enough! From my experiments it seems to me that the fusion, compiletime
programming combination can be very beneficial there too. I am not clear how
beneficial as I don't really know what the current state of the art is.

The final aspect of matrices (AFAICS, I am sure no expert) is that they can be
big.  Again from a very few experiments it seems to be quite possible to have a
matrix, using fusion, where arbitrary elements are compile time entities. It is
also possible of course at compile time to check ( for major example) if a
particular compile time element is zero.  If ( unlike the case for my physical
quantity elements), you assume that each compile time element is standing in for
a double, then it is presumably quite possible to sweep through the matrix
resulting form a calc and eliminate any zero elements. Then when an element is
not found in a processed matrix it must be a double with a zero value. For me
howver that is some way down the road ;-)

BTW the case of a compile time element with a zero value is particularly
interesting, because it seems to allow the holy grail of actually regaining some
compile time information.  This is because  N * 0  == ( of course 0), hence
whenever any runtime value is multiplied by a compile time value of 0  then a
compile time type representing 0 can be returned. This can have a beneficial
'domino' effect, thus eliminating many variables from a calc (think of how
fusion computes the result_type of a calc). In cases where the compile time
value is not 0 then the runtime type is returned:

(In simplest case)

static_value<0>  operator* (static_value<0>, double) { return
static_value<0>();}

template <int N> double operator * (static_value<N>, double v) { return v * N;}

Note also that the compiler will find it very easy to optimise the first away
completely and one can also factor this in as almost a useful compile time 
tool( which actually fusion does a lot AFAICS)

> My next step is figuring how to generate the
> values (IOW, just like fusion::vector has values corresponding to
> mpl::vector [OK, actually they're template arguments to the
> fusion::vector, but maybe you get my idea], there would be fusion::array
> having values corresponding to array<Shape,TypeArray>).

FWIW I think that a tuple is more interesting than an array, because of this
property that it can hold both runtime and compile time entities.
OTOH I guess that its all pretty new, so I should just say I dunno!

regards
Andy Little