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

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

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).

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