[tae898]

NativeVectorIndex._run_search (native find_nearest and find_nearest_by_key) turns the query into a Python list with tolist(). Since #107 the codec then either checks that list for float32-exactness (_exact_float_list: set(map(type, ...)), np.array, astype, array_equal, then the side-buffer tag BL), or, for a float64 query whose values float32 rounds, prints one float repr per element as JSON text (about 611 us at 1536 dimensions, the figure in the codec's own docstring). This change hands the codec a float32 ndarray instead: a numeric 1-d query (an ndarray of any numeric dtype, or a list or tuple of numbers, which numpy walks in C) goes through the float32 side buffer (tag B) directly. The engine reads the vector as float32 whatever it is given, so the rounding does not change. Text or None entries, a generator, ragged input and a missing numpy stay a list and reach the engine as before.

This is the port of humemai/arcadedb-embedded-python#523 (backlog row N-07) onto main. It was written before #107; what #107 already removed is the per-element _prep calls that #523 counted (768 to 0). What is left to save is tolist(), the exactness pass for a float32 query, and the JSON text for a float64 query. Whether that shows in a search of 0.3 to 0.75 ms is for the timed A/B to say; no timing was run here.

Results are identical: every form of the query (float32 and float64 array, tuple, list of numpy floats, generator, non-contiguous view, integer array, find_nearest_by_key, a float64 query that float32 rounds) answers the same neighbours at the same distances (exact equality), allowed_rids and ef_search still apply, and a query of the wrong dimension or with None or text entries is still refused with ArcadeDBError.

Tests: tests/test_find_nearest_query_forms.py runs on both backends and passes before and after the change (it is the contract the change keeps). tests/test_native_find_nearest_params.py is native only (not collected on the JVM backend): where the floats travel (tag B with dim floats beside the text, never BL) and that _exact_float_list is not run on a query; 5 of its 6 tests fail on the code before. Local check on the committed bytes: the 14 tests pass against the unmodified native wheel 26.11.1.dev0 (matched dev pair dd45b53 + e353330c5c) with only this PR's schema_objects.py copied over it (not a wheel built from this repo); the vector, SQL-vector, numpy and query-vector-parameter suites show the same failing set with and without the change (the wheel predates main, and test_vector.py needs JPype). black, isort (profile black), pyflakes and bandit are clean on the changed files. Not run: the full suite, scripts/build.sh, CI (a draft skips the matrix).

This stays a draft until a timed A/B decides it: native wheels of main and of this head, find_nearest k = 10 p50 at 768 and 1536 dimensions for a float32 array, a float64 array and a list, with the answers compared pair by pair. If the interval does not exclude 1.00 it stays a cleanup or is closed. It touches the same function as the lazy-vector change of the same series (a separate PR); the two edit adjacent lines of _run_search, so whichever merges second needs a trivial rebase.

Refs #19

🤖 Generated with Claude Code