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*: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>*Date*: Wed, 27 May 2009 14:50:48 +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=jRNWtAKXkX2IkivLVD8K2hwmyZCfA7ROMqZvQME4yDI=; b=kmAgjlhdgUVs4Ya9tl7EEs0SaHKQ2zVS3dqvIBhCNpa+3OVkhENBWS8C7kwtfLtnzC bpFmF2K+HLQ0oTl2h8ndM3Q2L15w1MqhEZx7OMIrjQ5824wDKD//bJ2yTkELa6BivsOd Wt/whr9zULUvUDqFWnv+QVKC5wUfw6DMBBrjQ=*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=tK579Fq5um/jQlo/BLuVyuFfpvNKxzIWxy6JVdIfxqsMSt5J/MyPmvsRnQZJQhCxlB IHhEMp7pxFB7E3XyBrE6QJ8gTK16X3gJSQWqLmttmWboLOLZo9JEwNlH8x8ULECujz5H uRw0LYfKGrxNd3Zfhw1475iFZPIRsYCKHdI04=

On Wed, May 27, 2009 at 2:37 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote: > 2009/5/27 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>: >> 2009/5/27 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>: >>> Regarding the storage type (i.e. RowMajor vs. ColMajor) I would >>> refrain from starting to implement any algorithm such that it makes >>> any assumptions on it. >> >> We agree with this but sometimes it's very hard to make code that will >> be equally fast in both cases. Look at the PartialLU: it could equally >> well be done with row operations or col operations, and of course >> better speed is achieved if this matches the storage order. Currently >> it is done with col operations and I'm not sure how to best make it >> work in the row-major case without writing the code twice. Or is this >> inevitable? Just transposing doesn't cut it as that would interchange >> L and U.transpose() and they're not interchangeable (L has 1's on the >> diagonal). > > You got me thinking :) > > 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. > I have yet to decide between the 2 approaches, transposing is more > high-level and elegant and safe and requires no changes to the core of > Eigen, but the other approach will give faster compilation and will > allow to write algorithms like LU without having to act in 2 different > ways (transpose or not) depending on storage order. > > Benoit > > >

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

**References**:**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

**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

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

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