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

[jmh530]

On Tuesday, 13 March 2018 at 15:47:36 UTC, Martin Tschierschke 
wrote:
> On Tuesday, 13 March 2018 at 14:13:02 UTC, jmh530 wrote:
> [...]
>> https://en.wikipedia.org/wiki/Row-_and_column-major_order
>
> I think for mathematics it is more important for easy handling,
> to be able to get the element of a matrix a_ij by a(i,j) and 
> not only by a[i-1,j-1].
>
> The underlying storage concept is less important and depends 
> just on the used libs, which should be the best (fastest) 
> available for the purpose.

The underlying storage format is important for performance, 
especially cache lines. For instance, calculate the sum of the 
columns of a matrix stored in row major format vs. column major 
format. If it is stored column-wise, you can just loop right down 
the column.

In LAPACKE (note the E), the first parameter on just about every 
function is a variable controlling whether it is in row-major or 
column major. By contrast, I believe the original LAPACK (without 
E) was written for FORTRAN and is in column-major storage [1]. 
The documentation for LAPACKE notes:

"Note that using row-major ordering may require more memory and 
time than column-major ordering, because the routine must 
transpose the row-major order to the column-major order required 
by the underlying LAPACK routine."

It also is relevant if people who use mir want to interact with 
libraries that use different memory layouts. Alternately, people 
who use languages like Fortran that have row major formats might 
want to call mir code.

[1] mir-lapack uses Canonical slices in many of these functions. 
I assume this is correct, but I have a nagging feeling that I 
should compare the results of some of these functions with 
another language to really convince myself...When you increment 
an iterator on canonical it's still going in row order.