trackpy 0.5.0 narrowly fails its tests TestFeatureIdentificationWithVanillaNumpy.test_uncertainty_failure and TestFeatureIdentificationWithNumba.test_uncertainty_failure due to precision issues on an aarch64 linux system. It passes happily on an a86_64 system with an identical build process.
> assert np.allclose(actual[['x', 'y']], expected[['x', 'y']])
E AssertionError: assert False
E + where False = <function allclose at 0xffff98d06670>( x y\n0 13.0 7.012958, x y\n0 13 7)
E + where <function allclose at 0xffff98d06670> = np.allclose
It's not hugely uncommon for x86 systems to have disagreements with other architectures when it comes to float precision - I gather this might be to do with x87 calculations being done to extended 80-bit precision and then truncated.
Thanks for this report — and it's always good to know that (seemingly) everything else does work on arm64. Perhaps we can increase the tolerance just a teensy bit.
trackpy
0.5.0 narrowly fails its testsTestFeatureIdentificationWithVanillaNumpy.test_uncertainty_failure
andTestFeatureIdentificationWithNumba.test_uncertainty_failure
due to precision issues on an aarch64 linux system. It passes happily on an a86_64 system with an identical build process.Full build log available: https://hydra.nixos.org/log/wnim5641b96vp42mimf0wvaypyg26x7q-python3.8-trackpy-0.5.0.drv
It's not hugely uncommon for x86 systems to have disagreements with other architectures when it comes to float precision - I gather this might be to do with x87 calculations being done to extended 80-bit precision and then truncated.