vector_of_kll: convert array inputs to the expected dtype

[leerho]

Fixes #63.

Problem

The vector_of_kll_*_sketches query methods accept a scalar, a list, or a numpy array. The array alternative was an untyped nb::ndarray<>, and input_to_vec() wrapped its buffer as the expected element type without checking the dtype, so a mismatched array was silently reinterpreted. Reproduced on main:

Call on vector_of_kll_floats_sketches	main	this PR
get_quantiles(np.float32 ranks) (the issue)	[-98.9, -99.5]	[-99.2, -10.0], same as float64
get_ranks(np.float64 values)	[1.0, 1.0]	same as a list
isk=np.array([0, 1]) (int64, numpy's default)	sketch 0 twice	sketches 0 and 1

update() was not affected: it already takes a typed nb::ndarray<T>, which nanobind converts.

Fix

ArrInputType now uses nb::ndarray<V, nb::ndim<1>> for its array alternative, so nanobind converts the input to the expected dtype before the method sees it. This covers get_quantiles, get_ranks, get_pmf, get_cdf, and the isk argument of every method that takes it (collapse, serialize, ...).

One behavior change: a 2-D array passed where a 1-D input is expected now raises TypeError. Before, its buffer was reinterpreted as 1-D.

Testing

New test_kll_input_dtypes checks that float32 and float64 arrays give the same results as lists for get_quantiles, get_ranks, get_pmf and get_cdf, and that int32 and int64 index arrays select the same sketches as a list. It fails on main and passes with this change; all 39 tests pass (macOS, Python 3.12). The ranks in the test are exactly representable in float32 (0.0625, 0.9375); a value like np.float32(0.99) is genuinely a different rank from 0.99 and can select a different item.

🤖 Generated with Claude Code