-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
Questionable behaviour in MaskedArray.__eq__ on flexible arrays #8589
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.
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
Comments
In the commit pointed too, in another similar change, there is a comment: "# In case we have nested fields..." So, at least that gives a hint why this was introduced. Indeed, one of the test cases shows that it is at least one thing the
In principle, I guess one should really write
But where does the indexing go wrong? I must say having a default of |
Just checking now: my |
Does this mean there is a bug with masked 2D record arrays? |
Yes. What a code... Anyway, fix almost done. |
See #8590 for a fix. |
In the process of trying to fix the "questionable behaviour in `MaskedArray.__eq__`" (numpygh-8589), it became clear that the code was buggy. E.g., `ma == ma[0]` failed if `ma` held a structured dtype; multi-d structured dtypes failed generally; and, more worryingly, a masked scalar comparison could be wrong: `np.ma.MaskedArray(1, mask=True) == 0` yields True. This commit solves these problems, adding tests to prevent regression. In the process, it also ensures that the results for structured arrays always equals what one would get by logically combining the results over individual parts of the structure.
Yes! |
These lines, introduced in a5da87c by @pierregm, appear multiple times in
numpy/ma/core.py
, such asMaskedArray.__eq__
:But where is this
ValueError
expected to come from? The.view
, or the.all
, due to an invalid axis.It seems like there is a bug in the code that prepares
axis
here, and this bug is being silenced by an overzealous try/catch.The text was updated successfully, but these errors were encountered: