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

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

Just a last note:

if you feel blocked by having to implement this expression-templates
thing for DualQuaternions and Quaternions, then don't; instead, as far
as I'm concerned, it's OK for me to have naive operator+ etc... just
returning by value, as a temporary measure. Like in your original
patch.

I wasn't OK initially because I thought that we didn't want to allow
non-unit quaternions, hence no operator+. It's been clear in this
discussion that we actually want to allow operator+ etc... and from
there, where the implementation naively returns by value or does
expression templates, is only an implementation detail.

Benoit

2009/9/18 Rohit Garg <rpg.314@xxxxxxxxx>:
> On Fri, Sep 18, 2009 at 5:26 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> 2009/9/18 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.
>>
>> Yes, there is a limitation with Map vectorization at the moment, so
>> reinterpret_cast is still useful, just letting you know that at least
>> it will be possible to use Map as another solution.
> I think this limitation should be removed, even if we dont go the map
> route here.
>>
>>>>
>>>> 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?
>>
>> It would be inconvenient, because then doing
>>
>>    (dualquat1 + dualquat2).someDualQuatMethod()
>>
>> wouldn't work. And more generally, one wishes that doing dualquat1 +
>> dualquat2 returns a "dualquat expression", something that really
>> behaves like a dualquat.
>
> :(
>
> You are right. We want a sum expression to be actually a sum.
>>
>> Benoit
>>
>>
>>
>
>
>
> --
> Rohit Garg
>
> http://rpg-314.blogspot.com/
>
> Senior Undergraduate
> Department of Physics
> Indian Institute of Technology
> Bombay
>
>
>