commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] Adding a Quaternion class and modifying the Rotation class
Date Wed, 27 Jul 2011 06:43:46 GMT
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message