[
https://issues.apache.org/jira/browse/MATH-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15066239#comment-15066239
]
Luc Maisonobe commented on MATH-1302:
-------------------------------------
No. The order is the right one.
What you present is a very well known consequence of a convention that is
already explained at length in the Javadoc.
You can look at the javadoc of the Rotation(Vector axis, double angle)
constructor.
We *know* some people do not like this convention.
The problem is that a rotation can be considered either as a vector operator
that moves vectors with respect to a fixed
reference frame, or it can be seen as a frame conversion operator that moves
frames while vectors are kept fixed.
Suppose that for example we simply state: rotation r is a 90 degrees rotation
around the Z axis. Using the first
convention (fixed frame, moving vectors), the image of vector with coordinates
(1, 2, 3) would be vector (-2, 1, 3).
This means that the vector rotates counterclockwise. Using the second
convention (the frames rotates), then
the image of vector with coordinates (1, 2, 3) would be vector (2, -1, 3)
because the frame rotates counterclockwise,
so the fixed vector appears to rotate in the opposite direction.
Apache Commons Math uses the first convention, because it is focused on
representing a vectorial operator.
The other convention, which Apache Commons Math does not use, is more often
encountered in the following
fields of applications: frames transforms (typically 3D scenes modelization) or
attitude in space flight dynamics.
When people work in these fields (and in fact I do work in space flight
dynamics and attitude), then one as to
be aware of the different conventions and as to think that the angle alpha that
Apache Commons Math expect
is a perfectly well defined angle that is simply the opposite of the one I have
at hand. So when I build my
rotation, I simply have to pass -alpha, and when I retrieve the angle using
getAngle, I have to change its
sign after retrieval.
As this topic comes back from time to time, we *may* add an enumerate for
specifying the convention in the
two constructors involved (one axis and one angle or one rotation order and
three angles) and the symmetrical
getters. However, simply changing from one convention to the other without any
hint for the user to which
convention is used is not gonna happen. There are no reasons why the other
convention is right and the
current convention is wrong. They are simply that: conventions. They are
relevant in different fields of
applications.
What would you think about we add an enumerate, which could be for example
VECTOR_OPERATOR_CONVENTION
and FRAMES_CONVERSION_CONVENTION?
> Rotation constructor with RotationOrder and angles produces wrong rotation
> --------------------------------------------------------------------------
>
> Key: MATH-1302
> URL: https://issues.apache.org/jira/browse/MATH-1302
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: James Boyer
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Rotation constructor taking (RotationOrder, double, double, double) has the
> local variable "composed" set to an incorrect rotation because the use of r1
> and r3 are swapped.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
