In something which made me spent several hours, I have found an inconsistency in how Matlab deals with dimensions. I somebody can explain to me OR indicate me how to report this to Matlab, please enlight me.

For size, ones,zeros,mean, std, and most every other old and common commands existing inside Matlab, the dimension arrangement is like the classical one and like the intended standard (as per the size of every dimension), the first dimension is along the column vector, the second dimension is along the row vector, and the following are the non graphical following indexes.

>x(:,:,1)=[1 2 3 4;5 6 7 8];
>x(:,:,2)=[9 10 11 12;13 14 15 16];

>m=mean(x,1)
m(:,:,1) = 3     4     5     6
m(:,:,2) = 11    12    13    14

m=mean(x,2)
m(:,:,1) =
    2.5000
    6.5000
m(:,:,2) =
   10.5000
   14.5000

m=mean(x,3)
m =  5     6     7     8
     9    10    11    12

d=size(m)
d =  2     4     2

However, for graphical commands like stream3,streamline and others relying on the meshgrid output format, the dimensions 1 and 2 are swapped!: the first dimension is the row vector and the second dimension is the column vector, and the following (third) is the non graphical index.

> [x,y]=meshgrid(1:2,1:3)
x =  1     2
     1     2
     1     2
y =  1     1
     2     2
     3     3

Then, for stream3 to operate with classically arranged matrices, we should use permute(XXX,[2 1 3]) at every 3D argument:

xyz=stream3(permute(x,[2 1 3]),permute(y,[2 1 3]),permute(z,[2 1 3])...
    ,permute(u,[2 1 3]),permute(v,[2 1 3]),permute(w,[2 1 3])...
    ,xs,ys,zs);

If anybody can explain why this happens, and can indicate to me why this is not a bug, welcome.

CodePudding user response：

This behavior is not a bug because it is clearly documented as the intended behavior: https://www.mathworks.com/help/matlab/ref/meshgrid.html. Specifically:

[X,Y,Z]= meshgrid(x,y,z) returns 3-D grid coordinates defined by the vectors x, y, and z. The grid represented by X, Y, and Z has size length(y)-by-length(x)-by-length(z).

Without speaking to the original authors, the exact motivation may be a bit obscure, but I suspect it has to do with the fact that the y-axis is generally associated with the rows of an image, while x is the columns.

CodePudding user response：

Columns are either "j" or "x" in the documentation, rows are either "i" or "y".

Some functions deal with spatial coordinates. The documentation will refer to "x, y, z". These functions will thus take column values before row values as input arguments.

Some functions deal with array indices. The documentation will refer to "i, j" (or sometimes "i1, i2, i3, ..., in", or using specific names instead of "i" before the dimension number). These functions will thus take row values before column values as input arguments.

Yes, this can be confusing. But if you pay attention to the names of the variables in the documentation, you will quickly figure out the right order.

With meshgrid in particular, if the "x, y, ..." order of arguments is confusing, use ndgrid instead, which takes arguments in array indexing order.