[
https://issues.apache.org/jira/browse/MATH-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161848#comment-14161848
]
Luc Maisonobe edited comment on MATH-1157 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 1-epsilon 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.905e-17 and the error in q3 is about
-1.767e-17, 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 1-epsilon 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.905e-7 and the error in q3 is about
-1.767e-17, 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: MATH-1157
> URL: https://issues.apache.org/jira/browse/MATH-1157
> 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)
