Repository navigation
test_planetarylib.py fails on aarch64 #582
Description
test_planetarylib.py fails on aarch64.
Distro is openSUSE Tumbleweed.
Log:
[ 58s] + python3.8 -m assay --batch skyfield.tests
[ 61s] .....................................................................................................................................................................................................................................................................................................................................................
[ 61s] -------------------------------- stdout --------------------------------
[ 61s] [1;32m2.8282931552325863e-14
[ 61s] 2.8282931552325863e-14[0m
[ 61s] ------------------------------------------------------------------------
[ 61s] skyfield/tests/test_planetarylib.py line 110 in test_frame_rotation_matrices
[ 61s] [1;35m assert (R == desired_rotation).all()[0m
[ 61s] [1;31mAssertionError[0m
[ 64s] ...............................................................................................................................................................................................
Activity
bnavigator commentedon Apr 18, 2021
See #404 and #411 for a discussion about failing tests due to precision on "exotic" platforms.
bnavigator commentedon Apr 18, 2021
We are now working around the fail on Arm and PPC platforms by
sed -i 's/if IS_32_BIT/if True/' skyfield/tests/test_planetarylib.pyon openSUSE Tumbleweed: https://build.opensuse.org/request/show/886489brandon-rhodes commentedon Jun 13, 2021
Thanks for the report! (Wow, it’s been 2 months? Next time I’ll try replying faster; a vacation intervened.) I am interested in figuring out why other platforms are not performing the same 64-bit IEEE floating point that Skyfield expects of both Python math operators and of results from NumPy.
But at the moment I'm not sure I own any of the hardware that would let me experience one of these platforms first-hand, and brief searches for how to set up something like qemu to let me simulate them locally on another platform make it look like a bit of an effort to get one set up. It might be a while before I have time to tackle that as a project.
If anyone with experience trying to get math to work the same across platform has ideas, I'm interested — or if anyone wants to toss a few
print()statements into therotation_and_rate_at()method called by that test, and figure out where the numbers diverge between i386 and aarch64, then we'd at least know which operation was not running stably.(Come to think of it: I have a little Raspberry Pi that I got once at a conference. I guess I could finally try using it, to run Skyfield!)
brandon-rhodes commentedon Jun 22, 2021
I just took a look at some qemu docs (after realizing that my Pi might not be aarch64 but might be 32 instead; I still haven't had time to dig through the drawer to find it, and get it set up). It says I can't just ask for an aarch64 system, but have to name a specific board?
https://qemu-project.gitlab.io/qemu/system/target-arm.html#choosing-a-board-model
Which board should I choose that would give me an environment tolerably close to the one you are trying to support, @ggardet? Do you know which board, or emulated board, is running those openSUSE tests you cited? Thanks for any guidance!
ggardet commentedon Jun 22, 2021
@brandon-rhodes you likely want to use the generic
virtboard for qemu.Raspberry Pi 2 is armv7 (32-bit) while Raspberry Pi 3 and 4 are both 64-bit. But some distros still runs 32-bit on 64-bit capable RPi which causes some confusions.
brandon-rhodes commentedon Jun 22, 2021
@ggardet — Thank you! I had looked at the top of the list for anything generic and didn't see it;
virtwas hiding down at nearly the very bottom. :)It looks like there are several more steps necessary to getting a development environment up and running, more than I have time to tackle in the few minutes here before my day gets going. But I'll leave this link here for myself that I just found, which might get me going if I return to this with more time later: https://wiki.debian.org/Arm64Qemu
RegularJoe-CEO commentedon Oct 12, 2026
The original
test_frame_rotation_matricesfailure seems to have been fixed by #844 (exact==replaced by tolerances); it passes on arm64 macOS on current master. The one arm64 failure left is intest_velocity_in_ITRF_to_GCRS2(1.801e-11 vs a 1.8e-11 limit), caused by last-ulp differences in the platform libm's sin/cos/atan. Details and a small fix in #1147. If it holds up on Linux aarch64 as well, this issue can probably be closed.