Re: [eigen] Submatrix of a matrix does not preserve majorness

[ Thread Index | Date Index | More Archives ]

Got it.

Let me state my suggestion here in the mailing list while I wait to be granted a buzilla account to participate in the discussion there, 
In summary, I think the RIGHT THING TO DO is to eliminate the SPECIAL definition of innerSize/outerSize of vectors, which is different from that of a 2D matrix at the moment, and then go from there. I think this is close to Christoph Hertzberg's suggestion on the mailing list.


On Sun, Feb 3, 2019 at 5:10 AM Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:
See bug 416 for discussions on that matter:

For the record, I've recently been tricked by this issue too: , so I agree this behavior should be changed, but as discussed in bug 416 that's not as straightforward as it looks at first glance.


On Sat, Feb 2, 2019 at 4:08 AM Yuanchen Zhu <yuanchen.zhu@xxxxxxxxx> wrote:

I find it unintuitive that a submatrix of a matrix can change its majorness depending on if the submatrix is a row or a column. Say M is a column-majored matrix. Then M.row(i) is actually conceptually row-majored. This becomes an issue once you start to reshape the resulting 1D quantity, e.g, you might want treat pixels in a 2D image as a row of a big 3-row matrix. Then at the end, you want to unpack a row back into a 2d matrix. Natuarally, when you do unshape, you should preserve the majorness. But the row is actually row-majored, so if you don't change the majorness when you reshape, you get a row-majored matrix at the end.

To summarize: Having submatrix operations changing the majorness of the resulting submatrix depending on its shape is a library-wart. Can we change this behavior? Essentially once you choose a majorness convention for your application, all matrix operations should not change the majorness of the resulting matrix, unless EXPLICITLY requested by user, e.g., for efficiency.


Mail converted by MHonArc 2.6.19+