The Matrix to end all Matrix classes (Let's dream!)

[Pablo Ripollés]

Hello!

Just a few sort comments and ideas...

Don Clugston Wrote:

> No, I don't have the perfect Matrix. I just want to explore the question of 
> whether it exists.
> There are a plethora of C++ matrix libraries, all of which are far from perfect; 
> they all involve trade-offs between various language limitations.

Appart from these C++ matrix libs, I've come to appreciate these array/matrix API's:

http://numpy.scipy.org/
Fortran 95 arrays
MATLAB arrays
Maple linear algebra API's

> In particular, the usage of expression templates creates all kinds of evil.
> 
> Requirements:
> 1. Must be compatible with future multi-dimensional array syntax such as
> double [7,5] m;

As it has already been mentioned, is the target of this Matrix only 2-dimensional? In mathematical terms a matrix is always a 2-dimensional array with a proper algebra.  For example, AFAIK the transpose operation is not defined for a 3-dimensional array.

> 2. Must be theoretically capable of optimal performance.
> 3. Needs to support slices. This means we also need to support strided
> vectors. Therefore we also need matrix slices, and matrix references.
> Probably distinguishing between the T[] and T[new] concepts.
> 4. For storage we need packed, triangular, symmetric, banded, and sparse
> matrix support. (Possibly even 'calculated' matrix support, for
> user-defined matrix types which generate entries on-demand).
> 5. Can be generalized to tensors.

What does this mean?  AFAIK tensors are not a mere dimensional generalization of matrices.  Tensors are "geometric" entities that are independent of the coordinate system.   Besides all this play with the covariant/contravariant you haven't got with matrices.  0-order tensors are scalars, 1-order tensors are vectors.  We can use matrices to represent scalars, different covariant/contravariant vectors and 2-order tensors.  I would like to see a Matrix type but respecting the mathematical abstraction it should represent.

> 6. Nice error messages.
> 
> I now have enough experience with my BLADE library to be confident that all of 
> these features can be achieved in existing D. In particular, the crucial 
> requirement 2 can be completely decoupled from the others.
> 
> But, there are many requirements (dozens?) which are not on my brief list, and 
> perhaps they cannot all be met simultaneously, even in theory. Yet I'm not 
> convinced that it's impossible. What are the other requirements?

IMHO I think that when implementing (classic) mathematical abstractions, its primitive conceptual design should be retained.

Pablo