std.linalg

[CJS]

I'm with SomeDude: This project is doomed to failure from the get 
go, and under no circumstances should be put into std.

First, some background so this doesn't seem too harsh. Numerical 
linear algebra is easily the single oldest and most 
well-developed area of computing. Period. There's a huge history 
there, and if you don't know it then whatever you make won't be 
used and will be universally derided. Second, beyond the 
background of implementations is the theoretical background of 
what they're used for and how that influences the API.

You also have understand that linear algebra algorithms and data 
structures come in 3 major varieties: Dense, Sparse Direct, and 
Iterative methods. For just the theoretical background on these 
and associated floating point issues there is an absolute minimum 
of the material similar to what's covered in these two standard 
references:
Matrix Computations by Golub and Van Loan: 
http://www.amazon.com/Computations-Hopkins-Mathematical-Sciences-ebook/dp/B00BD2DVIC/ref=sr_1_6?ie=UTF8&qid=1381614419&sr=8-6&keywords=nick+higham

Accuracy and Stability of Numerical Algorithms by Nick Higham: 
http://www.amazon.com/Accuracy-Stability-Numerical-Algorithms-Nicholas/dp/0898715210/ref=sr_1_7?ie=UTF8&qid=1381614419&sr=8-7&keywords=nick+higham

The old, well-tested, and venerable BLAS and LAPACK APIs/packages 
are just for dense matrices. There are other variants for 
different kinds of parallelism. And notice there are differences 
in numerical linear algebra between instruction level parallelism 
(like SSE and AVX), shared memory, distributed memory, and 
coprocessors (like OpenCL or CUDA). In terms of popular existing 
implementations there are more recent packages like Magma 
(http://icl.utk.edu/magma/), 
PLASMA(http://icl.cs.utk.edu/plasma/), PETSc 
(http://www.mcs.anl.gov/petsc/), Trillinos 
(http://trilinos.sandia.gov/), or Elemental 
(http://libelemental.org/). The most popular sparse direct 
package, as far as I know, is SuiteSparse 
(http://www.cise.ufl.edu/research/sparse/SuiteSparse/), which is 
wrapped by Eigen 
(http://eigen.tuxfamily.org/index.php?title=Main_Page). Eigen is 
so popular in part because it does a good job of balancing 
expression template magic for dense matrices and wrapping/calling 
BLAS/LAPACK and SuiteSparse.

The very popular NumPy and SciPy packages are also basically 
wrappers around BLAS and LAPACK. There is also a scipy.sparse 
package, but its API differences are an ongoing headache.

All of which is to say this is a very deep area, the differences 
in algorithms and storage are sufficiently fundamental to make a 
unified API very difficult, and in any case the D community 
simply cannot commit to developing and maintaining such a library 
or commit to rolling in future developments from ongoing research 
in the area. This is exactly the sort of thing that should be a 
third-party extension, like in every other language, rather than 
in the standard library.


On Saturday, 12 October 2013 at 08:47:33 UTC, SomeDude wrote:
> On Saturday, 12 October 2013 at 06:24:58 UTC, FreeSlave wrote:
>>
>> For these cases we may let users to choose low-level backend 
>> if they need. High-level interface and default implementation 
>> are needed anyway.
>>
>> I called it std.linalg because there is website 
>> http://www.linalg.org/ about C++ library for exact 
>> computational linear algebra. Also SciD has module 
>> scid.linalg. We can use std.linearalgebra or something else. 
>> Names are not really important now.
>>
>> Ok, things are more clear now. Today I look what I can do.
>
> There are litterally dozens of linear algebra packages: Eigen, 
> Armadillo, Blitz++, IT++, etc.
>
> I was not complaining about the linalg name, but about the fact 
> that you want to make it a std subpackage. I contend that if 
> you want to make it a std package, it must be nearly perfect, 
> i.e better performing than ALL the other alternatives, even the 
> C++ ones, and that it's really good as an API. Else it will be 
> deprecated because someone will have made a better alternative.
>
> Given the number of past tries, I consider this project is very 
> likely doomed to failure. So no std please.