The changes I am suggesting take care of the case when X and/or Y are logarithmically spaced.
(e.g. visualizing a time series of fractional octave band sound pressure level data. See the following example)

import numpy as np
import matplotlib
import matplotlib.pyplot as plt

time = np.array([0, 1, 2, 3])
freq = np.array([500, 1000, 2000, 4000])
time_mesh, freq_mesh = np.meshgrid(time, freq)
C = np.arange(16).reshape(4,4)

fig, ax = plt.subplots()
im = ax.pcolormesh(time_mesh, freq_mesh, C, dropdata=False)
cbar = fig.colorbar(im)
cbar.set_label('Octave band SPL [dB$_{ref: 20 \mu Pa}$]')

ax.set_xticks(time)
ax.set_yscale('log')
ax.set_yticks(freq)
ax.set_yticklabels(freq)
ax.minorticks_off()
ax.set_xlabel('Time [s]')
ax.set_ylabel('Octave band center frequency  [Hz]')

plt.show()

I like this logarithmic addition! The only thing I'd add is that you can still use the method and calculate dX's even if the points aren't evenly spaced, so the first if statement shouldn't be a requirement. It could just be the default after checking for the ratio.

I don't think this will apply generally enough to be a good approach. If someone needs precision in the cell edges, they should calculate them themselves as they need, not count on matplotlib to do it. This is just a rough fix which is not quite as rough as just dropping the data.

Yeah, there are a whole bunch of cases where this will fail/error out (x = [10, 9, 8]) that we could check for, but I'm not convinced its worth the extra code.

I guess a possibility would be to do the grid interpolation in screen space? Something like... (assuming dropdata=False and the shapes are such that grid interp is necessary)

• convert the x values using the current scale
• if the scaled values are uniformly spaced, do the interp, convert back to data space, use the interp'd grid.
• if not (and an interpolation is necessary), emit a warning (so that users will know to call set_xscale("log") before passing their log-scaled x values

(very rough sketch)

That seems way too fancy and hard to explain to the user. And I'm not even convinced it makes sense for curvilinear grids etc. Lets keep this simple and easy to explain. If the user wants something fancier they can calculate their own edges...

I guess a possibility would be to do the grid interpolation in screen space? Something like... (assuming dropdata=False and the shapes are such that grid interp is necessary)

* convert the x values using the current scale

* if the scaled values are uniformly spaced, do the interp, convert back to data space, use the interp'd grid.

* if not (and an interpolation is necessary), emit a warning (so that users will know to call set_xscale("log") before passing their log-scaled x values

This process could be converted into a helper function which could be showed off in a gallery example/matplotlib blog. If the OP is fine with it, I am interested in working on a PR demonstrating the process outlined here. Does this sound a like a good idea?

Also, I think the method definition for _pcolorargs needs to be updated to include dropdata=True.

What about a different kwarg than dropdata? Maybe something like xyvertices=False, xyedges. Something to insinuate that the current xy are grid points or vertices rather than edges.

Yeah, I see what you mean, but not sure what to do about this. We don't want to imply that we will do anything if len(x)==N+1. I'll propose we keep dropdata for now.

The problem I see with dropdata as the kwarg is that you're actually not just including all of the data, you're also changing the centers/edges of the cells by calculating a midpoint everywhere. In the examples above, the edges were at integers (0, 1, 2) and with this fix they are now at -0.5, 0.5, 1.5 2.5. So the grid has shifted as well. To me, dropdata=False reads like you would have just extended the previous edges to include a new extrapolation point to capture all of the data (0, 1, 2, 3).

xy_centers, xy_midpoints?

If len(x)==N+1 and this kwarg is present, you could raise/warn a user that the combo doesn't make sense.

you're also changing the centers/edges of the cells by calculating a midpoint everywhere.

I'm not calculating the midpoint, I'm calculating the edges, assuming that the given co-ordinates are the midpoint, which I think is what 99.99% of users would expect. The fact is that I think this should be the default behaviour, but thats a whole back compatibility concern.

I agree with what you've said (hence my xy_midpoints suggestion), I wasn't very clear in my description above. I also agree that I think this is what most users would expect. For backwards compatibility, I think it would be fine if this is just an extra option and the default is the previous behaviour.

I agree that the name should be changed. I disagree that this is what users want 99% of the time. Most of the time, imshow() is exactly what those users really need, and is faster to boot. I have been in enough arguments with people about whether coordinates should represent vertices or midpoints to know that it is very dependent upon the particular field you are in and the standard data formats they are usually using most of the time.

I think 0.001% of users expect data to be dropped. As for imshow that is useless for unevenly spaced X or Y.