Re: [eigen] Geometry module - Quaternion fitting alternative

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

2009/5/27 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> On Wed, May 27, 2009 at 2:37 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> It's not that hopeless, just very hard for my limited brain to think.
>> If we also transpose the LU matrix here, all should be fine. So
>> transposing should be one possible way of doing this.
>>
>> Another, even more "agnostic" way would be to introduce
>> "storage-order" versions of rows/cols/blocks/coeff access methods.
>> These would ignore the actual storage order and instead work as if the
>> storage order were always col-major. Then I could take my LU algoritm
>> that uses column operations and do everything with these methods and
>> the result would be the same, only it would be equally optimized
>> regardless of storage order.
>
> This is what I did in the Sparse module because if you have a colmajor
> sparse matrix there is no way to loop over the elements of a row,
> whence the outersize(), innerSize(), innerVector(), etc. functions.
>
> This is also similar to what is done in the matrix product: the
> function takes a pair of pointer/stride and assume the matrix is
> colmajor. The caller takes care to transpose/swap the arguments when
> needed.

Right, thanks for the remark. So let's standardize on this. I'll have
a look at how you did it.
Benoit