BUG: reduce using SSE only warns if inside SSE loop#11043
BUG: reduce using SSE only warns if inside SSE loop#11043charris merged 1 commit intonumpy:masterfrom
Conversation
|
also handles case where |
numpy/core/tests/test_regression.py
Outdated
There was a problem hiding this comment.
this test should probably be in the testminmax of numpy/core/tests/test_umath.py
and we have to hope it fpu exceptions work on all platforms properly
There was a problem hiding this comment.
fixed.
One of the CI test platforms is a VM without SSE, so passing this test there means this will warn whenever there is a NAN in the output of a min/max reduce. Note the code in loop.c.src to check that condition.
numpy/core/tests/test_regression.py
Outdated
There was a problem hiding this comment.
You could use the diagflat trick here, maybe with different values of n.
There was a problem hiding this comment.
Maybe let n range through various powers of two, say 8, 16, 32.
There was a problem hiding this comment.
the test is meant to check that a warning is raised for any single NAN no matter where in a vector, the daigflat call would only emit one warning, not n warnings, no?
fixed to let n range through powers of 2
There was a problem hiding this comment.
You can run it with an iterator
for row in diagflat(...):
whatever
|
fixed from reviews, squashed to single commit |
|
MSVC for python < 3.6 gives the wrong result, so it seems PR #11036 is a prerequisite to this one. Edit: link to PR, not issue |
…1036) * BUG: optimizing compilers can reorder call to npy_get_floatstatus * alternative fix for npy_get_floatstatus, npy_clear_floatstatus * unify test with pr #11043 * use barrier form of functions in place of PyUFunc_{get,clear}fperr * update doc, prevent segfault * MAINT: Do some rewrite on the 1.15.0 release notes. [ci skip]
|
#11036 is in. |
|
rebased and updated |
|
Thanks Matti. |
noticed in discussion on #10370
This is a continuation of PR #9020. Note that if/when PR #11036 is accepted and changes the interface for
npy_set_floatstatus*()this PR will need to be updatedEdit: does not affect #11029 , it seems so far there is no relation