Re: [eigen] about the semantic of MaxRows, MaxCols

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

2010/3/3 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 2010/3/3 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>>
>> Hi,
>>
>> A recent change of mine about matrices having different max sizes and actual
>> sizes broke lu kernel computation. The reason is that I thought that in the
>> following example:
>>
>> Matrix<float,3,3,0,4,4> m;
>> m << 0, 3, 6,
>>          1, 4, 7,
>>          2, 5, 8;
>>
>> the data were organized as follow:
>>
>> 0 1 2 x 3 4 5 x 6 7 8 x x x x x
>>
>> i.e., Matrix<float,3,3,0,4,4> was like a 3x3 block of a 4x4 matrix. However,
>> currently, the 3x3 floats are taken from the 9 first ones of the 16
>> statically allocated buffer:
>>
>> 0 1 2 4 4 5 6 7 8 x x x x x x x
>>
>> i.e., Matrix<float,3,3,0,4,4> is really like a Matrix<float,3,3>.
>>
>> So the question is shall we stick with the current behavior ? or shall we
>> adopt what I thought it was ? Let's enumerate the pros and cons for the
>> change:
>> pros:
>>  * potentially allows for more vectorization since, e.g.,  it allows to
>> align all the columns of a Matrix<float,3,Dynamic> using
>> Matrix<float,3,Dynamic,0,4,Dynamic>
>> cons:
>>  * this is a change so more work to do and potentially new bugs ;)
>>  * such matrices lost the linear access flags
>
> This complexifies a lot a concept that was, so far, very simple
> (indeed the Max dimensions only have an effect for the allocation of
> the array, and no effect at all on the data layout inside of that
> array).
>
> So it needs to be justified by a big benefit and one should also check
> if there's a simpler way to allow the same...
>
> Benefit check: how good is it to have aligned columns in a
> column-major matrix? It allows to vectorize certain matrix products
> although it requires special care as we now have uninitialized scalars
> coming into play...
>
> On the other hand we lost he LinearAccess bit as you mention, and,
> independently of that, the vectorization of linear operations is now,
> at best, only 3/4 as efficient.
>
> If we are certain that the user wants that then of course it's his
> responsibility, but here, i could imagine an algorithm with
> meta-unrollers producing a Matrix<float,3,3,0,4,4> from an initial
> Matrix4f....
>
> So I have the impression that if we want to offer the possibility of
> this kind of matrices, another API is needed. Could be a new Matrix
> option AlignInner...

Big argument in favor of keeping the default as-is and possibly adding
an AlignInner option later: such a change will be both API and ABI
compatible. So it can be done at any later date. By contrast, in your
initial proposal, we must get that done right now.

Benoit

>
> Benoit
>
>>
>> what do you think ?
>>
>> gael
>>
>