Matrix API support - start with formats?

[Daniel Shapero via Digitalmars-d]

On Friday, 14 August 2015 at 14:57:19 UTC, Andrei Alexandrescu 
wrote:
> No doubt other popular linear algebra libraries have similar 
> documentation. I was thinking we could start with adding these 
> layouts to std, along with a few simple primitives 
> (construction, element/slice access, stride etc). Then, people 
> may just use those as they are or link with the linalg 
> libraries for specific computations.
>
>
> Thoughts?
>
> Andrei

For comparison, some other sparse linear algebra libraries worth 
looking at are:

* Eigen (http://eigen.tuxfamily.org/)
* PETSc (http://www.mcs.anl.gov/petsc/)
* the Epetra sub-package of Trilinos (https://trilinos.org/)
* OSKI, which aims to do for sparse matrices what ATLAS does for 
dense (http://bebop.cs.berkeley.edu/oski/)

MKL is missing some important sparse matrix formats -- the 
ellpack and jagged diagonal formats, which are very well suited 
for SIMD processors, and the MSR/MSC format, which makes 
multigrid smoothing faster.

I don't know enough to weigh in on whether sparse matrix algebra 
is best left to the individual libraries or put in the language's 
standard library. It's common practice whenever one needs sparse 
matrices to write wrapper classes that can use either PETSc or 
Trilinos, depending on what the users have installed on their 
systems. For example, this is the approach taken in the finite 
element library deal.II (http://dealii.org/). Moreover, the big 
sparse matrix libraries can all use each other; PETSc can link to 
the solvers in Trilinos, both PETSc and Trilinos can link to 
OSKI, etc. If there were some support in the standard library for 
this functionality, it could obviate the need for some of the 
glue code in C/C++.