s2geometry VS usearch

I experimented with geospatial Hilbert Curves as a Postgres extension [0] for PostGIS using the S2 [1] spherical geometry library. S2 uses a scale free cell coverage pattern that is numbered using six interlocking space filling Hilbert Curves [2].

By having both high level (cell) and low level (cell id) geometries it was a very powerful library which allowed projection from the hilbert space into a Postgres spatial index (spgist) including various trees, like noted in this article. It appears to be still quite active in development.

[0] https://github.com/michelp/pgs2

[1] https://s2geometry.io/

[2] https://s2geometry.io/devguide/s2cell_hierarchy

If you check the h3geo comparison page, you should see plenty of alternatives to geohash, such as s2 or even h3 itself.

See some discussion I started at https://github.com/google/s2geometry/issues/190

> It was quite hard for me to find open-source implementations of linear quadtrees.

You probably know this, but the S2 library has one: https://github.com/google/s2geometry

https://s2geometry.io shows how this works

If your points are distributed globally, however, I'd suggest using something like s2geometry (calculates over a sphere instead of an ellipsoid which is much faster + already has something called S2ClosestPointQuery).

Some alternative solutions are S2 from Google and H3 from Uber. These don't have the same issues as geohash because they work on a 3-d model of the geoid and not a 2-d cylindrical projection like Geohash.

Might have a look at this library:

https://github.com/unum-cloud/usearch

It does HNSW and there is a SQLite related project, though not quite the same thing.

Another worth mentioning in this thread is usearch, though not a separate algorithm, based on HNSW with a bunch of optimizations https://github.com/unum-cloud/usearch

I've used usearch successfully for a small project: https://github.com/unum-cloud/usearch/

The hardest (still missing) part of efficient cosine computation distance computation is picking a good epsilon for the `sqrt` calculation and avoiding "division by zero" problems.

We have an open issue about it in USearch and a related one in SimSIMD itself, so if you have any suggestions, please share your insights - they would impact millions of devices using the library (directly on servers and mobile, and through projects like ClickHouse and some of the Google repos): https://github.com/unum-cloud/usearch/issues/320

As you scale, you may benefit from these two projects I maintain, and the Big Tech uses :)

https://github.com/unum-cloud/usearch - for faster search

https://github.com/unum-cloud/uform - for cheaper multi-lingual multi-modal embeddings

> It doesn't appear to query CPUID

Yes, I'm actually looking for a good way to do it for other projects as well. I've looked into a couple more libs, and here is the best I've come up with so far: https://github.com/unum-cloud/usearch/blob/f942b6f334b31716f...

> Your substring routines have multiplicative worst case

Yes, that is true. It's a very simple stupid trick, just happens to work well for me :)

> It seems quite likely that your confirmation step

We have a different library internally at Unum, that avoids this shortcoming. It has a few thousand lines of C++ templates with SIMD intrinsics... and it's definitely more efficient, but the margins aren't always high. So I kept the pure C version with inlined functions as minimal and simple as possible.

> It would actually be possible to hook Stringzilla up to `memchr`'s benchmark suite if you were interested. :-)

Yes, that would be a fun thing to do! I haven't had time to look into `memchr` yet, but would expect great perf from your lib as well. For me the State of the Art is Intel HyperScan. Probably the most advanced SIMD library overall, not just for strings. I was very impressed with their perf ~5 years ago. But the repo is 200 K LOC... So get ready to invest a weekend :)

That said, I'm a bit slammed with work right now, including open-source. Hoping to ship a new major release in UCall this week, and a minor one in USearch :)