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

[ Thread Index | Date Index | More Archives ]

Ok, I will revert my change. Also as Hauke just told me, Matrix<float,3,3,0,4,4> is not allowed, so now I remember that the Max* stuff are only about avoid heap allocation, nothing more. Then why not replacing them with a unique MaxSize? it would be less confusing. Or do you remember if when MaxRows=4 and MaxCols=Dynamic, the fact that MaxRows=4 is used somewhere ?


On Wed, Mar 3, 2010 at 2:18 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
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
>> what do you think ?
>> gael

Mail converted by MHonArc 2.6.19+