Re: [boost] Re: matrix library ?

From: Dean Calver (deano_at_[hidden])
Date: 2001-03-13 16:27:42

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