MNT: Cleanup infs handling in np.testing assertion utilities #29321
Conversation
|
Can you elaborate a little bit more about what is broken in the current inf handling and what this PR does exactly to fix it? It's not clear to me just looking at the diff here. |
ad2317f to
260cddd
Compare
|
It's not totally clear to me: is it possible for this change to cause tests that previously passed to start failing with a numpy version that includes this change? Or similarly, for a test that used to fail to start passing? If it's the latter, was the failure that happened before actually a bug? Or is it that this is a purely internal change that can't change the behavior of the numpy's testing utilities? |
No.
The first commit in the PR demonstrates a case of Other than that, there should be no impact on |
|
Ah, I missed that you have really detailed commit messages in your commits. In the future I encourage you to include that information in your PR description or at least clearly note the commit messages have extra context. Normally on github I assume commit messages don't have useful information, so I tend to just look at the PR description. |
numpy/testing/_private/utils.py
Outdated
| else: | ||
| assert infs_mask.all() | ||
|
|
||
| # For details on the work-arounds employed here, see func_assert_same_pos above |
There was a problem hiding this comment.
Might it be worth factoring out these two functions? They seem identical except for the part that gets added to err_msg.
There was a problem hiding this comment.
Extracted robust_any_difference for the significant part of the logic
| assert_allclose(a, b) | ||
|
|
||
| b = np.array([3.]) | ||
| expected_msg = 'inf location mismatch:' |
There was a problem hiding this comment.
Here and below I would just put expected_msg inside the pytest.raises statement, as there is no reason for escaping, so it easily fits on one line. Less clutter.
There was a problem hiding this comment.
I think it's a bit nicer to keep it the same pattern as everywhere else in the file
Also, does a colon not require escaping in a regex? Who knows? :)
You can skip subsets of the CI too, if you don't want everything to run: https://numpy.org/doc/stable/dev/development_workflow.html#commands-to-skip-continuous-integration |
|
The CI failure looks real but unrelated to this change |
Recently, numpy#29112 added showing first mismatches indices, but assert_array_almost_equal.compare trips it up by returning a shape different from its input, causing an IndexError: ``` <...> if invalids.ndim != 0: if flagged.ndim > 0: > positions = np.argwhere(np.asarray(~flagged))[invalids] E IndexError: boolean index did not match indexed array along axis 0; size of axis is 3 but size of corresponding boolean axis is 2 ``` (traceback shown using pytest --full-trace)
A nice cleanup (newer, similar inf handling already exists now in assert_array_compare), and resolves the shape mismatch issue. However, the removed logic was handling complex infs while the one isn't, causing the new test and an existing one (TestInterp::test_complex_interp) to now fail with RuntimeWarnings attempting to subtract the complex infs.
assert_array_compare now tests all inf values for matching position and value, including complex infs. Fixes the failing tests.
The behavior for real infs is the same is before. For complex infs, demonstrates that the behavior for mismatching values is now cleaner, showing a concise error message vs. previously displaying nan max errors. For complex infs with matching values, the behavior is the same as before, accepting them as equal (although internally they would now be filtered ahead of being passed to isclose, like real infs already had been).
e8e1fbd to
86417f3
Compare
|
Thanks! The refactoring made this (even) nicer. Let's get it in. |
Besides just being a nice cleanup, a specific motivation is towards reporting max errors indices (#28827). Without this change,
assert_array_almost_equal.comparecan produce an output shape different from its input, requiring additional logic to produce the correct indices in the original array.Note: This PR is based over #29318 commits because it somewhat depends on it. It's probably better to review #29318 before this one.