Re: [eigen] Rigid Transformations in eigen: discussion thread
• To: eigen@xxxxxxxxxxxxxxxxxxx
• Subject: Re: [eigen] Rigid Transformations in eigen: discussion thread
• From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
• Date: Fri, 18 Sep 2009 11:08:39 +0200

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

>>> The classic Grahm schmidt has a very poor numerical stability. It can
>>> be modified to run in a stable manner, but there is ~2x operation
>>> penalty.
>>
>> Not when the matrix was already very close to being orthogonal, as is
>> the case here if you re-normalize frequently enough. In that case,
>> Gram-Schmidt is fine. But that is OT, as indeed it's never as good a
>> solution as quaternions.
>>
>>>
>>> Another good point. What do you think of the current unit tests?
>>
>> sorry, haven't had time to look at it carefully.
>> i guess the cout's aren't there to stay, for the rest i need to read
>> it carefully, have to run now...
>>
>> Benoit
>>
>>
>>
>
>
>
> --
> Rohit Garg
>
> http://rpg-314.blogspot.com/
>