geos-wasm
tg
| geos-wasm | tg | |
|---|---|---|
| 1 | 6 | |
| 74 | 535 | |
| - | - | |
| 7.9 | 6.8 | |
| about 1 month ago | about 1 month ago | |
| JavaScript | C | |
| GNU Lesser General Public License v3.0 only | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
geos-wasm
tg
-
I'm writing a new vector search SQLite Extension
Thanks for sharing! I've looked into usearch before, it's really sleek, especially all their language bindings. Though I want sqlite-vec to have total control over what stays in-memory vs on-disk during searches, and most vector search libraries like usearch/hnswlib/faiss/annoy either always store in-memory or don't offer hooks for other storage systems.
Additionally, sqlite-vec takes advantage of some SQLite specific APIs, like BLOB I/O [0], which I hope would speed things up a ton. It's a ton more work, coming up with new storage solutions that are backed by SQLite shadow tables, but I think it'll be work it!
And I also like how sqlite-vec is just a single sqlite-vec.c file. It makes linking + cross-compiling super easy, and since I got burned relying on heavy C++ dependencies with sqlite-vss, a no-dependency rule feels good. Mostly inspired by SQLite single-file sqlite3.c amalgamation, and Josh Baker's single file C projects like tg[1].
[0] https://www.sqlite.org/c3ref/blob_open.html
[1] https://github.com/tidwall/tg
- Show HN: TG – Fast geometry library for C
-
Show HN: TG – Fast geometry library in C
I can't stop precision loss in all cases, but I do my darnedest to avoid loss when it causes false positives, especially for stuff like intersect detection code. For example the collinear [1] function looks really big for a seemingly simple operation, but there are extra checks built in to check for precision loss and in the cases of compiler associate math issues (like a user borking a build with -ffast-math).
I'm sure it's not all perfect but I feel pretty good about it overall. It certainly helps that much of the logic derived from the Tile38 [2] project, which has 8 years of use in production. I ported many of tests too, which makes me warm and fuzzy every time they pass.
[1] https://github.com/tidwall/tg/blob/v0.1.0/tg.c#L389
What are some alternatives?
sedona - A cluster computing framework for processing large-scale geospatial data
robust-predicates - Fast robust predicates for computational geometry in JavaScript
sqlite-tg - SQLite extension around tg, a geometric library for limited GIS operations
GeometricTools - A collection of source code for computing in the fields of mathematics, geometry, graphics, image analysis and physics.
Tile38 - Real-time Geospatial and Geofencing
s2geometry - Computational geometry and spatial indexing on the sphere