Do Matlabs 3D plots swap axes?

Dear all,

I am very confused by Matlab's 3D plotting functions (surf, plot3). Consider the following MWE:

>> [X,Y] = meshgrid(1:20,1:20);
>> Z = sin(X) + cos(Y);
>> Z(1,end)=10;
>> surf(X,Y,Z)
>> xlabel('x')
>> ylabel('y')

I expected the command Z(1,end)=10; to set a peak at the first value of the x axis and the last value of the y axis. However, it generates the following plot, in which the axes seem to be flipped. Please point me to my error. I can reproduce this behavior for plot3 as well.

Answer 1

[Stephen23]

The confusion occurs because X and Y do not correspond to rows and columns (i.e. dimensions 1 and 2) of the plotted matrix, which is what you are assuming. In MATLAB, as is the standard in mathematics, the first dimension corresponds to the rows, the second the columns, the third the pages, etc. of an array/matrix:

https://www.mathworks.com/help/matlab/math/multidimensional-arrays.html

which means, for example, that a matrix with size 2x3 has two rows and three columns. Note how these do NOT correspond to X and Y!

However some people prefer to think of the first dimension as being left/right and the second up/down (i.e. X and Y), but note that this swaps the roles of the first two dimensions (because how they are stored does not match how they are displayed)! In any case, to make it easy for users wanting to treat X and Y as the first two dimensions, functions like meshgrid support this: you can see in dpb's example that X actually increases along the second dimension, whereas Y increases along the first dimension.

The solution is to either

• change all mathematics to consider the columns as the first dimension and rows as the second (unlikely), or
• understand that in MATLAB (like all mathematics) matrix rows are encoded by the first dimension and columns by the second, and this means when you think in terms of X and Y you will need to transpose their roles in your matrices (much easier).

Note that meshgrid is limited to 2/3 dimensions, because this is typically what people want when they work in terms of X and Y (and Z). But there is also a completely consistent function ndgrid, which does not swap role the first two dimensions, and operates up to as many dimensions as you want to. If you look carefully at some examples of ndgrid and meshgrid you will see that the first two dimensions of meshdrigd's output are the odd ones out (basically swapped around), whereas in every case the Nth output of ndgrid increases along the Nth dimension.

[Walter Roberson]

For cartesian coordinates, mathematics uses x first, to mean distance left/right. But when people build tables, they prefer to talk about row number first and then column number "Go down to line 35, column 7".

I gather that historically tables were not arranged that way, but that it changed when people moved from scroll format to folio (cut page) format.

[Stephen23]

"For cartesian coordinates, mathematics uses x first, to mean distance left/right"

I guess the tendency to list the independent variable first is the cause of putting X first when discussing plots, which restricts the coordinates to having X horizontally. Perhaps if we used a different notation for writing maths (e.g. output first) this would be different and we would consider the dependent variable as the X axis. Or is there a tendency for humans to prefer the horizontal axis as the independent variable, similar to how most scripts are written horizontally? In any case, clearly the order of matrix indices and the order of coordinate systems developed independently from one another.

"I gather that historically tables were not arranged that way, but that it changed when people moved from scroll format to folio (cut page) format."

Sounds feasible. I was just trying to hunt down some good sources on this history of the matrix indexing standard: do you happened to know any?

[Jan]

@Stephen: Ha, cool. I gave you 2 votes!

The servers are slow today. It seems to be easy to cause uncaught some racing condition. We have some threads with 2 accepted answers also. This means, that Matlab Answers is not an ACID prove database. Well, the state of the art is something else.

Answer 2

[dpb]

Not the way meshgrid is laid out -- look at a small enough space you can see it easily (and also not symmetric so can tell who's who in the zoo):

>> [X,Y]=meshgrid(1:4,1:6)
X =
     1     2     3     4
     1     2     3     4
     1     2     3     4
     1     2     3     4
     1     2     3     4
     1     2     3     4
Y =
     1     1     1     1
     2     2     2     2
     3     3     3     3
     4     4     4     4
     5     5     5     5
     6     6     6     6
>>

The location you're looking for is Z(end,1) instead of Z(1,end)

[Jannis]

Okay, but this seems very unintuitive to me. The problem is, that it leads to wrong interpretations based on the plot. If I am interested in the position of the maximum and I see above plot I'd be tempted to say that it occurs at an (x_ind,y_ind) = (20,1).

However:

   >> [min,ind] = max(Z(:));
   >> [x_ind,y_ind] = ind2sub(size(Z),ind);

gives me (1,20). In order to get the proper results (20,1) you need to do:

>> x_ind_true = X(x_ind,y_ind);
>> y_ind_true = Y(x_ind,y_ind);

Omitting this can be source of error for people semi-confident with Matlab.

[Walter Roberson]

I find meshgrid() to be frustrating, and always feel as if it is giving the first two outputs in the wrong order. I always prefer to use ndgrid().

The only way I can explain meshgrid() is to mumble to myself that it is trying to compensate for the fact that in MATLAB images, X is the second dimension (columns) and Y is the first dimension (rows); meshgrid() feels like a hack to silently allow people to get away with treating X as if it were the first dimension.

[Stephen23]

"... always feel as if it is giving the first two outputs in the wrong order."

They are!

• With ndgrid the Nth output increases along the Nth dimension.
• With meshgrid the first two outputs are swapped: the first output increases along the second dimension and the second output increases along the first dimension (but the third is consistent!). Blame the mathematicians who decided that rows come first!

[Jan]

The unexpected order of outputs concerns gradient also.

[dpb]

I didn't say was intuitive, only that's the way meshgrid has always worked... :)

I don't know, but I strongly suspect it exists as is simply owing to historical reasons that it was introduced that way initially probably without a tremendous amount of thought regarding the order peculiarity.

NDGRID came along somewhat later albeit still a long time back but did fix the inconsistency.

Probably would be worthy of a documentation improvement suggestion to make specific note of the difference in MESHGRID() similar to that in NDGRID that specifically notes the difference. Although MESHGRID describes the output, it isn't easy to decipher from just the words...

Have to admit I've never really thought about it too much; the general purpose is to simply display a surface and the specifics of how the ordering was arranged for the purpose hasn't ever really cropped up as an issue...