Glas List: Re: [glas] Call for developers

From: Pieter.Collins_at_[hidden]
Date: 2007-06-28 05:02:31

Dear Karl,

As the main co-developer on the main project I am working on recently
graduated and vanished, I appreciate that it's important to have support!

I would be prepared to contribute to GLAS, but only if this is directly
useful for my project. Since we have some rather specialised requirements,
maybe GLAS cannot support these. Here are the main issues:

Expressions: We would like a general-purpose expression template mechanism
which we can use throughout, and not just for linear algebra. For this we
need storage expression classes BinaryExpression etc and operator classes
Add etc. These classes are orthogonal to the linear algebra concept
classes ScalaVectorExpression etc, and could probably be combined using
multiple inheritance.

Mixed Arithmetic: We use mixed-mode arithmetic for our scalar types and
would like this to carry over to the linear algebra. For example, Integer
/ Integer -> Rational. Currently we implement this using type traits
similar to
  typedef division<Integer,Integer>::result_type Rational;
but perhaps a better system would be to use late binding
  divide(Rational&,Integer,Integer);
called by dispatching from
  Rational q = z1 / z2;

Renaming: Since we want a consistent interface, and use CamelCaps class
names, we need to rename the GLAS classes. As C++ does not (currently)
have a "typedef template" construction or similar, we need to use
inheritance and wrapping. How does this interact with the expression
templates system?

Algorithms: We would like to have LAPACK functionality classes/algorithms
for LU, QR, SVD, and Eig which are not restricted to LAPACK bindings. I've
finally gotten round to requesting space on Sourceforge for the TBLAS and
fledgeling TLAPACK templated routines, but these need a class wrapper, and
as I'm not a linear algebra expert, the TLAPACK functionality is minimal.
(Help wanted!!) We need wrappers for these C-style functions.

We currently have our own implementation of the minimal functionality we
need (currently not using expression templates) but it would be better not
to have to duplicate work, if our requirements can be met. (Otherwise we
might just adapt GLAS code from time to time.)

Best regards,

Pieter Collins
CWI, Amsterdam