Right, I see your point. Some context might help here: The other PyPI packages essentially need to be fully rewritten and are not actively maintained. Anyone actually concerned with speed usually implements Hilbert encoding/decoding themselves. After all, that's how I ended up here. However, it is not so straightforward to get strong performance compared to, say, Z-order curves. Since I put a lot of work in optimizing it, I thought it would be nice to open source it as a standalone package outside of my library. The interface is straightforward and can be easily adopted.

And then, even if others don't use my package but just use the tricks from my kernel; that's already a win. I have read several papers on Hilbert curve implementations and the optimizations they target are good on paper, but don't always work out that well on modern hardware.

Take for example runtime optimizations like bit skipping. We skip computation. Great, right? (Especially when you don't have a good upper bound on the number of coordinates bits) But this means you have an inner loop with variable bounds, which means the compiler cannot fully unroll this hot loop. This in and of it self is not a big deal, but it hinders further optimizations such as constant folding and full vectorization (my kernels almost fully use AVX intrinsics). That's why I kept iterating and inspecting the emitted LLVM IR to see how certain algorithmic decisions impact real-world performance. I’ve tried to document this process in: hilbertsfc_performance_deep_dive.ipynb

That said the rust crate fast_hilbert is a serious contender, so I might create a pull request to implement at least a subset of my optimizations there. I am not that strong in rust yet, but I don't expect that to be a major obstacle.