[tae898]

Closes #249

Documents what #203 changed: on the native package VectorIndex.find_nearest sends the query vector as one float32 buffer whatever its form (list, float64 array, float32 array).

• how-to/vectors.adoc: a paragraph after the find_nearest signature sentence and a table of median latency, with the change over without it (95% interval). Measured on the native wheel 26.11.1.dev0 on one Linux x86_64 laptop, 11 to 12 clean pairs per figure, the wheel built before the change as the baseline. At 1536 dimensions a float32 array is 0.951 [0.945, 0.954], a float64 array 0.616 [0.614, 0.621] and a list of Python floats 0.631 [0.627, 0.635]; at 256 dimensions 0.952 [0.942, 0.96], 0.777 [0.774, 0.781] and 0.792 [0.787, 0.798]. The vectorNeighbors statement path did not change (1.003 [0.995, 1.014] and 1.004 [0.991, 1.006]). The figures were copied from the study's score file by script. The section also gets an explicit [[find-nearest]] anchor.
• how-to/databases-and-queries.adoc: the "A query vector" section says it is about statements and links to the find_nearest section. The float32 advice for statements stays.
• src/arcadedb/vector.py: the find_nearest query_vector Args line says the native build converts any of the forms to one float32 buffer. find_nearest_approximate is left alone because its native path does not use the buffer.
• which-package.adoc: the native-versus-JVM query medians are kept and labelled as measured before Native find_nearest: send the query vector as one float32 array, not a Python list #203. They were not re-measured, so there are no new numbers there.

The sentence with the find_nearest signature is untouched, so the include_vector PR (#204) can rebase on this one. Checks run: compile and pyflakes on vector.py, pre-commit on the changed files, no pip install or em dash in the diff, and the new find-nearest anchor exists. Not run on this machine: the Antora docs build (the docs.yml check does that) and the test suite.

🤖 Generated with Claude Code