Re: [eigen] Rigid Transformations in eigen: discussion thread |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Rigid Transformations in eigen: discussion thread*From*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Fri, 18 Sep 2009 06:59:36 -0400*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=R0wt2OF7VF4tcrtl2P/IkSaQ5+qehNmCDC50GV2iflA=; b=Xz8F7x9Tqgv5x+eLyJI8DEhG1IxCFdFx19K8GkM9Wt+vRaFjJh8G3ZbEojPH7DYK2B hPpA5s7UY9qb/s08IWG7o3wi9vFgQwNfnN0kqVO9Wj2JyUnQxTNo08P2dMFT3hCVXaPn 4wymv9GqwmX2k0BB5oY9b6fa/UAI2M04aROBg=*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=MaJUHCepAH0rh9+MwBKr+hOOM1c9blsEHJ6jImtupUnQkbiKUfYBquOAdRIypamezr zqn1iybJa8gSq/mEYIZ03/G5PMvsrPNevACs2J5htOms2HGbkK5z2c9iA3BxfFvnyt24 UFoWJSIVMFlwYrvDj3q3CyNvUCok8CI+dInSw=

2009/9/18 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>: > On Fri, Sep 18, 2009 at 7:41 AM, Rohit Garg <rpg.314@xxxxxxxxx> wrote: >>> Yes. So if the user is OK to cope with having to call coeffs(), then >>> he can do all what he likes, and get optimized code thanks to ET. >> >> But for just an interpolation, you should not have to write coeffs() >> everywhere. :( >> >> Is there no other way to get ET without coeffs()? >> >> How about the + and the * operator return vec8 expressions, and we >> provide only 1 assignment operator to take vec8 expression as input? > > Another quite simple solution is to add a second template argument > being the type of the coeffs. By default it would be a Vector8_. For > instance operator* would be implemented as: > > DualQuaternion<Scalar, CwiseUnaryOp<ei_scalar_multiple_op<Scalar>, > CoeffsTypeOfThis> > operator*(Scalar s) > { > return s * m_coeffs; > } > > > same for operator+: > > template<typename OtherCoeffsType> > DualQuaternion<Scalar, CwiseBinaryOp<ei_scalar_sum_op<Scalar>, > CoeffsTypeOfThis, OtherCoeffsType> > > operator+(const DualQuaternion<Scalar, OtherCoeffsType>& other) > { > return m_coeffs + other.m_coeffs; > } > > Then you add a ctor and operator= like this: > > template<typename OtherCoeffsType> operator=(const > DualQuaternion<Scalar, OtherCoeffsType>& other) > { > m_coeffs = other.m_coeffs; > } > > > and you're almost done: you still have to take care to evaluate the > coeffs if needed in the compositing operator* and similar functions. Excellent, somehow that possibility totally escaped me. This solution also fixes another problem of Rohit, by the way: how to map existing data as a Quaternion (there already was the reinterpret_cast trick but now there is also the possibility of using Map<....> as the data type). Rohit, just in case this isn't clear from Gael's email, he's suggesting that the data type of the "Vector8 m_coeffs;" data member can be freely chosen, so instead of a "plain vector" type as Vector8 you can have any expression type. So your operator+ may now return a DualQuaternion where the underlying Vector8 type is now a "sum of two Vectors" expression. That brings all the ETs to DualQuaternion. Benoit > > gael > >>>> The classic Grahm schmidt has a very poor numerical stability. It can >>>> be modified to run in a stable manner, but there is ~2x operation >>>> penalty. >>> >>> Not when the matrix was already very close to being orthogonal, as is >>> the case here if you re-normalize frequently enough. In that case, >>> Gram-Schmidt is fine. But that is OT, as indeed it's never as good a >>> solution as quaternions. >>> >>>> >>>> Another good point. What do you think of the current unit tests? >>> >>> sorry, haven't had time to look at it carefully. >>> i guess the cout's aren't there to stay, for the rest i need to read >>> it carefully, have to run now... >>> >>> Benoit >>> >>> >>> >> >> >> >> -- >> Rohit Garg >> >> http://rpg-314.blogspot.com/ >> >> Senior Undergraduate >> Department of Physics >> Indian Institute of Technology >> Bombay >> >> >> > > >

**Follow-Ups**:**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Rohit Garg

**References**:**[eigen] Rigid Transformations in eigen: discussion thread***From:*Rohit Garg

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Benoit Jacob

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Rohit Garg

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Benoit Jacob

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Rohit Garg

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Benoit Jacob

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Rohit Garg

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Benoit Jacob

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Rohit Garg

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Gael Guennebaud

**Messages sorted by:**[ date | thread ]- Prev by Date:
**[eigen] Dev branch: Name clash with termios system header** - Next by Date:
**Re: [eigen] Rigid Transformations in eigen: discussion thread** - Previous by thread:
**Re: [eigen] Rigid Transformations in eigen: discussion thread** - Next by thread:
**Re: [eigen] Rigid Transformations in eigen: discussion thread**

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