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.

Reply via email to