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*: Thu, 24 Sep 2009 11:36:41 -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=xJyLs8Fe/0NOIW1+y8DzqI4Ht5fuLJlmd0a5j4EDSjY=; b=u7rzRli341yf2fPHAGqjrVX7I4lJM++wBCQSU2UO4d/QgtywMTmm+qJH1F4dv2P2sE w7JQ9mP4Nc/ZWB4DOo6brapI/CdeLHf8dG/0VtXvRHXSJqROZpX85ni/3n2Mn8skxRti vEVu+SA2aVGG6O5yEOAlfyu5MSR/92srvzol8=*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=WmSbmklHcQdcIokrc9WLh2BaBgnbFwoZjwBI3oW5P6hXQrUi2yc07HPLHTdlHpRNCD tAzYmFQxKZZwQvnrJITkuUyiIxXDfq4LNd2gIF6mDY1SeElVowVXfzD/V6oTg5cW2nB4 zyFamlrgFYX4mPci1X/Ffe8+luRdAR3OcO6DY=

Just a last note: if you feel blocked by having to implement this expression-templates thing for DualQuaternions and Quaternions, then don't; instead, as far as I'm concerned, it's OK for me to have naive operator+ etc... just returning by value, as a temporary measure. Like in your original patch. I wasn't OK initially because I thought that we didn't want to allow non-unit quaternions, hence no operator+. It's been clear in this discussion that we actually want to allow operator+ etc... and from there, where the implementation naively returns by value or does expression templates, is only an implementation detail. Benoit 2009/9/18 Rohit Garg <rpg.314@xxxxxxxxx>: > On Fri, Sep 18, 2009 at 5:26 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote: >> 2009/9/18 Rohit Garg <rpg.314@xxxxxxxxx>: >>>>> 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. >> >> Yes, there is a limitation with Map vectorization at the moment, so >> reinterpret_cast is still useful, just letting you know that at least >> it will be possible to use Map as another solution. > I think this limitation should be removed, even if we dont go the map > route here. >> >>>> >>>> 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? >> >> It would be inconvenient, because then doing >> >> (dualquat1 + dualquat2).someDualQuatMethod() >> >> wouldn't work. And more generally, one wishes that doing dualquat1 + >> dualquat2 returns a "dualquat expression", something that really >> behaves like a dualquat. > > :( > > You are right. We want a sum expression to be actually a sum. >> >> Benoit >> >> >> > > > > -- > Rohit Garg > > http://rpg-314.blogspot.com/ > > Senior Undergraduate > Department of Physics > Indian Institute of Technology > Bombay > > >

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

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] port of (c)minpack to eigen : status** - Next by Date:
**Re: [eigen] New contributors section** - 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/ |