|Re: [eigen] Rigid Transformations in eigen: discussion thread|
[ Thread 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:07:00 +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=RO3LxiZkCSXkIgzeSAtZAJN+a2sYggvcIYoLLPFvjds=; b=i69NNjUqJ4WAZDRvSVSzNF/2gJo/JKECWwlmAWhyQbHGoAIm4LFpUwTlpWGto8Oku8 O0khrcIXCvCvmEsPj9Bhq0MCSEX/xyQqzjPzP4N56I+L+ojf1jct7xrjNZrIjd94JfMZ AY7SwrTPpgF3mBy8D7D575WvE5Ch2LQiP7xFs=
- 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=k5pkhCbaA7U9/Kc4GCBBJtZfXa2CLxaDJylAcNpXLFFBC9gmADXbUc7o+d5fI3SXxv Qol2vfqdBjhOyKt4miMJR+0YxBFmPC1ykRHztLr6nXtJv4ailhSUZt9GEMkPPxZ/uUjZ XdDlDWvP33D5EhUaiBtPlEw9R9KMB8CW6HTDA=
On Fri, Sep 18, 2009 at 5:01 PM, Gael Guennebaud
> On Fri, Sep 18, 2009 at 1:01 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> 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.
>> One more remark: one can then remove the Scalar parameter, and deduce
>> it automatically from the CoeffsType as typename CoeffsType::Scalar.
> maybe it is still worth keeping Scalar so that one can easily declare
> a DualQuaternion:
> DualQuaternion<float> dq;
> For an example of this technique have a look at my auto-diff module in
> Finally, do you think Quaternion should be implemented this way as
> well ? I mean for DualQuaternion these two operators are really useful
> (unlike for Quaternion where slerp is really what you should use), and
> since dualquat are larger high efficiency require ET (again unlike
I agree ET are *needed* for dualQuats, but even for normal quats,
there are times (and needs) where a nlerp makes sense.
>> PS. Rohit, if this isn't clear, you can always in a first approach
>> keep the trivial operator+ returning by value and later replace, as
>> that is API compatible.
Department of Physics
Indian Institute of Technology