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