ENH Introduce dtype preservation semantics in DistanceMetric objects.

[Micky774]

Reference Issues/PRs

What does this implement/fix? Explain your changes.

Preserves dtype when computing distances, under the assumption that the precision of the input data is an implication of preferred precision of output data. Note that accumulation still largely occurs using float64_t with some exceptions.

Any other comments?

Current benchmarks (generated here) suggest that there is no regression in the dense case (dist), and a 10-25% speedup in the sparse case (dist_csr).

Benchmark Plots

Memory profiling indicates a reduction of memory usage in this script from 763MiB to 382MiB.

cc: @jjerphan @OmarManzoor @thomasjpfan

[github-actions]

✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

_{Generated for commit: f8b6027. Link to the linter CI: here}

[jjerphan]

Thank you, @Micky774.

We indeed need to add dtype preservation to Cython implementations. Yet, I do not think we need to change the return type of methods to INPUT_DTYPE_t. One of my comments gives some details.

[jjerphan]

I was oncerned with the loss of precision for PairwiseDistancesReductions but since the test suite passes I think we can accept or one the other: proceed as you prefer, @Micky774.

[Micky774]

I was oncerned with the loss of precision for PairwiseDistancesReductions but since the test suite passes I think we can accept or one the other: proceed as you prefer, @Micky774.

I've reintroduced the dtype-dependent signatures. Do you think this warrants a separate changelog entry considering DistanceMetric objects now fully preserve dtype?

[jjerphan]

I don't think this is necessary since DistanceMetric32 aren't public.

[OmarManzoor]

LGTM. Thanks @Micky774

[jjerphan]

I merged main again to resolve the unrelated linter failure on the CI.