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

[jmh530]

On Tuesday, 13 March 2018 at 21:04:28 UTC, bachmeier wrote:
>
> What I have settled on is Row(x,2), which returns a range that 
> works with foreach. I tried x[_,2] to return Row(x,2) but 
> didn't like reading it, so I went with x[_all,2] instead. 
> Similarly for Col(x,2) and x[2,_all]. The exact form is 
> bikeshedding and shouldn't make much difference. I use ByRow(x) 
> and ByColumn(x) to iterate over the full matrix.

This Row(x, 2) is essentially the same approach as Armadillo (it 
also has rows, cols, span). mir's select isn't quite the same 
thing.

_all is interesting.

mir's byDim that can iterate by both rows and columns.

>
> IME, if you try to mix row-order and column-order, or 0-based 
> indexing and 1-based indexing, it's too complicated to write 
> correct code that interacts with other libraries. I think you 
> need to choose one and go with it.

Fair enough.

mir uses a row-order 0-based indexing approach by default. That's 
fine, I'm used to it at this point. What I was thinking about was 
that Slice's definition would change from
struct Slice(SliceKind kind, size_t[] packs, Iterator) to
struct Slice(SliceKind kind, size_t[] packs, Iterator, 
MemoryLayout layout = rowLayout)
so that the user has control over changing it on a object by 
object basis. Ideally, they would keep it the same across the 
entire program. Nevertheless, I would still prefer it so that all 
functions in mir provide the same result regardless of what 
layout is chosen (not sure you can say that about switching to 
0-based indexing...). The idea would be that whatever is built on 
top of it shouldn't need to care about the layout. However, due 
to cache locality, some programs might run faster depending on 
the layout chosen.

With respect to interacting with libraries, I agree that a user 
should choose either row-order or column-order and stick to it. 
But what options are available for the user of a column-major 
language (or array library) to call mir if mir only makes 
available functions that handle row-major layouts? RCppArmadillo 
doesn't have an issue because both R and Armadillo are 
column-major. Going the other way, you'd probably know better 
than I would, but it looks like in embedr the only way I see to 
assign a D matrix to a RMatrix is by copying values. If a matrix 
was already in column-major form, then how easy much easier would 
it be to interact with R?