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

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

On Fri, Sep 18, 2009 at 2:01 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2009/9/18 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> 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/.
>
> OK
>
>>
>> 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).
>
> I think it's worth doing the same for Quaternion for consistency.

I agree on the consistency reason.

> If
> DualQuaternion has an operator+, then Quaternion should too. Rohit
> mentioned that nlerp is also wanted for Quaternion. Then there is the
> question of whether it should return by value or using your trick,
> well i think that your trick brings more benefits (e.g. mapping
> expressions) so once we have the DualQuaternion impl it's worth
> porting to Quaternion... also it's a more consistent API: if
> DualQuaternion can Map any xpr, so should Quaternion.

Note that mapping the coefficients of a Quaternion or DualQuaternion
seems to be quite dangerous because this assume a convention for the
storage order of the coeffs and there is no such standard.

gael