This is a general question, I’m not seeking help with anything specific.

The linear algebra convention for matrix indices is (row, column), which is also the case in julia (and matlab). So why does julia (and matlab) assign columns as dimension 1, and rows as dimension 2 for permutedims and the like? It seems non-intuitive and inconsistent.

For array dimensions greater than 2, the dimension number and index order line up again - it’s just the first two that have reversed labelling.

I get that arrays are stored column major, and that each consecutive index represents a more “zoomed out” view of the memory layout. But in a high level language that really shouldn’t be very important.

Am I missing some insight? Maybe just a matlab carryover?

This is something that has gotten me confused many times as well.
AFAICT When we say column major it means that all entries of the first column are a contiguous block of memory and then all other columns in order (+ higher dimensions)
Therefore the fast changing first index ( dim=1) describes the nth entry within the first column.

This can be confusing as the nth entry in a column refers to a row. So column major only refers to the memory layout.

I don’t really see what you mean. They seem to me to line up correctly. The first index is row, the second is column, just like in linear algebra, and in every programming language I know of. And the length of the first dimension is equal to the number of rows, the length of the second is equal to the number of columns, and the length of the third dimension is equal to the number of ‘frames’, or whatever you want to call it.

Can you explain in more detail what you mean? And what programming languages do it differently?

Edit: OK, I’m not well today, so I missed your point being about permutedims, but upon inspection, I don’t see any strange behaviour there either. Do you have an example?

And the length of the first dimension is equal to the number of rows, the length of the second is equal to the number of columns, and the length of the third dimension is equal to the number of ‘frames’, or whatever you want to call it.

OK, that’s a great explanation and I’m satisfied, thanks.

The confusion was coming from things like fft(A,1) and fft(A,2) acting on the columns and rows of A, respectively, which seems reversed. But after thinking about it more carefully, fft(A,1) is really a DFT of the “rows”, applied independently over each column. Makes sense.

OK, I’m not well today, so I missed your point being about permutedims , but upon inspection, I don’t see any strange behaviour there either.

No, permutedims was just an arbitrary example of a function that considers “dimensions”. Sorry for the red herring.