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

[Rohit Garg <rpg.314@xxxxxxxxx>]

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

Wait, we saw that fixed size vectorizable types don't play nice with
Map. You saw that a Vector4i wasn't getting vectorized when I mapped a
block of memory to it.
>
> 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.

I don't understand. If I just return say m_coeffs + other.m_coeffs,
wouldn't that bring et to dualquats? The return type is of course
changed to Coefficients and we provide an assignment operator from
Coefficients to DualQuaternion.

After all, the real evaluation is happening in the = operator right.
>
> 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
>>>
>>>
>>>
>>
>>
>>
>
>
>



-- 
Rohit Garg

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

Senior Undergraduate
Department of Physics
Indian Institute of Technology
Bombay