Do we need Mat, Vec, TMmat, Diag, Sym and other matrix types?

[J-S Caux]

On Tuesday, 13 March 2018 at 03:37:36 UTC, 9il wrote:
> Hi All,
>
> The Dlang multidimensional range type, ndslice, is a struct 
> composed a an iterator, lengths and possibly strides. It does 
> not own memory and does not know anything about its content. 
> ndslice is a faster and extended version of numpy.ndarray.
>
> After some work on commercial projects based on Lubeck[1] and 
> ndslice I figure out what API and memory management is required 
> to make Dlang super fast and  math friendly in the same time.
>
> The concept is the following:
> 1. All memory is managed by a global BetterC thread safe ARC 
> allocator. Optionally the allocator can be overloaded.
> 2. User can take an internal ndslice to use mir.ndslice API 
> internally in functions.
> 2. auto matrixB = matrixA; // increase ARC
> 3. auto matrixB = matrixA.dup; // allocates new matrix
> 4. matrix[i] returns a Vec and increase ARC, matrix[i, j] 
> returns a content of the cell.
> 5. Clever `=` expression based syntax. For example:
>
>    // performs CBLAS call of GEMM and does zero memory 
> allocations
>    C = alpha * A * B + beta * C;
>
> `Mat` and other types will support any numeric types, PODlike 
> structs, plus special overload for `bool` based on `bitwise` 
> [2].
>
> I have a lot of work for next months, but looking for a good 
> opportunity to make Mat happen.
>
> For contributing or co-financing:
> Ilya Yaroshenko at
> gmail com
>
> Best Regards,
> Ilya
>
> [1] https://github.com/kaleidicassociates/lubeck
> [2] 
> http://docs.algorithm.dlang.io/latest/mir_ndslice_topology.html#bitwise
> [3] 
> http://www.netlib.org/lapack/explore-html/d1/d54/group__double__blas__level3_gaeda3cbd99c8fb834a60a6412878226e1.html#gaeda3cbd99c8fb834a60a6412878226e1

Well if D had:
- a good matrix type, supporting all numeric types (absolutely 
crucial: including complex!)
- *very important*: with operations syntax corresponding to the 
well-established standard mathematical conventions (including in 
labelling the elements!)
- with superfast LU decomposition, det and similar (perhaps via 
LAPACK)
- able to recognize/carry a tag for (anti)symmetric, hermitian, 
... and exploit these in computations
then I'd be more seriously considering switching to D.

Your suggestion [4] that matrix[i] returns a Vec is perhaps too 
inflexible. What one needs sometimes is to return a row, or a 
column of a matrix, so a notation like matrix[i, ..] or 
matrix[.., j] returning respectively a row or column would be 
useful.

I'd be happy to help out/give advice from the viewpoint of a 
scientist trying to "graduate" away from C++ without having to 
sacrifice performance.