"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:ee2u4r$s9b$1@sea.gmane.org...
"Larry Evans" <cppljevans@cox-internet.com> wrote in message news:ee26mm$bu7$1@sea.gmane.org...
On 09/05/2006 08:36 AM, David Abrahams wrote:
"Andy Little" <andy@servocomm.freeserve.co.uk> 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