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

[Yuanchen Zhu <yuanchen.zhu@xxxxxxxxx>]

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, 

• We have already nailed the semantics of innerSize/outerSize for a 2D matrix. 
• If semantically a column vector or a row vector is a 2D matrix, then it really doesn't make sense to change the semantics of innerSize/outerSize of column/row vectors to be (size(), 1). Pick a different name if you want to refer to something different.
  
• If semantically a column vector or a row vector is not a special case of a 2D matrix, then it shouldn't even have innerSize/outerSize defined. For Eigen, I believe this is not the case, and column/row vector IS still a matrix (just with rows or cols known to be 1 at compile time), otherwise it doesn't even make sense to talk about row vs column vector. 

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.

Thanks,

Yuanchen

On Sun, Feb 3, 2019 at 5:10 AM Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

See bug 416 for discussions on that matter: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=416

For the record, I've recently been tricked by this issue too: https://bitbucket.org/eigen/eigen/src/fd83cfbceb90e303a935c86238f1e3cf3bd913ef/Eigen/src/Core/PartialReduxEvaluator.h#lines-209 , 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.

Gaël.

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

Hi,

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.

Thanks,

Yuanchen