Skip to content
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

[Bug] masking of NaN Z values in pcolormesh #5451

Merged
merged 1 commit into from Nov 11, 2015

Conversation

andim
Copy link
Contributor

@andim andim commented Nov 9, 2015

In pcolormesh non-finite values (e.g. NaNs) are not currently masked. The function allows the input of masked arrays, so there is an easy workaround of masking the array before passing it in (see http://stackoverflow.com/questions/7778343/pcolormesh-with-missing-values). It would make more sense IMHO, though, to mask the array internally as is done in imshow. This would fix what I believe is a bug, namely that the autoscaling of the Z axis does not work if the array contains NaNs.

@efiring
Copy link
Member

efiring commented Nov 9, 2015

That's reasonable, but I think that instead of putting the safe_masked_invalid call in pcolormesh it should go in two places (check--this is based on a very quick look) in _pcolor_args so that it will be applied to the whole pcolor family.

@andim
Copy link
Contributor Author

andim commented Nov 9, 2015

Thanks for the quick reply!

You mean putting the check before both of the returns in _pcolor_args I suppose? I was afraid that some of the other pcolor functions might not be able to handle a masked array, but if this is not the case then I'll indeed move the call to safe_masked_invalid up there.

@efiring
Copy link
Member

efiring commented Nov 9, 2015

In the development of mpl, masked array support predates nan support, which is the reason there are still places like this that need safe_masked_invalid added.

@tacaswell tacaswell added this to the proposed next point release (2.1) milestone Nov 11, 2015
@tacaswell
Copy link
Member

@efiring I could go either way on backporting this to 2.0.x

@efiring
Copy link
Member

efiring commented Nov 11, 2015

@andim Looks good. Would you mind squashing the two commits down to one and force-pushing?

@andim
Copy link
Contributor Author

andim commented Nov 11, 2015

I had some trouble at first (I'm new to this more advanced git features), but it should be ok now with the latest commit. Thanks again for your comments and looking forward to seeing this fixed.

efiring added a commit that referenced this pull request Nov 11, 2015
[Bug] masking of NaN Z values in pcolormesh
@efiring efiring merged commit 5ac32f3 into matplotlib:master Nov 11, 2015
@efiring
Copy link
Member

efiring commented Nov 11, 2015

@andim Thanks for your contribution!

@Alexander-Barth
Copy link

@tacaswell It would be great if this feature could be back-ported to 2.0 (except when 2.1 will be released soon). It would help a lot of users coming from Matlab.
(I have to change the coded in my local copy of matplotlib and it does exactly what I wanted. But if I want to share code with my colleagues using features from an not yet released version of matplotlib is not really an option.)

@tacaswell
Copy link
Member

The current goal is 2.1 RC in the next month or so.

@Alexander-Barth
Copy link

OK, great! Thank you for the information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants