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

[Rohit Garg <rpg.314@xxxxxxxxx>]

On Fri, Sep 18, 2009 at 5:01 PM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> 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.
>>>
>>> gael
>>
>> 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
> unsupported/.
>
> 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
> Quaternion).

I agree ET are *needed* for dualQuats, but even for normal quats,
there are times (and needs) where a nlerp makes sense.

http://number-none.com/product/Understanding%20Slerp,%20Then%20Not%20Using%20It/
>
> gael.
>
>> Benoit
>>
>> 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.
>>
>>
>>
>
>
>



-- 
Rohit Garg

http://rpg-314.blogspot.com/

Senior Undergraduate
Department of Physics
Indian Institute of Technology
Bombay