The native index Monty.Frameworks.Utils.KdTree uses when it can.
The Elixir tree in that module is the reference: it is what the tests describe,
what runs on a machine without a Rust toolchain, and what the native engine is
held to by a parity test. This is the fast path — kiddo, which answers a
query in about 0.45 µs against the Elixir tree's 6, and stays flat as the graph
grows instead of getting slower.
A NIF is a library the BEAM loads into itself, so its absence is a raised
ErlangError rather than a returned error: loaded?/0 is the question a caller
asks once, and KdTree asks it when it builds an index.
Summary
Functions
True, from the native side — the only way to know it is loaded.
An index over positions, a flat binary of 3 * n little-endian f64 values.
Whether this VM built and loaded the native index.
The ids of the k points nearest each of the queries in queries.
The same answers with the distance to each, as {ids, distances}.
How many points an index holds.
Functions
True, from the native side — the only way to know it is loaded.
An index over positions, a flat binary of 3 * n little-endian f64 values.
A point's id is its position in that binary, which is why KdTree.build/1
only takes this path when the ids it was given are 0..n-1.
@spec loaded?() :: boolean()
Whether this VM built and loaded the native index.
The ids of the k points nearest each of the queries in queries.
Swept from one flat binary of 3 * m f64 values to m * k little-endian u32
ids, nearest first, 4_294_967_295 where a query found fewer than k.
The same answers with the distance to each, as {ids, distances}.
How many points an index holds.