-
-
Notifications
You must be signed in to change notification settings - Fork 204
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
test_position_of_radec failure on 32bit arm and s390x #784
Comments
The native IEEE double precision is nominally 2^-53, which is 1.1e-16. If one is lucky and all information is kept in the registers (which may have e.g. 80 bits like it had in the the M68k series), and one does not use compiler options that enforce IEEE compatibility, this sort of relative accuracy can be achieved. If the processor is moving all the floating point numbers in and out of memory, because it does not have many registers, a precision of 1.e-16 is almost impossible to keep. Backports that emulate 32-bit systems are also likely to get exactly a 64-bit lookalike output (I haven't looked into the armel specs, though). So to keep tests compatible with all sorts of host systems, I'm usually taking 1.e-15 as reasonable error margins in my coding. |
Thanks for the feedback @rmathar. If all agree on it I could provide a small PR. |
I think I have a branch somewhere that reduces several test thresholds—the Anaconda packaging folks, I think, may have asked for it so the tests could pass on some other platforms they test? But I got bogged down this summer with other responsibilities, and haven't gotten back to it yet. Based on branch names, my guess is that this is my most recent work: https://github.com/skyfielders/python-skyfield/tree/fix-float And this might have been an even earlier attempt? https://github.com/skyfielders/python-skyfield/tree/precisions I wish Python and NumPy would use IEEE compatibility options when compiling, it would make it easier to write programs that print the same output on different platforms! |
As we have recently addressed this problem in fac3cff, I am going to go ahead and close this issue now. |
Recently I packaged skyfield for debian and I'm having some failures of the
test_position_of_radec
test on some architectures:It seems that it is mostly a matter of floating point accuracy.
Does it make sense to relax the error threshold form 1e-16 to e.g. 3e-16?
The text was updated successfully, but these errors were encountered: