[tests] failures against 32bit arches

[stanislavlevin]

Tests suite of haversine 2.8.1 fails on 32bit systems with:

=================================== FAILURES ===================================
________________________________ test_pair[km] _________________________________

unit = <Unit.KILOMETERS: 'km'>

    @pytest.mark.parametrize(
        'unit', [Unit.KILOMETERS, Unit.METERS, Unit.INCHES]
    )
    def test_pair(unit):
        def test_lyon_paris(unit):
            expected_lyon_paris = EXPECTED_LYON_PARIS[unit]
            assert haversine_vector(LYON, PARIS, unit=unit) == expected_lyon_paris
            assert isinstance(unit.value, str)
            assert haversine_vector(
                LYON, PARIS, unit=unit.value) == expected_lyon_paris

>       return test_lyon_paris(unit)

tests/test_haversine_vector.py:19: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

unit = <Unit.KILOMETERS: 'km'>

    def test_lyon_paris(unit):
        expected_lyon_paris = EXPECTED_LYON_PARIS[unit]
>       assert haversine_vector(LYON, PARIS, unit=unit) == expected_lyon_paris
E       AssertionError: assert array([392.21725956]) == 392.2172595594006
E        +  where array([392.21725956]) = haversine_vector((45.7597, 4.8422), (48.8567, 2.3508), unit=<Unit.KILOMETERS: 'km'>)

tests/test_haversine_vector.py:14: AssertionError
_________________________________ test_pair[m] _________________________________

unit = <Unit.METERS: 'm'>

    @pytest.mark.parametrize(
        'unit', [Unit.KILOMETERS, Unit.METERS, Unit.INCHES]
    )
    def test_pair(unit):
        def test_lyon_paris(unit):
            expected_lyon_paris = EXPECTED_LYON_PARIS[unit]
            assert haversine_vector(LYON, PARIS, unit=unit) == expected_lyon_paris
            assert isinstance(unit.value, str)
            assert haversine_vector(
                LYON, PARIS, unit=unit.value) == expected_lyon_paris

>       return test_lyon_paris(unit)

tests/test_haversine_vector.py:19: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

unit = <Unit.METERS: 'm'>

    def test_lyon_paris(unit):
        expected_lyon_paris = EXPECTED_LYON_PARIS[unit]
>       assert haversine_vector(LYON, PARIS, unit=unit) == expected_lyon_paris
E       AssertionError: assert array([392217.2595594]) == 392217.2595594006
E        +  where array([392217.2595594]) = haversine_vector((45.7597, 4.8422), (48.8567, 2.3508), unit=<Unit.METERS: 'm'>)

tests/test_haversine_vector.py:14: AssertionError
________________________________ test_pair[in] _________________________________

unit = <Unit.INCHES: 'in'>

    @pytest.mark.parametrize(
        'unit', [Unit.KILOMETERS, Unit.METERS, Unit.INCHES]
    )
    def test_pair(unit):
        def test_lyon_paris(unit):
            expected_lyon_paris = EXPECTED_LYON_PARIS[unit]
            assert haversine_vector(LYON, PARIS, unit=unit) == expected_lyon_paris
            assert isinstance(unit.value, str)
            assert haversine_vector(
                LYON, PARIS, unit=unit.value) == expected_lyon_paris

>       return test_lyon_paris(unit)

tests/test_haversine_vector.py:19: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

unit = <Unit.INCHES: 'in'>

    def test_lyon_paris(unit):
        expected_lyon_paris = EXPECTED_LYON_PARIS[unit]
>       assert haversine_vector(LYON, PARIS, unit=unit) == expected_lyon_paris
E       AssertionError: assert array([15441624.39210257]) == 15441624.392102592
E        +  where array([15441624.39210257]) = haversine_vector((45.7597, 4.8422), (48.8567, 2.3508), unit=<Unit.INCHES: 'in'>)

tests/test_haversine_vector.py:14: AssertionError

...

FAILED tests/test_haversine_vector.py::test_pair[km] - AssertionError: assert...
FAILED tests/test_haversine_vector.py::test_pair[m] - AssertionError: assert ...
FAILED tests/test_haversine_vector.py::test_pair[in] - AssertionError: assert...

[jdeniau]

Hi,

It does seems to be a floating point precision exception if I read it right, isn't it?

Noob question : do we still need to handle 32 bits in 2024? If we do, I do not know if we need to fix the test by testing the architecture (which seems pretty useless because the test will just match the expectation) or the code (but it may be really hard to have the same value)

[stanislavlevin]

Hi,

It does seems to be a floating point precision exception if I read it right, isn't it?

Looks like.

Noob question : do we still need to handle 32 bits in 2024? If we do, I do not know if we need to fix the test by testing the architecture (which seems pretty useless because the test will just match the expectation) or the code (but it may be really hard to have the same value)

I'm talking as ALTLInux packager, my distro does support i586 so far.

32bit is dying. But for example, there are major Linux distros that fully support i586 like Debian or OpenSUSE or partially like Fedora (RPM packages are built for i586).

I noticed that the tests started to fail with the newest version and decided to inform upstream that either the expectations are incorrect or it's the product's bug.

[jdeniau]

Could you make a bisection to detect which commit introduced this regression?

Thanks

[stanislavlevin]

It's related to numpy or one of its dependencies.

haversine 2.8.0 was tested against numpy 1.22.1 and the aforementioned test passed (when I packaged it 1 year ago).

But now it fails against numpy 1.26.4 absolutely the same as 2.8.1. So it's not related to this project directly (not regression).