Boost logo

Boost :

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

"Andy Little" <andy_at_[hidden]> wrote in message
> "Larry Evans" <cppljevans_at_[hidden]> wrote in message
> news:ee26mm$bu7$
>> 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.

Andy Little

Boost list run by bdawes at, gregod at, cpdaniel at, john at