commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luc Maisonobe (JIRA)" <>
Subject [jira] [Commented] (MATH-1302) Rotation constructor with RotationOrder and angles produces wrong rotation
Date Mon, 21 Dec 2015 09:22:46 GMT


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

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

What would you think about we add an enumerate, which could be for example VECTOR_OPERATOR_CONVENTION

> Rotation constructor with RotationOrder and angles produces wrong rotation
> --------------------------------------------------------------------------
>                 Key: MATH-1302
>                 URL:
>             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

View raw message