The first thing that comes to my mind when I think game programming is: N-to-1 mappings and fractals. And I’m sure you do too. (For improved cache accesses)
(P.S. I wouldn’t have started a new thread…but what 'cha gonna do?)
Would be cool if you had some kind of image(s) showing off the principle behind the mathematical symbol-magic (in other words: code). 
Also, maybe a very tiny use-case example could help, too 
What are these for?
I’ve only stuck up Morton for the moment but:
Pictures/Wikipedia:
CDF Player required (https://www.wolfram.com/cdf-player/):
http://demonstrations.wolfram.com/HilbertAndMooreFractalCurves/
http://demonstrations.wolfram.com/Lebesgue3DCurves/
http://demonstrations.wolfram.com/WunderlichCurves/
http://demonstrations.wolfram.com/HilbertAndMoore3DFractalCurves/
Wolfram/Alpha:
Say you have a 2D data set which you flatten into an array or some other linear storage. For simplicity it’s a square with power-of-two height/width = D. The common indexing will be [icode]index=(D*y+x)[/icode]. This is pretty good. It’s a 2-to-1 mapping that’s compact (there’s no wasted space). I’ll call this row-linear just to give it a name.
Now it’s common if you examine some cell (x,y) that the next cell(s) you’re going to visit are going to be close to cells you’ve already looked at recently. With row-linear the next cell is going to be very close in memory if it’s a horizontal displacement. But it’s not very hot if (say) you’re walking vertically. A simple alternate indexing scheme would be a reflected row-linear. So the first row is (x), second is (2D-x-1), third is (2D+x), forth (4D-x-1), etc. This simplifies but it’s not a very interesting scheme.
So enter space-filling-curves and other 2-to-1 mappings. Talking about exact properties of each actually isn’t very useful because “to do the math” requires knowing average (or worst case) access patterns and details of the target hardware’s memory architecture. Pure PITA. Schemes that are potentially worth considering will good locality. Morton is nice and simple to compute…esp incrementally. So basically you layout the data in some alternate indexing scheme in an attempt to move less memory.
What kind of gains can one expect? Small. You’re explicitly reading and writing the same amount of memory and performing the same amount of work at each cell. If you want real speed gains this isn’t the place to look. Any speed gains stem from moving less memory around in the memory architecture. One thing to note is that all the gains are not local the “thread” where this is occurring…the reduced pressure on memory allows other threads to progress (assuming they’re accessing). What I’m only single threaded! ORLY? You at least have two more: GC and compiler.
I’ve added a few comments and I’ll toss together a RayGrid2D example.
I might particularly have use for these mappings at some point… a way down the line, when I’m really scraping the barrel for performance optimisations. My 2D maps are 256x256 in size, and each cell is a long (packed bits representing 12 fields), and I’ve got say 4…8 threads accessing it, for maybe 6,000 entities or so, usually not in a random fashion but scanning. It’d be interesting if there was some sort of visual system to represent cache misses and so on with respect to the usage of a data structure.
Cas
That’s the spirit! And the exact use case.
Quickly banged out: https://github.com/roquendm/JGO-Grabbag/blob/master/src/roquen/interp/IndexedRayGrid2D.java