Why does pcolor not display the full matrix?

There are several questions on here asking why pcolor does not display the full matrix. Most answers say something along the lines of "use image/imagesc instead". And then other people jump in and say pcolor is more powerful (because it allows irregularly spaced grids). In my case, I use irregularly spaced grids to display geophysical modelling results so image/imagesc does not work. Some people suggest first interpolating your irregularly-spaced data and then using image/imagesc. But, for me, the actual x and y vectors matter a lot (e.g. the location of a given model cell is very important).

I understand that pcolor removes the right column and the top row.

My question is: Why does this happen? Is this a feature or a bug?

From the pcolor help:

"The grid covers the region X=1:n and Y=1:m, where [m,n] = size(C)."

Maybe I'm misunderstanding, but doesn't the grid cover the region X = 1:n-1 and Y=1:m-1? Why does it say it covers the full region if, in reality, it cuts off the top row and right column of the data matrix?

To me this is a bug that should be fixed and everyone seems to complain about it. But I figure there must be some deeper reason why it is not (or can't be) fixed.

Here's an example script:

%Some irregularly spaced vectors:
x = [0.5 0.8 1 1.6];
y = [1.2 1.4 2 2.2];

%Some data
r = ones(4,4); %Size = 4 by 5
r(1,1) = 3;
r(4,4) = 10;
r(2,2) = 10;

pcolor(x,y,r)
colorbar

% r(2,2) is in the correct spot
% and you can see r(1,1) as well.
% But you cannot see r(4,4) = 10

Answer 1

[Steven Lord]

This is not a bug. The perceived bug is the result of the 2-dimensional fencepost error. From the description of the C input argument on the documentation page for the pcolor function:

"The values in C map colors in the colormap array to the vertices surrounding each face. The color of a face depends on the color at one of its four vertices. Of the four vertices, the one that come first in X and Y determines the color of the face. If you do not specify X and Y, MATLAB uses X=1:n and Y=1:m, where [m,n] = size(C). Because of this relationship between the vertex colors and face colors, none of the values in the last row and column of C are represented in the plot."

The values in C do not represent the colors of the faces but represent the colors of the vertices. If you look at the picture included in that input argument description the corresponding C is 3-by-3 but only the four (2-by-2) elements with arrows pointing to the faces are used in determining the colors of the pcolor plot. Similarly, if you wanted to draw a 9-by-9 Sudoku grid on a piece of paper you need to draw 10 horizontal and 10 vertical lines to fully enclose the 81 squares where numbers would be placed.

[Darcy Cordell]

Why would they write such a convoluted program though? Why require all the nastiness of making the color face depend on the data values at the four vertices?

Why not make pcolor plot the cell faces directly based on the data matrix (as would be much more intuitive) and require the user to input cell edges? If your matrix is size M by N, then you would be required to input vectors of cell edges with length (M+1) and (N+1), respectively.

This would:

(a) avoid the fencepost error

(b) allow full plotting of the data matrix

(c) be more intuitive and;

(d) likely avoid extra computation time when deciding what color to plot.

I assume there must be some deeper reason for the choice of implementation.

[Walter Roberson]

Just make something like imagesc with variable data spacing, how hard can it be?

Use warp()

[Paul]

Coincidentally, I just ran into this exact pcolor v. imagesc issue yesterday. pcolor returns a surface, which gives control over some things that imagesc does not, like EdgeColor.

[Harri Ojanen]

Yet again running into this problem. IMHO this pcolor behaviour is a bug, even if it works as specified (i.e., the specification is wrong). This does not make any sense, why would anyone want it to work like it does?

imagesc is broken, because it does not respect the x and y vectors when those are not uniformly spaced. pcolor is broken as described by the OP. heatmap makes more sense, but has a completely differerent interface and other limitations, e.g., it is not possible to plot other graphics on top of the heatmap (at least hold on gives an error with heatmap).

They are all broken in various ways. I have to implement my own... Wait, someone has already done it, there is sanePColor in file exchange...

[DGM]

It's not a fencepost error until someone starts arguing that the number of posts should equal the number of boards.