plt.pcolormesh stopped working with Masked Arrays

[divenex]

plt.pcolormesh does not work any more with Numpy Masked Arrays, as of Matplotlib 2.1.0

import matplotlib.pyplot as plt
import numpy as np

x = np.linspace(0,1,10) 
xx, yy = np.meshgrid(x, x)
xx = np.ma.masked_array(xx, mask=xx>0.5)
yy = np.ma.masked_array(yy, mask=xx>0.5)
plt.pcolormesh(xx, yy, xx*yy)

produces the error

File "Miniconda3\lib\site-packages\matplotlib\pyplot.py", line 3167, in pcolormesh ret = ax.pcolormesh(*args, **kwargs)
File "Miniconda3\lib\site-packages\matplotlib\__init__.py", line 1710, in inner return func(ax, *args, **kwargs)
File "Miniconda3\lib\site-packages\matplotlib\axes\_axes.py", line 5636, in pcolormesh
coords = np.column_stack((X, Y)).astype(float, copy=False)
TypeError: astype() got an unexpected keyword argument 'copy'

The example works as expected without using Numpy Masked Arrays. And indeed one can check that the np.astype does not accept the keyword copy for Masked Arrays.

This problem seems related to #9577

Matplotlib version

• Operating system: Tested on both Windows and Ubuntu
• Matplotlib version: 2.1.0
• Matplotlib backend: Qt5Agg
• Python version: 3.6.3
• Matplotlib installed via Anaconda

[jklymak]

Thanks for the bug report... Looks like #8801 caused this as well as what I fixed in #9168.

[jklymak]

Fixed in #9722

[efiring]

Unlike pcolor, pcolormesh isn't designed to work with masked arrays for x and y--they are supposed to be supported only for the c array:

       *C* may be a masked array, but *X* and *Y* may not.  Masked
        array support is implemented via *cmap* and *norm*; in
        contrast, :func:`~matplotlib.pyplot.pcolor` simply does not
        draw quadrilaterals with masked colors or vertices.

So I think the real bug is that we are not properly checking for the existence of masked or invalid points in the X and Y inputs; if found, they should trigger an exception. Otherwise, I'm pretty sure that the masks will be discarded silently further down the line, which is not what we want.

[jklymak]

Oh, fair enough! What I did indeed silently drops the mask from the x and y and just uses the underlying values.

So, do we want to do:

1. catch masked arrays as TypeError?
2. silently ignore (or log) the mask?

[jklymak]

Just to be clear, 1. is unfortunately an API change to bring the code in line w the docs. 2. keeps the API the same, but allows it to contravene the docs.

[efiring]

3. If X or Y are masked arrays, see if they have masked points; if they do, raise a ValueError, otherwise use asarray to convert them to unmasked arrays. Possible addition: first use safe_masked_invalid, so that any nans or infs will also be caught early.

I would not support option 2, so I think it is between 1 and 3, or some minor variation on these. Originally we considered it the responsibility of the user to pay attention to the docs and to ensure they supplied sensible and supported inputs; increasingly we have been putting in validation steps. Options 1 and 3 are simply two such approaches, with 3 being more complex but more user-friendly.

I'm OK with either; it might make sense to start with 1. It's simple and consistent with the docstring. I suppose the downside is that it might break some existing code that was relying on the previous behavior, supplying masked arrays that happen to have valid values behind the mask.

Option 1 leaves the documented API intact, but breaks the effective API; Option 3 changes the documented API, but essentially leaves the effective API.

[jklymak]

I’m fine with 3 as well. I’ll hold off on a new PR in cases someone else wants to chime in.