Hi Yannick and Gilles,
Le 27/07/2011 00:37, Gilles Sadowski a écrit :
Hello.
In project SIRIUS (CNES), we would like to slightly modify the Rotation
class so it can fit our needs, and to create an independant Quaternion
class.
- Quaternion : We need to separate these two notions : the quaternion
and the rotation representation, because we have to be able to access
directly to a quaternion as a mathematical object, not only as a
rotation quaternion.
Fine.
- Rotation :
- We would like to base the rotation upon the new Quaternion object.
Why ? A rotation quaternion is a special case of a quaternion. It is
normalized and it has the property that Q and -Q represent the same
quaternion, but from a pure quaternion point of view they are different
quaternions. These assumptions are used throughout the Rotation class
(see for example the constructors that add some specific parameters to
deal with normalization.
The fact that Rotation uses quaternion formalism (but for now not an
independent class Quaternion) is an implementation detail and should not
be visible from outside. This is shown by the getters in the class.
There are getters for quaternion components, of course, but there are
also getters for Cardan angles, for Euler angles, for vector and axis
and for matrix, none of them are stored in the instance, they are
recomputed on the fly. We could provide another getQ() getter that would
build the Quaternion on the fly when it is needed.
Adding the Quaternion as the storage part of the Rotation class would
also add another layer, with two different memory handling (which is
significant for very small objects) and two levels of method
delegations. If you look at your other proposal about 3x3 matrices, it
seems rather inconsistent. In this second proposal, you ask for a
specialization to improve performances. Here you already have a highly
performing and validated implementation and you want to add a layer that
is only an implementation detail without user changes (except drop in
performance and need to validate again).
- We would like to use the CCSDS convention (the same as ESA projects)
for the rotation quaternion :
if Q represents a rotation, applied to a vector X giving the
vector X', we have : X' = Q.X.Qt (Qt = conjugate(Q) ).
-> As the actual rotation (based upon 4 double q1/2/3/4) does not use
this convention, we propose to modify the getters/setters (getQi /
setQi) to preserve compatibility and to add a getQ that returns a
quaternion compliant with CCSDS convention.
I would strongly propose to build the quaternion on the fly by simply
adding the Quaternion class and build an instance on the fly when getQ
is called.
Calling getQ is a very rare need and most users directly use the
specialized Rotation operation to deal with rotation, and not with extra
Quaternion only operations, as general quaternion operations are not
Rotation oriented. So it does make sense to build the extra object only
for the very few uses where it is needed (i.e. your uses) and not to
always have this secondary object buried inside the Rotation class where
most users don't need it.
This feature can be summed up in 3 points :
- create a Quaternion class (mathematical object)
Yes.
- modify the Rotation class to use this quaternion, with the CCSDS
convention
Non.
- modify the actual methods in Rotation class to preserve compatibility
Should not be necessary.
The Quaternionn class should be placed in the geometry.euclidian.threed
package.
I'd propose to put it in the "complex" package. It would thus stand out as a
mathematical concept of its own, as you suggest above.
I agree with Gilles here. If you intend to have a quaternion that is the
mathematical object, it should not be in threed. Quaternions in 3D are
only rotation quaternions. General quaternions are much closer to
Complex as Gilles said or to 4th dimension space, which is probably not
widespread enough to set up a specific package, so they should be elsewhere.
best regards,
Luc
Thanks in advance for your advice about this feature. Please also tell
us the best way to communicate on such features (mailing list or/and bug
tracker ?).
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
