[eigen] issue 77: map with stride

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

Hi,

Let's continue the discussion here, as bitbucket doesn't send
notification for replies on the issue tracker AND has a crappy
text-edit widget.

quoting Gael:

> hm, here are some thoughts:
>
>    * First of all, I think that for vectors, the storage order should not matter at all, i.e., it should simply be ignored in Assign.h and the likes..

Yes, we agree on that: the storage order should just be ignored. The
only reason why I proposed to constrain it was to allow for a more
consistent meaning of "stride".

>    * Second, from my point of view that's the outer-size of a vector which should always be 1. For instance think about algorithm working per innervector.: you would loop over all innervectors, and it is pretty clear that the outersize of the subobjects you get (i.e., M.innerVector(j)) should be 1..

I also considered the same argument that you are pointing out, but
until now I thought that it was no big deal because vectors are best
traversed using LinearAccess anyway.

Then I thought about the example of tiny matrix-matrix products with
InnerVectorization and how they should specialize to matrix-vector
product... so you are right, this does matter.

But on the other hand, your convention that stride means "outer
stride" for matrices but suddenly becomes 1 for vectors, is much more
logical if vectors have innerSize==1, which led to my proposal.

So we have a dilemma.

Let's propose to solve this problem by decoupling the notion of stride
into two separate notions of stride: "inner stride" and "outer
stride". Outer stride is what you used to call stride for matrices
(not vectors). Inner stride is the spacing between two consecutive
entries within an inner slice, so it is equal to 1 almost always.

Here is an example with InnerStride!=1: suppose that M is a
column-major matrix with r rows, then each row can be obtained as a
Map with InnerStride=r.

quoting Gael again:

> Finally, regarding the RowMajorBit flag, here is a proposal: What about add a ColMajorBit flag (i.e., RowMajorBir=1 and ColMAjorBit=2). For vectors we would ensure that Flags&(RowMajorBit|ColMajorBit)==0, and expressions having no preferred orders like some matrix products and binary ops between a colmajor and a rowmajor matrices could have both bit flag.

This is a bit more elegant than our current design, yes.

This can also lead to a slightly better logic determining storage
orders, for example in:

 RowMajorMatrix + ColMajorMatrix + ColMajorMatrix2

the first + could say "i dont care about the storage order" so the 2nd
+ chooses column-major. But I don't see that happening a lot in
practice.

FYI, I spent time thinking if/how we should do such a change also to
the Options parameter of Matrix. The answer is no:
 - 0 must stay the default value in all cases including matrices, as
this is a bit field touched by the user.
 - so 0 would have to mean "column major, and nevermind if it's a vector"
 - so a column-major matrix could have either 0 or ColMajor here.
 - that's 2 separate types meaning exactly the same thing: a recipe to
generate redundant template instantiations. Bad.

So in all cases, the Options template parameter to Matrix stays as-is.
So there would be a discrepancy between it and MatrixBase::Flags.
Perhaps that negates the elegance benefit of the proposed change to
MatrixBase::Flags?

Benoit