Skip to content

feat: Add Chebyshev distance (L_∞ norm) support#290

Merged
sdd merged 17 commits intosdd:v5.x.xfrom
cbueth:feature/chebychev
Mar 1, 2026
Merged

feat: Add Chebyshev distance (L_∞ norm) support#290
sdd merged 17 commits intosdd:v5.x.xfrom
cbueth:feature/chebychev

Conversation

@cbueth
Copy link

@cbueth cbueth commented Feb 12, 2026

This is a PR #286, reopened for the fitting branch. I rebased my suggested changes, dropping all other commits. Locally all test still pass. I have added a few cases to increase code coverage. Find the PR description over at #286. I will just add onto. it here.

For the default implementation of accumulate I understood best to use num_traits::SaturatingAdd, but this trait is only implemented for integer types, not for floating-point types (f32, f64). So now I changed it to use std::ops::Add as the bound, which works for both integers and floats. This means the default rd + delta works correctly for floating-point types (produces inf on overflow), but fixed-point types need to override accumulate with rd.saturating_add(delta) to prevent overflow. I ignorantly assume that this covers a larger userbase and think this solution is the best we can do without specialization (is currently unstable https://std-dev-guide.rust-lang.org/policy/specialization.html / rust-lang/rust#31844). To my understanding this is still a breaking change for users with fixed-point types who implement custom DistanceMetrics. The only feasible alternative I see would be with a macro to generate implementations that can differentiate the two. Please correct me if I got this wrong.

Secondly, I want to clarify a statement from my previous #286 (comment).

  • Finally, I was not able to find a test where < vs <= makes a difference, but programmatically I agree it could strictly be the right choice. As of now I changed some back to <. You can see the two places it was added (D::IS_MAX_BASED removed in this commit c934656. NON_STRICT_PRUNING would be a better name). I'd suggest you treat this as a separate issue.

I was only not able to find a relevant test where the <= removed in c934656 did (dist_belongs_in_heap) make a difference, so I changed them to <. But still, there are other occurences that are still included and that did make a difference in the test with gaussian data. So if you think there are some cases where having the <= for dist_belongs_in_heap, these can be re-added. Right now there are many parametrizes test cases with nearest_n, but not for within.

If there are suggestions for changes, don't heasitate to say so.

Closes #286

@sdd
Copy link
Owner

sdd commented Feb 16, 2026

Hi again Carlson! Just seen this, I will check them out over the next day or two. Thanks!

@codecov
Copy link

codecov bot commented Feb 16, 2026

Codecov Report

❌ Patch coverage is 95.52980% with 27 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.04%. Comparing base (f87b965) to head (c4e8db9).
⚠️ Report is 17 commits behind head on v5.x.x.

Files with missing lines Patch % Lines
src/traits.rs 29.41% 12 Missing ⚠️
src/float/distance.rs 98.21% 3 Missing and 5 partials ⚠️
src/fixed/distance.rs 93.63% 5 Missing and 2 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           v5.x.x     #290      +/-   ##
==========================================
+ Coverage   94.89%   95.04%   +0.14%     
==========================================
  Files          54       54              
  Lines        5685     6252     +567     
  Branches     5685     6252     +567     
==========================================
+ Hits         5395     5942     +547     
- Misses        273      286      +13     
- Partials       17       24       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@cbueth
Copy link
Author

cbueth commented Feb 16, 2026

Sounds good, thanks :)
Let me know of last changes you want me to integrate, e.g. coverage, formatting.

@sdd
Copy link
Owner

sdd commented Feb 16, 2026

Thanks. As it is, the commit lint step fails because some of your commit message subjects are not confirming to Conventional Commits standard. You can either fix them individually with interactive rebase, or squash them into one commit with a catch-all subject like feat: Add Chebyshev distance metric

@cbueth
Copy link
Author

cbueth commented Feb 26, 2026

Thanks. As it is, the commit lint step fails because some of your commit message subjects are not confirming to Conventional Commits standard. You can either fix them individually with interactive rebase, or squash them into one commit with a catch-all subject like feat: Add Chebyshev distance metric

Yes, I will do that asap for all three PRs.

@cbueth
Copy link
Author

cbueth commented Feb 26, 2026

Hello @sdd, I have changed the commit messages to conform with the conventional commits standard, rebasing this PR, #293 and #294. If there is any more feedback, let me know. Otherwise, I'd be happy to these features in a coming release, so I can use this as a dependency going beta with infomeasure-rs. Again, thanks for your constructive feedback and welcoming my feature requests.

@cbueth
Copy link
Author

cbueth commented Feb 27, 2026

Thanks for running the CI. commitlint failes because I capitalized the message. I think this should only be done in PR titles, not commits.
In stable without features there seems to be one test fixed::query::best_n_within::tests::can_query_best_items_within_radius_large_scale with a panick due to overflow. I will try to reproduce locally.

Copy link
Owner

@sdd sdd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for getting this into shape Carlson, it's a very welcome addition and very thoroughly tested 😄

I just need to work out why the CI didn't seem to run on this. Once we've worked out why and got it to run on this again, I'm happy to merge and we'll get it released.

#[case([ZERO, ZERO], [ZERO, ZERO], ZERO)]
#[case([ZERO, ZERO], [ONE, ZERO], ONE)]
#[case([ZERO, ZERO], [ZERO, ONE], ONE)]
#[case([ZERO, ZERO], [ONE, ONE], FxdU16::lit("2"))]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could use TWO here instead of FxdU16::lit("2") but I'm not going to block merging for such a trivial change :-)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, maybe I missed one click in find+replace there.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in f33b6e9.

@cbueth
Copy link
Author

cbueth commented Feb 27, 2026

While I was not able to reproduce the overflow, it happend with FixedU16 and points to the saturating arithmetic. The 4D test probably exceeded the range of the type. So I replaced the dist and dist1 for all three fixed metrics. Because I did not create a test case that triggers this locally for me (Maybe increasing TREE_SIZE or NUM_QUERIES in the test at src/fixed/query/best_n_within.rs:148 could trigger this overflow.), I'd suggest we let the CI use the existing tests.

  • Manual absolute difference if a > b { a - b } else { b - a }) -> the dist() of fixed::traits::Fixed.
  • For SquaredEuclidean now using saturating_mul()

For both I did not know before these exist for Fixed.

I just need to work out why the CI didn't seem to run on this. Once we've worked out why and got it to run on this again, I'm happy to merge and we'll get it released.

That's great to hear, thanks!

@sdd sdd merged commit 568b496 into sdd:v5.x.x Mar 1, 2026
10 checks passed
@sdd
Copy link
Owner

sdd commented Mar 2, 2026

Hi Carlson - I've merged this in now. Looking at your other PR now (#291), there's a small merge conflict now that this one has been merged, as well as a failure on the formatting check. If you can get that one back into shape, I'll merge that one in as well so we can get both into a 5.3.0 release. Thanks!

@cbueth
Copy link
Author

cbueth commented Mar 2, 2026

Thanks for the review and merge! 👏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants