Re: [eigen] Rotations and unit vectors

[Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>]

On 17.05.2013 10:45, Gael Guennebaud wrote:
> Even though there is a related bug entry, I continue here to give it
> more visibility.

I added a dependency between these bugs, but also continue detailed 
discussion here.

> Actually, a quick look at the current Quaternion class make me think
> that we should be able to generalize the current Quaternion class to
> be of general purpose without breaking or penalizing existing code.
> Only a few members would be marked as deprecated with an advise to
> move to the UnitQuaternion class. They include:

Yes, deprecating some of the methods is probably the way with the least 
harm.
The alternative would be to introduce a new class GeneralQuaternion and 
define the current Quaternion class to be a unit Quaternion (with 
assertions) -- this would most likely effect much less users, but we 
will give up API compatibility for them.

> - conversions from/to rotation matrices

I would not see a problem with conversion from rotation matrices. The 
same as I would of course allow "conversion" from UnitQuaternion to 
Quaternion.

> - slerp
> - setFromTwoVectors
> - angularDistance
> - operator*(vector)
>
> We should also think about the conversion from Quaternion to
> UnitQuaternion. For instance:
>   - Shall Quaternion::normalized() returns a UnitQuaternion? I guess not.

I would not see a problem with that, as the back-conversion to a general 
Quaternion is free. Actually, I would see this as a very clean way to 
initialize a UnitQuaternion from a non-unit 4d-vector:
  UnitQuaternion q1 = Quaternion(w,x,y,z).normalized();
// And if w,x,y,z are known to be normalized already:
  UnitQuaternion q2(w,x,y,z);

Actually looking at that, I see a unique opportunity to change the 
inconsistency:
  Quaternion(w,x,y,z)==Quaternion(Vector4(x,y,z,w))
I.e., we could make the new UnitQuaternion behave the same way for 
initializing from data pointers and from 4 scalars (but we would need to 
introduce another class for the GeneralQuaternion, as well)
However, I'm afraid that changing that would (at least temporarily) add 
more confusion than it solves.

>   - The conversion from a Quaternion to a UnitQuaternion should
> probably trigger an implicit normalization that could be avoided via a
> Quaternion::asUnitQuaternion() cast function?

Hm, not entirely sure about the implicit normalization. By the same 
reasoning all constructors should implicitly normalize (instead of 
assert, as currently proposed). I would slightly prefer to only assert 
unity when assigning Quaternion to UnitQuaternion -- but I'm not 
entirely fixed on that opinion.

Regards,
Christoph


--
----------------------------------------------
Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
Cartesium 0.049
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen

Tel: +49 (421) 218-64252
----------------------------------------------