RE: [boost] Re: matrix library ?

From: Reid Sweatman (reid_of_diamonds_at_[hidden])
Date: 2001-03-27 20:14:50

I just noticed in the OON Digest that Walter Landry
[landry_at_[hidden]] has written some generative template stuff for
tensors for his astrophysics work.  You might drop him a line and see if
it's sharable, or at least if we can look at it.  Here's the text of his
post (I hope he doesn't mind my repost; I think I had a meeting with him
about three years ago and annoyed the hell out of him...so someone else can
ask <g>):

POST START ---------------------------------------------------------------

I don't know if this counts, but I'm using template metaprogramming in
my astrophysics code.  An earlier version of the code has been
submitted to the Monthly Notices of the Royal Astronomical Society.
You can find a pre-print at the Los Alamos archives (xxx.lanl.gov).
Search for my name in gr-qc.  The code in that paper didn't use
template metaprogramming, but the current version of the code does.
The current version has been applied to more problems (initial data
for black holes and accretion disks around black holes), but, alas, no
publications yet.

Basically, I constructed a library for tensor manipulations.  I
needed something more powerful than what Blitz offered (I needed
automatic contraction, various symmetries, etc.)  Also, the model that
Blitz used for it's array class wasn't quite what I wanted.  In any
case, you can find out what it is by looking at the blitz mailing list
archives.  Just search for my name.

POST END ------------------------------------------------------------------

Reid Sweatman

> -----Original Message-----
> From: Dean Calver [mailto:deano_at_[hidden]]
> Sent: Tuesday, March 13, 2001 2:28 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Re: matrix library ?
>
>
> Dave Steffen wrote
> > C) most people need _either_ inner _or_ outer products in
> >     a given project; that is, the number of programming tasks
> >     requiring _both_ inner _and_ outer products is fairly
> >     small.
> >
> >  I also suspect that deciding whether operator*() implements an inner
> >  or outer product will generate a lot of heat, and either way people
> >  won't be happy.  It would be nice to allow both; there are several
> >  mechanisms that might do the trick.
> >
> >  So: I'd restrict our efforts to first and second order tensors
> >  (i.e. vectors and matrices), and settle for writing
> >
> >  A = B * C * D;
> >
> >  for the product of three matrices.
>
> I agree that there is little need for the higher tensors (but it would be
> nice) but computer graphics use inner and outer products all the
> time. Inner
> tend to be used more but Outer are used fairly often. The PlayStation2 has
> to do them so often it has hardware support for both, some algorithms use
> inner and outer products on a per-pixel basis.
>
> I'm very interested in vectors and matrices but I think that it would be
> nice to specify the interface in ways that will allow vendors to implement
> platform specific versions, most processors today support vector
> operations
> upto 4 floats or 8 integers as a basic type. Most of the numerics
> libraries
> I have seen seem to ignore the hardware support that exists in processors
> today.
>
> I should note that the comments I'm making are for 'small' vector/matrix
> operation max 8x8 matrixes and are likely complete rubbish for proper
> numerics :-) I tend to do lots (millions) of R4 dot and cross
> products, with
> a few complex operations (inverses, eigenvectors etc).
>
> I dream of the day when I can do this
>     mathvector<float,4> u;
>     matrix<float,4,4> m;
>     mathvector<float,4> r = m * u;
> and get portable/standard, potentially hardware accelerated maths
> libraries.
>
> Some issues I (already) foresee if we were to try are
> 1) returning references.
>   If a processor has a built in type, say a 128bit 4 float vector then we
> should NOT return references.
>     Good: mathvector<float,4> something();
>     Bad: mathvector<float,4>& something();
> but if not hardware we should? use a reference to stop having to copy a
> structure around.
> 2) partials.
>     Most vector units have a fixed size (e.g. 4 floats) but like to have
> partials type treated specially.
>   mathvector<float,4>a;
>   float b = 10.f;
>   a = a * b; // likely to be slow as it has to move to/from memory across
> registers etc
>   partial1_mathvector<float,4> c = 10.f; // there has to be many special
> partials
>   a = a * c; // likely to be faster register to register operation
> 3) multiple units.
>  Many processors have multiple units that can be used simultanously, using
> an STL memory allocator like system would allow this when speed is really
> important (not portable probably) something like this.
>  mathvector<float,4, VECTOR_UNIT0> va,vb;
>  mathvector<int,8, MMI> ia,ib;
>  mathvector<float,4, FPU> fa,fb;
>  va = va * vb;
>  ia = ia * ib;
>  fa = fa * fb;
>
> Thats probably enough (and there is alot more) to scare everybody into not
> wanting to look a hardware ever again :-) but to me the lack of
> basic vector
> operations (SIMD) in C++ is a major failing, I hope that in X
> years it will
> be a standard as float or int.
>
> We (games programmers) have these exact problems, with PC, P3,
> P4, AMD, Mac,
> PS2 and DreamCast versions and I want a standard, if I have to
> write 1 more
> vector class... (alright just a last boost one) :-)
>
> Sorry for the long post,
>     Deano
>
> Dean Calver
> Games Console 3D Programmer
>
>
>
>
> List-Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>