Thanks to visit codestin.com
Credit goes to github.com

Skip to content

BUG: 6 failing tests on RISC-V #26734

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.

Sign up for GitHub

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

Jump to bottom
Closed
bedroge opened this issue Jun 17, 2024 · 8 comments
Closed

BUG: 6 failing tests on RISC-V #26734

bedroge opened this issue Jun 17, 2024 · 8 comments
Labels
00 - Bug

Comments

@bedroge
Copy link

bedroge commented Jun 17, 2024

Describe the issue:

With version 1.26.4 (installed via EasyBuild) I'm getting six test failures on a StarFive VisionFive 2 (RISC-V):

=========================== short test summary info ============================
FAILED core/tests/test_numeric.py::TestBoolCmp::test_float - AssertionError:
FAILED core/tests/test_umath.py::TestFPClass::test_fpclass[-4] - AssertionErr...
FAILED core/tests/test_umath.py::TestFPClass::test_fpclass[-2] - AssertionErr...
FAILED core/tests/test_umath.py::TestFPClass::test_fpclass[-1] - AssertionErr...
FAILED core/tests/test_umath.py::TestFPClass::test_fpclass[1] - AssertionError:
FAILED core/tests/test_umath.py::TestFPClass::test_fp_noncontiguous[f] - Asse...
= 6 failed, 32076 passed, 1746 skipped, 1305 deselected, 31 xfailed, 3 xpassed, 18 warnings in 1008.04s (0:16:48) =

I'm wondering if this is expected and if they can be safely ignored. I found that test_fpclass andtest_fp_noncontiguous were disabled in the CI (#25246), so I assume those are expected to fail (?), but it looks like the first error should have been solved by #25430. Do you know why it may still be failing for me?

Reproduce the code example:

import numpy
numpy.test(verbose=2)

Error message:

=================================== FAILURES ===================================
____________________________ TestBoolCmp.test_float ____________________________

self = <numpy.core.tests.test_numeric.TestBoolCmp object at 0x3fa9a7a8a0>

    def test_float(self):
        # offset for alignment test
        for i in range(4):
            assert_array_equal(self.f[i:] > 0, self.ef[i:])
            assert_array_equal(self.f[i:] - 1 >= 0, self.ef[i:])
            assert_array_equal(self.f[i:] == 0, ~self.ef[i:])
            assert_array_equal(-self.f[i:] < 0, self.ef[i:])
            assert_array_equal(-self.f[i:] + 1 <= 0, self.ef[i:])
            r = self.f[i:] != 0
            assert_array_equal(r, self.ef[i:])
            r2 = self.f[i:] != np.zeros_like(self.f[i:])
            r3 = 0 != self.f[i:]
            assert_array_equal(r, r2)
            assert_array_equal(r, r3)
            # check bool == 0x1
            assert_array_equal(r.view(np.int8), r.astype(np.int8))
            assert_array_equal(r2.view(np.int8), r2.astype(np.int8))
            assert_array_equal(r3.view(np.int8), r3.astype(np.int8))

            # isnan on amd64 takes the same code path
            assert_array_equal(np.isnan(self.nf[i:]), self.ef[i:])
            assert_array_equal(np.isfinite(self.nf[i:]), ~self.ef[i:])
            assert_array_equal(np.isfinite(self.inff[i:]), ~self.ef[i:])
            assert_array_equal(np.isinf(self.inff[i:]), self.efnonan[i:])
>           assert_array_equal(np.signbit(self.signf[i:]), self.ef[i:])

i          = 0
r          = array([False, False, False, False, False, False, False, False,  True,
       False, False, False, False, False, False,... True,  True,
        True,  True, False, False, False,  True,  True,  True,  True,
        True, False, False, False])
r2         = array([False, False, False, False, False, False, False, False,  True,
       False, False, False, False, False, False,... True,  True,
        True,  True, False, False, False,  True,  True,  True,  True,
        True, False, False, False])
r3         = array([False, False, False, False, False, False, False, False,  True,
       False, False, False, False, False, False,... True,  True,
        True,  True, False, False, False,  True,  True,  True,  True,
        True, False, False, False])
self       = <numpy.core.tests.test_numeric.TestBoolCmp object at 0x3fa9a7a8a0>

/nvme/eb/tmp/eb-rmrx9n19/tmp27bs4j4r/lib/python3.12/site-packages/numpy/core/tests/test_numeric.py:516:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

args = (<built-in function eq>, array([False, False, False, False, False, False, False, False,  True,
       False, False, Fa...True,  True,
        True,  True, False, False, False,  True,  True,  True,  True,
        True, False, False, False]))
kwds = {'err_msg': '', 'header': 'Arrays are not equal', 'strict': False, 'verbose': True}

    @wraps(func)
    def inner(*args, **kwds):
        with self._recreate_cm():
>           return func(*args, **kwds)
E           AssertionError:
E           Arrays are not equal
E
E           Mismatched elements: 11 / 256 (4.3%)
E            x: array([False, False, False, False, False, False, False, False,  True,
E                  False, False, False, False, False, False, False, False,  True,
E                  False, False, False, False, False, False,  True,  True, False,...
E            y: array([False, False, False, False, False, False, False, False,  True,
E                  False, False, False, False, False, False, False, False,  True,
E                  False, False, False, False, False, False,  True,  True, False,...

args       = (<built-in function eq>, array([False, False, False, False, False, False, False, False,  True,
       False, False, Fa...True,  True,
        True,  True, False, False, False,  True,  True,  True,  True,
        True, False, False, False]))
func       = <function assert_array_compare at 0x3fac1e7c40>
kwds       = {'err_msg': '', 'header': 'Arrays are not equal', 'strict': False, 'verbose': True}
self       = <contextlib._GeneratorContextManager object at 0x3fac2109e0>

Python and NumPy Versions:

NumPy version 1.26.4

3.12.3 (main, May 23 2024, 16:57:47) [GCC 13.3.0]

Runtime Environment:

No response

Context for the issue:

No response
@bedroge bedroge mentioned this issue Jun 17, 2024
Open
@seberg
Copy link
Member

seberg commented Jun 18, 2024 •
edited
Loading

Yes, these tests were disabled for RISC-V, and if you use NumPy 2, the failures should just not show up. You shouldn't worry about them; RISC-V doesn't propagate the sign of NaNs as much as other architectures, but in normal code the sign of NaN never matters anyway.

It's pretty niche and I am not sure we will have another 1.26 bug-fix release, so going to close, but if anyone asks for it: also happy to backport the PR that disabled these tests on risc-v.

EDIT: Not suggesting to update to NumPy 2 just now. It was just released and has some slightly larger changes, so that may or may not be reasonable for you.

@seberg seberg closed this as completed Jun 18, 2024
@bedroge
Copy link
Author

bedroge commented Jun 18, 2024

Thanks @seberg!

I hadn't found #25280 yet, which seems to solve the other test failures. However, I also just tried to backport that one to 1.26.4, since it's an easy fix, but to my surprise it didn't solve my test failures either. While looking into this a bit more, I found that platform.processor(), which is used to fix some things in that test for RISC-V, returns an empty string on my RISC-V machine:

$ python3
Python 3.12.3 (main, May 23 2024, 16:57:47) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.processor()
''

From what I could find, platform.processor() basically uses uname -p, and that doesn't give any useful output either (and the man page says it's non-portable):

$ uname -p
unknown

So I was going to ask if it would be possible to stick to platform.machine() instead, but I just noticed that this was recently already changed in #26187. So I've tried that, and now everything works fine! 🎉

@seberg
Copy link
Member

seberg commented Jun 18, 2024

@bedroge sounds like a plan, would you be up for making a PR? Since none of us will be able to test it anyway.

@bedroge
Copy link
Author

bedroge commented Jun 18, 2024

@seberg Sure, but what do you mean exactly? Should it backport the changes from #25280 and #26187 to the 1.26.x branch?

@seberg
Copy link
Member

seberg commented Jun 18, 2024

Let's start with making a PR to the main branch tix the platform.machine() vs. processor(). Once that is merged, it would be nice to backport all three (no promise there will be an actual release with it).

@bedroge
Copy link
Author

bedroge commented Jun 18, 2024

So I was going to ask if it would be possible to stick to platform.machine() instead, but I just noticed that this was recently already changed in #26187.

Oh but that was already done in the aforementioned PR. The search only shows two places where platform.processor is still being used, but I don't think those need to be changed: https://github.com/search?q=repo%3Anumpy%2Fnumpy%20platform.processor&type=code

@seberg
Copy link
Member

seberg commented Jun 18, 2024

Ah, OK, misunderstood, I thought there was another follow-up change. So yeah, backporting (if you like), would be just adding those changes to the 1.26.x branch.

@bedroge
Copy link
Author

bedroge commented Jun 18, 2024

Backported the PRs in #26743.

@bedroge bedroge mentioned this issue Jun 18, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
00 - Bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@seberg @bedroge