Re: [eigen] Geometry module - Quaternion fitting alternative |

[ Thread Index | Date 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 > needed. Right, thanks for the remark. So let's standardize on this. I'll have a look at how you did it. Benoit

**References**:**Re: [eigen] Geometry module - Quaternion fitting alternative***From:*Hauke Heibel

**Re: [eigen] Geometry module - Quaternion fitting alternative***From:*Benoit Jacob

**Re: [eigen] Geometry module - Quaternion fitting alternative***From:*Benoit Jacob

**Re: [eigen] Geometry module - Quaternion fitting alternative***From:*Gael Guennebaud

**Re: [eigen] Geometry module - Quaternion fitting alternative***From:*Benoit Jacob

**Re: [eigen] Geometry module - Quaternion fitting alternative***From:*Hauke Heibel

**Re: [eigen] Geometry module - Quaternion fitting alternative***From:*Benoit Jacob

**Re: [eigen] Geometry module - Quaternion fitting alternative***From:*Benoit Jacob

**Re: [eigen] Geometry module - Quaternion fitting alternative***From:*Gael Guennebaud

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Geometry module - Quaternion fitting alternative** - Next by Date:
**[eigen] Preconditioners** - Previous by thread:
**Re: [eigen] Geometry module - Quaternion fitting alternative** - Next by thread:
**[eigen] older compiler problems?**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |