BUG: assert_equal/assert_array_equal now handle NaN in object arrays (gh-9023) - #32661
Open
BHUVANSH855 wants to merge 1 commit into
Open
BHUVANSH855 wants to merge 1 commit into
BHUVANSH855 wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR summary
numpy.testing.assert_equalandassert_array_equalraise a spuriousAssertionErrorwhen comparingdtype=objectarrays containingNaNvalues in matching positions, even though the two arrays are otherwise identical:This closes gh-9023.
assert_equal/assert_array_equalalready treat matching-position NaNs as equal for numeric dtypes (via a NaN-position check inassert_array_compare), but that check is gated by anisnumber(x) and isnumber(y)condition that excludesdtype=objectarrays entirely, sodtype=objectarrays fall through to a plain==comparison, andnan != nanunder IEEE-754 semantics then triggers a false mismatch.This PR adds an
isobject(x) and isobject(y)branch toassert_array_compare, parallel to the existing branches fornumeric, time, and vstring dtypes. Since
np.isnandoesn't supportdtype=object, NaN-detection for this branch uses each element's self-inequality (v != v), guarded with atry/exceptso non-comparable objects don't raise.Scope note:
assert_allcloseondtype=objectarrays has a related but distinct failure (TypeErrorfromisfinitenotsupporting
dtype=object, reported in gh-25496). That failure occurs even on object arrays with no NaN at all, since it comes fromnp.isclose's internal use ofisfinite, not from the NaN-position gating this PR touches. Fixing it would require changes tonp.iscloseitself or a fallback path inassert_allclose'scompare(), which is out of scope here — I've left it for gh-25496.A regression test (
test_object_array_nan_items) is added, verifying both that matching-NaN object arrays compare equal and that a genuine mismatch is still correctly caught.First time contributor introduction
Started contributing to NumPy a few days ago, and main aim it to learn more, enhance my knowledge and to help team to clear their issue triaging backlog.
AI Disclosure
No AI tool is used.