test_planetarylib.py fails on aarch64

[ggardet]

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] ...............................................................................................................................................................................................

[bnavigator]

See #404 and #411 for a discussion about failing tests due to precision on "exotic" platforms.

[bnavigator]

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.py on openSUSE Tumbleweed: https://build.opensuse.org/request/show/886489

[brandon-rhodes]

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 the rotation_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]

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]

@brandon-rhodes you likely want to use the generic virt board 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]

@ggardet — Thank you! I had looked at the top of the list for anything generic and didn't see it; virt was 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