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

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

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.

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

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.

Benoit

>
> 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/
>>
>> Senior Undergraduate
>> Department of Physics
>> Indian Institute of Technology
>> Bombay
>>
>>
>>
>
>
>