[ https://issues.apache.org/jira/browse/MATH1157?page=com.atlassian.jira.plugin.system.issuetabpanels:commenttabpanel&focusedCommentId=14161848#comment14161848
]
Luc Maisonobe edited comment on MATH1157 at 10/7/14 12:50 PM:

I don't think it is a real problem.
What happens here is simply floating point accuracy which is not absolute.
Under the hood, the Rotation class does not use matrices but a more efficient way based on
quaternions. This implies that the rotation you define has the following components: q0 =
0.984807753012208, q1 = 0, q2 = 0, q3 = 0.17364817766693033. The expression computing .applyInverseTo
is a combination of q0, q1, q2, q3 and your vector x, y, z. The z component is:
(2 q0 q2) x + (2 q0 q1) y + (2 q0 q0  1) z + 2 q3 s
where s = q1 x + q2 y + q3 z
In your case, q1 and q2 are 0, and floating points multiplications and additions involving
0 are exact, so in your specific case, (and only in this specific case) the z component is
(2 (q0^2 + q3^2)  1) z. As a rotation quaternion is normalized, this should be equal to
z since q1 and q2 are 0. however, the floating point numbers q0 and q3 are not perfect, and
the multiplicative factor for z is not exactly 1 but is rather 1epsilon where epsilon is
the gap between 1 and the primitive double number just below 1. This means that the values
q0 and q3 were already computed to the full accuracy of the computer. I have checked them
using our Dfp high accuracy numbers class, and in fact the error in q0 is about 3.905e17
and the error in q3 is about 1.767e17, so it is not possible to have better values for q0
and q3, we are already at the limit of the primitive double.
Do you agree with this explanation? Can we solve the issue as "Not A Problem"?
was (Author: luc):
I don't think it is a real problem.
What happens here is simply floating point accuracy which is not absolute.
Under the hood, the Rotation class does not use matrices but a more efficient way based on
quaternions. This implies that the rotation you define has the following components: q0 =
0.984807753012208, q1 = 0, q2 = 0, q3 = 0.17364817766693033. The expression computing .applyInverseTo
is a combination of q0, q1, q2, q3 and your vector x, y, z. The z component is:
(2 q0 q2) x + (2 q0 q1) y + (2 q0 q0  1) z + 2 q3 s
where s = q1 x + q2 y + q3 z
In your case, q1 and q2 are 0, and floating points multiplications and additions involving
0 are exact, so in your specific case, (and only in this specific case) the z component is
(2 (q0^2 + q3^2)  1) z. As a rotation quaternion is normalized, this should be equal to
z since q1 and q2 are 0. however, the floating point numbers q0 and q3 are not perfect, and
the multiplicative factor for z is not exactly 1 but is rather 1epsilon where epsilon is
the gap between 1 and the primitive double number just below 1. This means that the values
q0 and q3 were already computed to the full accuracy of the computer. I have checked them
using our Dfp high accuracy numbers class, and in fact the error in q0 is about 3.905e7 and
the error in q3 is about 1.767e17, so it is not possible to have better values for q0 and
q3, we are already at the limit of the primitive double.
Do you agree with this explanation? Can we solve the issue as "Not A Problem"?
> problem with the rotation
> 
>
> Key: MATH1157
> URL: https://issues.apache.org/jira/browse/MATH1157
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 3.3
> Environment: Windows 7, Eclipse, Java SE 1.7
> Reporter: Frank A
> Priority: Critical
> Labels: newbie
> Fix For: 3.4
>
>
> Hello,
> this is my problem:
> myAngle = 0.3490658503988659
> The angle is created with FastMath.toRadians(20).
> myRotation = new Rotation(RotationOrder.XYZ, 0, 0, myAngle);
> if I use this on my Vector3D myVector = new Vector3D(4,4,4) with myRotation.applyInverseTo(myVector)
I'm get the result
> x = 5.1268510564463075
> y = 2.390689909840958
> z = 3.999999999999999 (using the .getX() getY() and getZ() functions)
> Im working with double values, but after the rotation just around the axis z, the z value
of my vector shouldn't have changed, but it does. Maybe it is not a bug but a wrong result
after a simple rotation, or did I use the rotation in a wrong way?
> Best regards
> Frank

This message was sent by Atlassian JIRA
(v6.3.4#6332)
