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 14:37:13 +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=xWloUuuJICerOkcY3DtnoP0FtoShq8wseiWiwMT7Dxw=; b=ZSYmVvj0JaqisE+iiozYS/4bjJIeTN9TMuA5nMcLrowh4/8AXRNUA1JjfxL9//uhru EfpL5FoYohVanmRM3GIio10FqJSq9f6R1YcE1lQ0ZuzyD+LpDImZXBIeQlAE3K3F79tb HeZGjzXt+su2htWZNxCoNiRJ1Rn6lyX6uG6SE=*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=bQ47WlKeXxLS1ArAt4QWmhd5rZirA89wjx1apXGp3DkZIlTZGrVJfjHgCJqtdiThoL zg5S8R3l0WAOmRQhEPeb/PJg4Fuf7lYQdfNMdax7yfUqSIUN95b4Ekz8YUmLgo2kXrCs xMhOLT9Yp3l+5s7WIE1lGaqphwEkGPabbK5hE=

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. 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:*Gael Guennebaud

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

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