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 18:43:54 +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=qgzDPleMKZIEw6fYPb8ne4NQ9eTibABHDfCvgaolgqQ=; b=FWDM2H4YUGsNXu8+ASvWQdjFuc03SiYVooQRqj1cUW1Cdd/heqMlC+y5cZDS24xZ4C cVb2JVfPPOf2mO2n6DhYF4EpBC5yoWRvSOEYcy+rUjjXyXJFvTol+vrxvQCJm00EV/k8 SL8QIq/ANe9iUGElSumy4opt5fkhDc3iwA90c=*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=Lt63T31mlnnzyClas3fwgeW/ZnKtgL+Ezq07X3cpwl8JmbT5QlobXBtxf3ph9Ei4L6 ng7T6p6zYp8C18uvdB8DjHRmPkMopDsUUsxSPMmsNZVhCyg1jRJTc5JfmzXwdnSI54Ua tNn22GnaUHyFHJoitdxxmS+Zr2ZG/VlKxc8Dk=

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

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

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