cosine_distance_arrow_batch in rust/lance-linalg/src/distance/cosine.rs returns ArrowError::InvalidArgumentError with the same wording for two different faults, so a caller cannot tell them apart:
- the
from argument has an unsupported data type
- the
to argument's values fail to downcast to the expected float type
Both produce a message of the same shape from the same variant. A caller that wants to distinguish "the user handed us a query of the wrong type" from "this dataset's vector column is not what we expected" has nothing to key on but string matching.
The three metrics also disagree with each other on the variant for the first of those: l2_distance_arrow_batch returns ArrowError::ComputeError for an unsupported from type, while dot and cosine return InvalidArgumentError. Whichever is right, having l2 differ from its two siblings for the same input class is not.
Suggested resolution: give the two cosine paths distinct messages naming which argument and which type, and make the three metrics agree on the variant for an unsupported query type. InvalidArgumentError looks like the right one, since the cause is the caller's data rather than a computation failure.
Found while reviewing #8884, which adds a third error to these functions, for a null element in an Int8 query, and gives it wording distinct from both. That pull request does not touch the two pre-existing paths.
cosine_distance_arrow_batchinrust/lance-linalg/src/distance/cosine.rsreturnsArrowError::InvalidArgumentErrorwith the same wording for two different faults, so a caller cannot tell them apart:fromargument has an unsupported data typetoargument's values fail to downcast to the expected float typeBoth produce a message of the same shape from the same variant. A caller that wants to distinguish "the user handed us a query of the wrong type" from "this dataset's vector column is not what we expected" has nothing to key on but string matching.
The three metrics also disagree with each other on the variant for the first of those:
l2_distance_arrow_batchreturnsArrowError::ComputeErrorfor an unsupportedfromtype, while dot and cosine returnInvalidArgumentError. Whichever is right, having l2 differ from its two siblings for the same input class is not.Suggested resolution: give the two cosine paths distinct messages naming which argument and which type, and make the three metrics agree on the variant for an unsupported query type.
InvalidArgumentErrorlooks like the right one, since the cause is the caller's data rather than a computation failure.Found while reviewing #8884, which adds a third error to these functions, for a null element in an
Int8query, and gives it wording distinct from both. That pull request does not touch the two pre-existing paths.