|Re: [eigen] Rotations and unit vectors|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
On 17.05.2013 10:45, Gael Guennebaud wrote:
Even though there is a related bug entry, I continue here to give it
I added a dependency between these bugs, but also continue detailed
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
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
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:
Actually looking at that, I see a unique opportunity to change the
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.
Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
Tel: +49 (421) 218-64252