>> > [...] >> > >> >>> >> >>> 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, 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
