|Re: [eigen] Rotations and unit vectors|
[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]
Hi,I started adding some trivial tests over here: https://bitbucket.org/hauke/eigen_geometry_assertsAs you will see, I did not yet touch the Quaternion class. The reason is that it already allows partial usage as a non-unit Quaternion as Gael mentioned (there exists e.g. a function void normalize()).- HaukeOn Fri, May 17, 2013 at 12:31 PM, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On 17.05.2013 10:45, Gael Guennebaud wrote:I added a dependency between these bugs, but also continue detailed discussion here.
Even though there is a related bug entry, I continue here to give it
Yes, deprecating some of the methods is probably the way with the least harm.
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:
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.I would not see a problem with conversion from rotation matrices. The same as I would of course allow "conversion" from UnitQuaternion to Quaternion.
- conversions from/to rotation matrices
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:
We should also think about the conversion from Quaternion to
UnitQuaternion. For instance:
- Shall Quaternion::normalized() returns a UnitQuaternion? I guess not.
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 inconsistency:
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.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.
- The conversion from a Quaternion to a UnitQuaternion should
probably trigger an implicit normalization that could be avoided via a
Quaternion::asUnitQuaternion() cast function?
Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
Tel: +49 (421) 218-64252
|Mail converted by MHonArc 2.6.19+||http://listengine.tuxfamily.org/|