>> > [...]
>> >
>> >>>
>> >>> 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.
>As it can be defined in the same terms as a complex number, without
referring to geometry, I wouldn't say that that >package is the best
fit.
>From Wikipedia (first sentence):
> "In mathematics, the quaternions are a number system that extends the
> complex numbers."
>From MathWorld (in the first paragraph):
> "[..] and the quaternions are a single example of a more general class
of
> hypercomplex numbers discovered by Hamilton."
>I don't think that there should be a package for each class:
> complex.Complex
> quaternion.Quaternion
>What next?
>If implemented, all "hypercomplex" classes should feel at home in the
"complex" package.
+1 : I agree with you : the Quaternion should be in complex package,
since the object we want to implement is a pure mathematical object,
even if it is often used for geometry purpose.
About the fact to build (or not..) the Rotation upon the new Quaternion
(cf Luc's mail), I agree that's make another layer and may damage
performance. On the other hand, that duplicates some lines of code
between the two class. As there are not too many lines dealing with
quaternion in the rotation, we may choose Luc's solution (only add a
getter for the rotation quaternion, that builds a Quaternion on the
fly).
The last point is the name of the getter, because getQ() would return a
rotation quaternion (CCSDS Rotation) and it may confuse the users if
getQ0/Q1/Q2/Q3 and getQ return opposite quaternions.
> Maybe a "getRotationQuaternion" would be more appropriate ? What do
you think ?
Best regards,
Yannick
>Gilles

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
