I sort of agree with the author that N>3 dimensional arrays are cumbersome in numpy, that said I think this is partly because we are really not that great thinking in higher dimensions. I'm interested what the authors solution to the problem is, but unlike the author I'm not a big fan of the eigen notation, but maybe I just don't use it often enough. I don't see the issue with a[:,:,None] notation and that's never given me issues, however I agree about the issue with index arrays. I often make something which think should work and then need to go back to the documentation to realise no that's not how it works.
The inconsistency for argument naming is also annoying (even more if we include scipy), e.g. why is it np.fft.fft(x, axis=1) but np.fft.fftshift(x, axes=1)?!
> we are really not that great thinking in higher dimensions.
Normally when you've hit 4d arrays, are you not dealing with a grid of grids?
That is say you've got a 2×3×4×5 array, another way to think about that is you've got a 2×3 matrix of 4×5 matrices. (APL example to show what I mean: https://tryapl.org/?clear&q=%7B%E2%8D%B5%2C%E2%8D%A5%E2%8A%8...)
I agree in principle, but if you try to do operations about submatrices (and in a way that's what the article is about) it gets tricky quite quickly. I actually often find it even harder to understand if there are multiple nested loops, but that might also be because I use numpy much more often.
> That is say you've got a 2×3×4×5 array, another way to think about that is you've got a 2×3 matrix of 4×5 matrices.
No, a grid of grids is the same thing as a grid.
You can lay out some 4×5 matrices within a 2×3 pattern to have something to look at, but the result is significantly less structured than the 4-dimensional space that the array represents.
***** ***** *****
*A*** ***** *****
***** ***** *****
***** ***** *****
***** ***** *****
***** ***** *****
***** ***** *****
***** **B** *****