[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

[tae898]

Timed A/B (native wheel; arm A = main's CI native wheel, arm B = the same tree with only this PR's files, A/A control; laptop timed lane, tools/ab.py --noise, ABBA, round 0 dropped). find_nearest p50 latency, B/A median with 95% CI (below 1 = this PR is faster):

query passed as	1536-d	256-d
float32 array	0.951 [0.945, 0.954]	0.952 [0.942, 0.96]
float64 array	0.616 [0.614, 0.621]	0.777 [0.774, 0.781]
list of float32 values	0.975 [0.964, 0.982]	0.969 [0.966, 0.977]
list of doubles	0.631 [0.627, 0.635]	0.792 [0.787, 0.798]
statement path (control, not changed by this PR)	1.003 [0.995, 1.014]	1.004 [0.991, 1.006]

Clean pairs per figure: 11, 12. Every counted run returned the same ids and distances on both arms (answer digests equal in every round), the encoder spy showed the side buffer where this PR takes it, and the statement path stayed flat. By the rule written before the run this is a SHIP: every headline form is faster on both dimensions with no regression and an unchanged control. The large gain is for float64 input (array or list of doubles): main sends it as JSON text, this PR sends it as one float32 buffer like the other forms (encoder spy on every run).

The merge waits for the end of the current batch of timed studies that pin main (merging now would move their pins); the PR leaves draft at that point.