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*: Rohit Garg <rpg.314@xxxxxxxxx>*Date*: Fri, 18 Sep 2009 17:15:45 +0530*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=ESurPJUv11ql0MuWeoTvex13Y9RwME8dZHy0pqgMWeo=; b=gbJiU/byvd64FXB10GQLv/xjuoy084V7OPwwA3/1sF0z70k3yVc2s0yucnw5LnFUSb uruiu+GUJLL9DEAGz8Y1oPXPtC+NdQRpxYYoBZ7YpSugQoXdSq64K96kHxavLvmgj+Gg AYhuNf3d8PmC8PHFxSN0ihUlp7n60lOJ3w86g=*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=KDSHY9Y847xgmPufqz6UMQgiF/TyTdJRwzTvDtHsUrSBzuxaHCtxpC8y+760UVQS+M 1Per7cub0n9lsISQi+ebSiVXa/NRWML4H9OXZ7VDOHKE6IaUpplAVzAaLoxE/J5zGzZ0 whDl+jUFZ3y2Ww2DigPJVP6WQqkF1qLINaetQ=

>> 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). Wait, we saw that fixed size vectorizable types don't play nice with Map. You saw that a Vector4i wasn't getting vectorized when I mapped a block of memory to it. > > 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. I don't understand. If I just return say m_coeffs + other.m_coeffs, wouldn't that bring et to dualquats? The return type is of course changed to Coefficients and we provide an assignment operator from Coefficients to DualQuaternion. After all, the real evaluation is happening in the = operator right. > > 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 >>> >>> >>> >> >> >> > > > -- 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:*Benoit Jacob

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

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

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Rigid Transformations in eigen: discussion thread** - 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/ |