Excellent summary! Layout of N-dimensional arrays becomes even more important when you start considering on-disk formats, where seek times are relatively slow.

Excellent summary! Layout of N-dimensional arrays becomes even more important when you start considering on-disk formats, where seek times are relatively slow. People often talk about out-of-core calculations without fully considering how their data is laid out on disk. If your access pattern doesn't match the on-disk ordering of your large, N-dimensional array, you're in for a large surprise. Accessing a portion of an array that takes milliseconds in RAM can easily take multiple hours if you naively write a large multidimensional array to disk with an ordering that doesn't match your access pattern. Of course, this is why chunking exists, but surprisingly few people are as familiar with it as they should be. For example, at work, I often need to use a specific legacy format that's basically a large 3D fortran-ordered array stored on disk. I often get asked why I'm loading the entire thing into memory instead of taking an out-of-core approach. The problem is that our access pattern deals entirely with accessing a single "trace" (z-direction) at a time. For a fortran-ordered array stored on disk, that's the worst-possible access pattern. Each element in a single trace is a long ways apart throughout the entire file. Loading a single trace takes far long than loading the entire file into memory on most (non-SSD) systems. I've recently been on a bit of an evangelical kick for trying to persuade more people to think about the implications of on-disk layout. (For example: http://geology.beer/2015/02/10/hdf-for-large-arrays/ http://geology.beer/2015/02/10/hdf-for-large-arrays/ While that's specifically about HDF5, most of it is explaining memory/disk layout and its implications.)