8000 BUG: missing exception in `test_unary_PyUFunc_O_O_method_full[reciprocal]` on osx with 1.21.5 · Issue #20637 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

BUG: missing exception in test_unary_PyUFunc_O_O_method_full[reciprocal] on osx with 1.21.5 #20637

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
h-vetinari opened this issue Dec 21, 2021 · 11 comments
Closed

BUG: missing exception in test_unary_PyUFunc_O_O_method_full[reciprocal] on osx with 1.21.5 #20637

h-vetinari opened this issue Dec 21, 2021 · 11 comments
Labels
00 - Bug

Comments

@h-vetinari
Copy link
Contributor
h-vetinari commented Dec 21, 2021 •
edited
Loading

Building 1.21.5 for conda-forge, there was the following error on osx:

=================================== FAILURES ===================================
_____ TestUfuncGenericLoops.test_unary_PyUFunc_O_O_method_full[reciprocal] _____

self = <numpy.core.tests.test_ufunc.TestUfuncGenericLoops object at 0x11037da50>
ufunc = <ufunc 'reciprocal'>

    @pytest.mark.parametrize("ufunc", UNARY_OBJECT_UFUNCS)
    def test_unary_PyUFunc_O_O_method_full(self, ufunc):
        """Compare the result of the object loop with non-object one"""
        val = np.float64(np.pi/4)

        class MyFloat(np.float64):
            def __getattr__(self, attr):
                try:
                    return super().__getattr__(attr)
                except AttributeError:
                    return lambda: getattr(np.core.umath, attr)(val)

        num_arr = np.array([val], dtype=np.float64)
        obj_arr = np.array([MyFloat(val)], dtype="O")

        with np.errstate(all="raise"):
            try:
>               res_num = ufunc(num_arr)
E               FloatingPointError: invalid value encountered in reciprocal

MyFloat    = <class 'numpy.core.tests.test_ufunc.TestUfuncGenericLoops.test_unary_PyUFunc_O_O_method_full.<locals>.MyFloat'>
num_arr    = array([0.78539816])
obj_arr    = array([0.7853981633974483], dtype=object)
self       = <numpy.core.tests.test_ufunc.TestUfuncGenericLoops object at 0x11037da50>
ufunc      = <ufunc 'reciprocal'>
val        = 0.7853981633974483

../[...]/lib/python3.10/site-packages/numpy/core/tests/test_ufunc.py:172: FloatingPointError

During handling of the above exception, another exception occurred:

self = <numpy.core.tests.test_ufunc.TestUfuncGenericLoops object at 0x11037da50>
ufunc = <ufunc 'reciprocal'>

    @pytest.mark.parametrize("ufunc", UNARY_OBJECT_UFUNCS)
    def test_unary_PyUFunc_O_O_method_full(self, ufunc):
        """Compare the result of the object loop with non-object one"""
        val = np.float64(np.pi/4)

        class MyFloat(np.float64):
            def __getattr__(self, attr):
                try:
                    return super().__getattr__(attr)
                except AttributeError:
                    return lambda: getattr(np.core.umath, attr)(val)

        num_arr = np.array([val], dtype=np.float64)
        obj_arr = np.array([MyFloat(val)], dtype="O")

        with np.errstate(all="raise"):
            try:
                res_num = ufunc(num_arr)
            except Exception as exc:
>               with assert_raises(type(exc)):

MyFloat    = <class 'numpy.core.tests.test_ufunc.TestUfuncGenericLoops.test_unary_PyUFunc_O_O_method_full.<locals>.MyFloat'>
num_arr    = array([0.78539816])
obj_arr    = array([0.7853981633974483], dtype=object)
self       = <numpy.core.tests.test_ufunc.TestUfuncGenericLoops object at 0x11037da50>
ufunc      = <ufunc 'reciprocal'>
val        = 0.7853981633974483

../[...]/lib/python3.10/site-packages/numpy/core/tests/test_ufunc.py:174:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
../[...]/lib/python3.10/unittest/case.py:226: in __exit__
    self._raiseFailure("{} not raised".format(exc_name))
        exc_name   = 'FloatingPointError'
        exc_type   = None
        exc_value  = None
        self       = <unittest.case._AssertRaisesContext object at 0x11037ddb0>
        tb         = None
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <unittest.case._AssertRaisesContext object at 0x11037ddb0>
standardMsg = 'FloatingPointError not raised'

    def _raiseFailure(self, standardMsg):
        msg = self.test_case._formatMessage(self.msg, standardMsg)
>       raise self.test_case.failureException(msg)
E       AssertionError: FloatingPointError not raised

msg        = 'FloatingPointError not raised'
self       = <unittest.case._AssertRaisesContext object at 0x11037ddb0>
standardMsg = 'FloatingPointError not raised'

../[...]/lib/python3.10/unittest/case.py:163: AssertionError

I skipped it for the time being, but wanted to raise this issue. I also verified in conda-forge/numpy-feedstock#237 that it is (unlike some recent scipy failures) not dependent on the blas flavour being used.
@h-vetinari
Copy link
Contributor Author

Note that the failure happens for none of the other parametrizations of test_unary_PyUFunc_O_O_method_full, only for reciprocal.

@h-vetinari
Copy link
Contributor Author

Also of note, the same error does not appear or 1.22.0, see conda-forge/numpy-feedstock#248

@mattip
Copy link
Member
mattip commented Dec 21, 2021

I seem to remember some announcement about macOS version on some CI system changing, might that be involved?

@h-vetinari
Copy link
Contributor Author
h-vetinari commented Dec 21, 2021 •
edited
Loading

I seem to remember some announcement about macOS version on some CI system changing, might that be involved?

Not that I'm aware of. In fact - AFAIK - it's everything but OSX that has changed... 😅

(at least on the conda-forge side)

@seberg
Copy link
Member
seberg commented Dec 21, 2021

The test result here is a bit confusing. The problem has nothing to do with the object loop, the problem is that reciprocal([np.pi/4]) issues an incorrect floating-point warning.

The horror of testing FPE's... considering how bad many systems and compilers are still with it :(. This looks a lot like the "typical" clang vectorization optimization bug (especially on older clang's) that was fixed in a few places by adding a volatile (so that the optimizer doesn't think it can just work with garbage in the SIMD registers)

@seberg
Copy link
Member
seberg commented Dec 21, 2021

Wait, I guess this should be: #19926 but that is not backported (not sure we should).

@h-vetinari
Copy link
Contributor Author

Wait, I guess this should be: #19926 but that is not backported (not sure we should).

Not sure, because it was on osx-x64 and not on osx-arm, but in any case, I agree that it's not worth a backport. It doesn't even need any action at all IMO - I consider it marginal enough that I felt comfortable in skipping that test.

@seberg
Copy link
Member
seberg commented Dec 21, 2021

That PR fixes a two dimensional problem :). There is the dimension of compiler version (which apparently may need to check whether its apple or not) and also the hardware. Presumably you are running __clang_major__ < 10 or __apple_build_version__ < 12000000.

@h-vetinari
Copy link
Contributor Author

Presumably you are running __clang_major__ < 10

I don't pretend to understand the problem, but just to note that conda-forge currently compiles with clang 11 on OSX (and uses libcxx 12 & llvm-openmp 12 at runtime)

@h-vetinari h-vetinari mentioned this issue Dec 28, 2021
Closed
@h-vetinari
Copy link
Contributor Author

Since this is fixed with 1.22 and can be worked around or 1.21, I'm leaning to close this issue. Are there any other concerns?

@seberg
Copy link
Member
seberg commented Jan 4, 2022

Agreed, will close. If anyone feels particularly strongly about backporting, feel free to look into it. Although I doubt that it is likely that there will be another 1.21 release at this point.

@seberg seberg closed this as completed Jan 4, 2022
@nieder nieder mentioned this issue Nov 27, 2022
Open
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
3 participants
@seberg @mattip @h-vetinari
0