|Re: [eigen] Geometry module - Quaternion fitting alternative|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Geometry module - Quaternion fitting alternative
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Wed, 27 May 2009 15:19:41 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=NWgu89EuBHx3TV1ioVXIE7f1JrtOEv9d0F1TC2jz/S8=; b=iUNXfdhbnxRO369GfQIzSnGmpV/HeHr9XiLoYIrjCoV8VRN9107E2mVZQswGFVIMxA sZj3kUcGSe1Vsuimrhcj5a3kmKLnzpURg/mf6k9CLv+R2z3F35vB77ikm/zo7RAcFwu1 pmJCrDMpSLzz9SroWx7cJlbTO64bz1qG+M9y8=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Iw8EHu4vIuGUEbB1dW72xMkwOdeP55z4jQq00r54B+vSNPceS/6fCd40SvlCbrXpmt djLqKg3bJQAPDcz2t97tA3uSfy9o1DV13mJ+1Gv6Pb2lLI28qvUj4gBS9DMeE70uRMjv 0hUyPXahWh1RI++OqpFqg1/yfMtZpQUBAZzv0=
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
Right, thanks for the remark. So let's standardize on this. I'll have
a look at how you did it.