-
-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2.4.1: test_rotation fails on ppc64le #78
Comments
mesh.vectors when created:
mesh.vectors after -= .5:
mesh.vectors after 1st rotate:
mesh.vectors after 2nd rotate:
mesh.vectors after 3rd rotate:
mesh.vectors after += .5:
|
Well... I wouldn't really call it broken, this is simply the result of floating point inaccuracy. The test is just a bit too strict and doesn't account for floating point inaccuracies. Apparently the ppc64le platform uses a slightly different floating point implementation within numpy. It might be related to this: numpy/numpy#10281 Since I don't have access to a ppc64le machine I can't easily fix this (or at least, not test it) but something like this might do the trick: assert (mesh.vectors - numpy.array([
[[1, 0, 0], [0, 1, 0], [0, 0, 0]],
[[0, 1, 0], [1, 0, 0], [1, 1, 0]],
[[0, 1, 1], [0, 1, 0], [1, 1, 1]],
[[1, 1, 0], [0, 1, 0], [1, 1, 1]],
[[0, 0, 1], [0, 1, 1], [0, 1, 0]],
[[0, 0, 1], [0, 0, 0], [0, 1, 0]],
])).sum() < 0.0001 |
I'm playing with numpy.isclose to check if the result is close :) |
Didn't know of the existence of |
|
|
On some platforms, a regular (a == b).all() might not work doe to float32 not being very precise. In one particular case, also lower the tolerance for allclose, because on ppc64le 3 rotations are enough to divert too much from the mathematically correct result. We cannot increase the precision, because STL has 32bit floats. Fixes wolph#78
On some platforms, a regular (a == b).all() might not work due to float32 not being very precise. In one particular case, also lower the tolerance for allclose, because on ppc64le 3 rotations are enough to divert too much from the mathematically correct result. We cannot increase the precision, because STL has 32bit floats. Fixes wolph#78
On some platforms, a regular (a == b).all() might not work due to float32 not being very precise. In one particular case, we also increase the tolerance for allclose(), because on ppc64le 3 rotations are enough to divert too much from the mathematically correct result. We cannot increase the precision, because STL has 32bit floats. Fixes wolph#78
I'm not familiar with ppc64le that much, but apparently something is broken here:
I'll try to see at what point the result is wrong.
The text was updated successfully, but these errors were encountered: