Z-order curve usage to decrease dimensionality to 1(ssahinkoc.blogspot.com)
ssahinkoc.blogspot.com
Z-order curve usage to decrease dimensionality to 1
https://ssahinkoc.blogspot.com/2017/06/encoding-multi-dimensional-value-into-1.html
34 comments
My favorite has always been Serpinski curve - the math behind Philip Jose Farmer's Riverworld :-) Here, you can print one yourself :-) https://www.thingiverse.com/thing:622627
Usually a Morton ordering is used for things like improving average memory locality of N-dimensional data (e.g., loop iteration order, data layout, ...). But it is average locality that is being improved, because of huge jumps between many neighbors.
In a small number of dimensions, without knowing what search algorithm is being used, this is just more work than comparing the original values. It doesn't mention what "k-NN algorithm" is being used, beyond brute force search.
Lossily compressing N-dimensional data (from 2 to 1000s of dimensions) into a representation that requires fewer bits can be done via quantization as well, either scalar quantization, vector quantization (aka k-means) or product quantization, if your data has known statistics.
It also matters if you are building a static data structure that is queried many times, versus one that needs continual updating.
In a small number of dimensions, without knowing what search algorithm is being used, this is just more work than comparing the original values. It doesn't mention what "k-NN algorithm" is being used, beyond brute force search.
Lossily compressing N-dimensional data (from 2 to 1000s of dimensions) into a representation that requires fewer bits can be done via quantization as well, either scalar quantization, vector quantization (aka k-means) or product quantization, if your data has known statistics.
It also matters if you are building a static data structure that is queried many times, versus one that needs continual updating.
As the first commenter on the site pointed out, the Hilbert Curve is probably a better choice (https://en.m.wikipedia.org/wiki/Hilbert_curve)
Hilbert curve is only useful if the sole goal is sequential storage of point data. Z-curves are superior in almost every other case in real systems due to their unique and efficient computational properties, which many computer scientists are only vaguely aware of.
And since modern spatial database architectures don't sequentialize storage along the curve (because it doesn't make sense as a matter of engineering), the sole selling point of Hilbert curves is moot. You shouldn't design most systems in a way that could exploit the benefits of a Hilbert curve.
And since modern spatial database architectures don't sequentialize storage along the curve (because it doesn't make sense as a matter of engineering), the sole selling point of Hilbert curves is moot. You shouldn't design most systems in a way that could exploit the benefits of a Hilbert curve.
Could you elaborate on your comment about modern spatial databases not sequentializing storage along the curve? I would imagine parallel access across the curve, but wouldn't you want some reasonable sequential access at each cluster node to maximize IO speeds?
I've read your blog entries on SpaceCurve (http://www.jandrewrogers.com/2015/10/08/spacecurve/), found them very interesting but also just whetting the appetite. Are there no public reviews or papers covering discrete topology/sharding?
I've read your blog entries on SpaceCurve (http://www.jandrewrogers.com/2015/10/08/spacecurve/), found them very interesting but also just whetting the appetite. Are there no public reviews or papers covering discrete topology/sharding?
There are two design factors that most people overlook:
Most people know you can use Z/C-curve encodings to dynamically content address point data. There is a (very useful) generalization to hyper-rectangle types, perfect for content-addressing non-point geometries etc, but those types can't be meaningfully sequentialized at all in big systems. Most non-trivial spatial analytics involve non-point geometries, so being able to sequentialize points has limited utility.
Second, the computational cost of sorting along the curve, assuming you are using only points, is prohibitively high for negligible benefit. Modern storage engines use small shards, which are adaptively re-sharded as needed, and medium-sized pages. For insert, the content-addressing mechanic gets you to a single page; it would be significantly more expensive if you were sorting along the curve. For query, the typical selectivity on a shard is so high due to small adaptive shards, that you are better off treating it as an unsorted vector anyway. In short, much slower inserts and few (if any) query benefits.
As an optimization, it tends to only be applicable in cases where the architecture is significantly suboptimal anyway e.g. the use of gigantic shards. You'd get more benefit by fixing the architecture than trying to optimize poor architecture if at all possible.
Most people know you can use Z/C-curve encodings to dynamically content address point data. There is a (very useful) generalization to hyper-rectangle types, perfect for content-addressing non-point geometries etc, but those types can't be meaningfully sequentialized at all in big systems. Most non-trivial spatial analytics involve non-point geometries, so being able to sequentialize points has limited utility.
Second, the computational cost of sorting along the curve, assuming you are using only points, is prohibitively high for negligible benefit. Modern storage engines use small shards, which are adaptively re-sharded as needed, and medium-sized pages. For insert, the content-addressing mechanic gets you to a single page; it would be significantly more expensive if you were sorting along the curve. For query, the typical selectivity on a shard is so high due to small adaptive shards, that you are better off treating it as an unsorted vector anyway. In short, much slower inserts and few (if any) query benefits.
As an optimization, it tends to only be applicable in cases where the architecture is significantly suboptimal anyway e.g. the use of gigantic shards. You'd get more benefit by fixing the architecture than trying to optimize poor architecture if at all possible.
The big advantage of Z-order curves is that the addressing computation is very cheap, which is why it's used a lot in computer graphics.
While I agree that Z-order curves are simpler, but it's fast to calculate Hilbert curves on modern CPUs too. Just to self plug:
https://github.com/leni536/fast_hilbert_curve
I only implemented the index->XY calculation yet. It compiles to 36 instructions without any branches and takes up 86 bytes.
https://github.com/leni536/fast_hilbert_curve/wiki/How-effic...
I think I can apply the same tricks for the inverse function too.
https://github.com/leni536/fast_hilbert_curve
I only implemented the index->XY calculation yet. It compiles to 36 instructions without any branches and takes up 86 bytes.
https://github.com/leni536/fast_hilbert_curve/wiki/How-effic...
I think I can apply the same tricks for the inverse function too.
But using the same set of instructions, z-order encoding and decoding is 8 instructions (5 if you exclude size conversion and return):
zorder64_inv:
movabsq $0x5555555555555555, %rax
pextq %rax, %rcx, %rdx
shrq %rcx
pextq %rax, %rcx, %rcx
shlq $32, %rcx
movl %edx, %eax
orq %rcx, %rax
retq
zorder64:
movl %ecx, %eax
movabsq $0x5555555555555555, %r8
pdepq %r8, %rax, %rcx
movl %edx, %eax
pdepq %r8, %rax, %rax
addq %rax, %rax
orq %rcx, %rax
retqNice! Now I wonder when 36 vs 8 machine instructions become a bottleneck. I have seen applications of space-filling curves in quasi Monte Carlo integration, it could be potentially significant there.
Hilbert curves are used in a lot of graphics too. Heck, the old SGI Octane with Vpro graphics used a recursive Hilbert curve rasterizer. They show up a lot today in geospatial big-data since hilbert addresses make good shard keys.
I suspect that most production applications of Hilbert curve ordering would work just as well with Z order (a.k.a. Morton order), with the additional benefit of being simpler to reason about (just interleave/de-interleave the bits).
I haven’t ever seen any convincing benchmarks or other analysis where the Hilbert curve created any notable performance advantage vs. Z order; the only time you really need it is if moving along the linearized coordinate must never have jumps in the multidimensional coordinates, but I’m not convinced there are many if any real-world cases where that is important (note that in either case small movements in the multidimensional coordinates are associated with large jumps in the linearized coordinate). If the only goal is to minimize memory fetches, etc. then the Z ordering works just fine.
(If you know any good comparisons where the Hilbert curve comes out ahead, I’d be curious to read them.)
I haven’t ever seen any convincing benchmarks or other analysis where the Hilbert curve created any notable performance advantage vs. Z order; the only time you really need it is if moving along the linearized coordinate must never have jumps in the multidimensional coordinates, but I’m not convinced there are many if any real-world cases where that is important (note that in either case small movements in the multidimensional coordinates are associated with large jumps in the linearized coordinate). If the only goal is to minimize memory fetches, etc. then the Z ordering works just fine.
(If you know any good comparisons where the Hilbert curve comes out ahead, I’d be curious to read them.)
There is an error-diffusion dithering algorithm based on the Hilbert-curve called Riemersma dither.
https://www.compuphase.com/riemer.htm
I suspect that error diffusion along the long jumps of a z-order curve could create strange undesired artifacts.
https://www.compuphase.com/riemer.htm
I suspect that error diffusion along the long jumps of a z-order curve could create strange undesired artifacts.
H-curves are probably optimal with regards to locality, but good luck finding an implementation:
http://www.akt.tu-berlin.de/fileadmin/fg34/publications-akt/...
https://www.reddit.com/r/ProgrammerHumor/comments/4xzi9a/oh_...
http://www.akt.tu-berlin.de/fileadmin/fg34/publications-akt/...
https://www.reddit.com/r/ProgrammerHumor/comments/4xzi9a/oh_...
It doesn't need to be that complicated at all. The book "Hacker's Delight" gives some nice, fairly simple implementations. Here's one:
http://www.hackersdelight.org/hdcodetxt/hilbert/lams.c.txt
http://www.hackersdelight.org/hdcodetxt/hilbert/lams.c.txt
H-curves are not Hilbert curves! I know, the name is very confusing, but read the PDF: H-curves have better locality than Hilbert curves (possibly even optimal).
And I'm sure that constructing H-curves doesn't need to be as complicated as that linked academic code makes it look, but for now I don't know of any implementation.
Thanks for the link though :)
And I'm sure that constructing H-curves doesn't need to be as complicated as that linked academic code makes it look, but for now I don't know of any implementation.
Thanks for the link though :)
Moore curves are also worth considering.
Space-filling curves have been studied as a way to reduce N-dimensional space to 1-D. They are very useful for applications like maximizing sequential access in a N-D datastore. A recent SIGMOD paper analyzed space-filling curves impact on data access:
http://dl.acm.org/authorize.cfm?key=N37709
QUILTS: Multidimensional Data Partitioning Framework Based on Query-Aware and Skew-Tolerant Space-Filling Curves Shoji Nishimura (NEC Corporation); Haruo Yokota (Tokyo Institute of Technology)
It discusses C-Curve, Z-Curve, and Hilbert curves.
QUILTS: Multidimensional Data Partitioning Framework Based on Query-Aware and Skew-Tolerant Space-Filling Curves Shoji Nishimura (NEC Corporation); Haruo Yokota (Tokyo Institute of Technology)
It discusses C-Curve, Z-Curve, and Hilbert curves.
Here's a great write up on how you can use Z-curves to do multidimensional sorting using redis otherwise 1 dimensional sorted set datastructure. It's one of the best hands on examples on a way to solve real problems using this tech within your stack.
https://redis.io/topics/indexes
https://redis.io/topics/indexes
Can someone help explaining why this hash method could improve distance calculation for k-NN? What does it improve compared with Geohash or k-d tree structure?
1. A geohash is a z-curve.
2. It won't be better than a k-d tree. Dimensionality reduction is usually done when you have really truly huge numbers of dimensions that are sparsely populated and you don't care much about some information loss (e.g., for machine learning) or, in this case, when you have an easy way to create a single dimensional index and you want to force multi-dimensional data into it. In the general case a k-d tree would be objectively better in terms of performance.
2. It won't be better than a k-d tree. Dimensionality reduction is usually done when you have really truly huge numbers of dimensions that are sparsely populated and you don't care much about some information loss (e.g., for machine learning) or, in this case, when you have an easy way to create a single dimensional index and you want to force multi-dimensional data into it. In the general case a k-d tree would be objectively better in terms of performance.
And in very many or highly sparse dimensions with few or lazy updates, R-tree or derivatives.
I've used Z-order curves and related curves in Neuroevolution research. It allows conversion of an adjacency matrix to a spatial subtrate representation that preserves locality as it grows (Thus going from 1 dimension to 2 or 3). This technique is an alternative for HyperNEAT or ES-HyperNEAT and experiments demonstrate higher performance that ES-HyperNEAT on the modular retina task problem.
If you're tempted to use space filling curves (z-curves, hilbert curves, etc.) you should take a look at simple multi-dimensional data structures as an alternative.
As a couple of people have mentioned in this thread, space filling curves aren't great at preserving locality (i.e., two points that are "close together" in two dimensional space might end up being "far apart" in one dimensional space, and vice versa). A k-d tree is easy to code up and, in general, will be more efficient for queries like k-NN than dimensionality reduction because it's better at preserving locality.
There are also good libraries for multi-dimensional data structures for pretty much any mainstream language.
As a couple of people have mentioned in this thread, space filling curves aren't great at preserving locality (i.e., two points that are "close together" in two dimensional space might end up being "far apart" in one dimensional space, and vice versa). A k-d tree is easy to code up and, in general, will be more efficient for queries like k-NN than dimensionality reduction because it's better at preserving locality.
There are also good libraries for multi-dimensional data structures for pretty much any mainstream language.
AKA a geohash (for the lat/lon example), but can easily be extended to other bounded dimensions.
This stuff mostly goes over my head, but I'd like to understand it. In the original method, why is op concatenating the two positions into one number, rather than just storing the lat/lon pair and using something like Euclidean distance?
As the commentators on the website mentioned, this method does not preserve the closeness of the points (when going from 2D to 1D), so it is unclear how can it help the author.
True, but it is much better at preserving closeness than the alternative he mentioned (lexicographical sort).
So how would https://xkcd.com/195/ look using a z-curve instead?
I'd imagine it would look less continuous: some of the areas would be ripped apart and spread across the map.
On a lark I plugged this into Google https://encrypted.google.com/search?num=20&hl=en&q=https%3A%... and if you peer at the results, you can see that Google is highlighting "Hilbert curve" as if it were matching one of my search terms. I guess that its algorithm has "learned" that Hilbert curve is a synonym for z-order curve?
http://blog.christianperone.com/2015/08/googles-s2-geometry-...
And 2015 HN thread: https://news.ycombinator.com/item?id=10066616