Re: [eigen] Question about ColMajor vs. RowMajor

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

2011/12/16 Michael Dixon <mdixon@xxxxxxxxxxxxxxxx>:
>  Hi,
>
> My colleagues and I were recently playing around with changing the
> default for matrices from ColMajor to RowMajor, and we found that
> doing so changed the behavior of the () operator.  Specifically, when
> accessing a two-dimensional matrix with a single index (e.g., mat(i)
> ), the ColMajor/RowMajor flag affects which element of the matrix gets
> indexed as the ith.  Our assumption had been that changing the
> ColMajor/RowMajor flag would be completely transparent, which is to
> say, it would affect the underlying storage (and thus the
> performance/efficiency), but it wouldn't change the overall behavior
> of the code.

This is mostly true, but it doesn't apply to the few parts of the API
that are explicitly about low-level addressing of the underlying array
of coefficients as a single-dimensional array. operator(index) is like
that. It is meant for use cases where you just want to iterate over
coefficients in the most memory-local way, and don't care if that
means col-major or row-major iteration.

>  I was just wondering whether the altered behavior of the
> () operator was intended (in which case, our assumption of
> transparency was incorrect), or whether this was an unintended bug.

This behavior is intended and not considered 'altered', it just plays
at a lower level than where the notions of "col-major" vs "row-major"
storage exist.

Maybe we'd need to document that more clearly, but it's already
explained on page 1 of the tutorial:
http://eigen.tuxfamily.org/dox/TutorialMatrixClass.html

"Note that the syntax m(index) is not restricted to vectors, it is
also available for general matrices, meaning index-based access in the
array of coefficients. This however depends on the matrix's storage
order."

We need to have class API docs inherit base classes so that they are
more usable, and then put a similar explanation there.

Cheers,
Benoit

>
> Thanks,
> Michael
>
> P.S. In case my description of the problem was a little unclear, I'm
> also attaching a small program that demonstrates the change in
> behavior.