|Re: [eigen] Question about ColMajor vs. RowMajor|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
Awesome. Thanks, that makes perfect sense.
Sent from my iPhone
On Dec 17, 2011, at 7:21 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2011/12/16 Michael Dixon <mdixon@xxxxxxxxxxxxxxxx>:
>> 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:
> "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
> We need to have class API docs inherit base classes so that they are
> more usable, and then put a similar explanation there.
>> 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