Re: [boost] [fusion] matrix?

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

"Andy Little" <andy_at_[hidden]> wrote in message 
news:ee2u4r$s9b$1_at_sea.gmane.org...
>
> "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;}

OH Yeah. Now static_value is quite difficult to assign to  ;-)

Actually this problem is very ease to solve.

regards
Andy Little