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

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

2010/3/3 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>
>
> 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 ?

This is needed for example when you do A*A.transpose() to understand
that the result fits in a 4x4 static array...

Another example: A.col(i)  can then be evaluated inside a 4x1 static array....

As for a place where it's concretely used in practice, well I would
think that these examples are natural enough...? I'm pretty sure we
must be hitting such cases somewhere...

Benoit

>
> gael
>
> 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
>>
>> >
>> > Benoit
>> >
>> >>
>> >> what do you think ?
>> >>
>> >> gael
>> >>
>> >
>>
>>
>
>