On 7/26/11 11:43 PM, Luc Maisonobe wrote: > 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.
+1 > >>> - modify the Rotation class to use this quaternion, with the CCSDS >>> convention > > Non. > +1 >>> - 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. +0 - should definitely not be in g.e.threed; but complex is not a perfect fit either. What exactly are the expected applications? If there are enough of them to include the new object, it may make sense to just make quaternion its own package, which could arguably fit inside a) linear, b) geometry or c) complex. I suspect the primary applications are likely going to be in geometry, so it may make sense to place them there. Phil > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
