8000 Fix various bugs in np.ma.where by eric-wieser · Pull Request #8647 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

Fix various bugs in np.ma.where #8647

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

Merged
merged 1 commit into from
Apr 4, 2017
Merged

Conversation

eric-wieser
Copy link
Member
@eric-wieser eric-wieser commented Feb 20, 2017

This fixes #8599, #8600, and np.ma.where not preserving subclasses and #5826

This is an accidental reimplementation of #5827

@eric-wieser eric-wieser force-pushed the np.ma.where-fixes branch 2 times, most recently from 29d0340 to c9607e7 Compare March 7, 2017 23:58
@eric-wieser eric-wieser requested review from mhvk and removed request for mhvk March 8, 2017 00:00
Fixes numpy#8600 and numpy#8599
Also makes np.ma.masked work with structured dtypes.
@eric-wieser eric-wieser requested a review from mhvk March 8, 2017 00:30
@eric-wieser
Copy link
Member Author

Sorry about that, unexpectedly caused some tests to fail when trying to clean something up in the rebase

Copy link
Contributor
@mhvk mhvk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This all looks good. For subclasses, one now has the problem as np.where itself doesn't do subclasses correctly, but that is obviously outside of scope for this PR.

@mhvk mhvk added this to the 1.13.0 release milestone Mar 11, 2017
@mhvk mhvk added the 09 - Backport-Candidate PRs tagged should be backported label Mar 11, 2017
@eric-wieser
Copy link
Member Author
eric-wieser commented Mar 11, 2017

For subclasses, one now has the problem as np.where itself doesn't do subclasses correctly

Although that would then lead to confusion when np.where(masked_arrays) returns a masked array that doesn't have the correct mask.

So if np.where supporting subclasses is risky, perhaps supporting subclasses here is also the wrong thing to do, since it's hard to conceive of a useful subclass that would keep information without having a chance to __array_wrap__

@eric-wieser
Copy link
Member Author

Do you want me to revert that last commit then?

@mhvk
Copy link
Contributor
mhvk commented Mar 26, 2017

@eric-wieser - I have no strong feelings about this. Overall, a well-written class with a good __array_finalize__ just might work OK with your new construct (given a working np.where), and I don't really see any downside, so let's just stick with what you have. If you agree, then I think this is ready to go in (but if you prefer just to do the first commit, that is fine too)

@eric-wieser
Copy link
Member Author
eric-wieser commented Mar 27, 2017

I think I can be convinced to keep this, in the case of something like a MaskedQuantity subclass that just needs to copy metadata?

@eric-wieser
Copy link
Member Author

@mhvk: I rolled back that last commit - I think np.where not supporting subclasses is a strong argument that np.ma.where shouldn't either.

@eric-wieser
Copy link
Member Author

@mhvk: Tests all pass - good to merge?

@mhvk
Copy link
Contributor
mhvk commented Apr 4, 2017

Great! Merging...

@mhvk mhvk merged commit c4f1dec into numpy:master Apr 4, 2017
@charris charris modified the milestones: 1.12.2 release, 1.13.0 release May 13, 2017
@charris charris removed the 09 - Backport-Candidate PRs tagged should be backported label Sep 22, 2017
@charris charris removed this from the 1.12.2 release milestone Sep 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BUG: np.ma.where does not broadcast correctly
3 participants
0