fix: interpolation_search divide-by-zero panic and degenerate probe

[SEPURI-SAI-KRISHNA]

Pull Request Template

Description

interpolation_search divides by nums[high] - nums[low] without ever checking that the
difference is non-zero, and it performs that division before multiplying. Both are bugs.

1. Divide-by-zero panic

Whenever the two endpoints of the current range hold the same value, the probe computes
x / 0 and the search aborts with attempt to divide by zero. This is not an exotic
input — it happens for:

• any single-element slice: interpolation_search(&[7], &7)
• any slice whose endpoints are duplicates: interpolation_search(&[2, 2, 2], &2)
• any ordinary search whose range simply converges onto one element:
  interpolation_search(&[0, 1, 10], &10)

Fuzzing the old implementation over 39,600 random (sorted slice, needle) pairs with slice
lengths 1..12 produced 2,044 panics (~5% of all searches). The five existing unit tests
missed it because each one happened to probe the correct index on the first iteration.

The fix keeps low <= high as an explicit loop guard and returns early when the range is
constant — at that point the loop condition has already established
nums[low] <= item <= nums[high], so every element in the range is the item.

2. The interpolation formula defeated its own purpose

The probe was written as:

low + (((high - low) / (nums[high] - nums[low]) as usize) * (*item - nums[low]) as usize)

Integer division ran first, so (high - low) / (nums[high] - nums[low]) truncated to 0
whenever the value range was wider than the index range — the common case. The offset then
collapsed to low, and interpolation search degenerated into a linear scan, giving O(n)
instead of the O(log log n) the algorithm exists to provide. For example, searching 9 in
[1, 2, 3, 4, 5, 6, 7, 8, 9, 100] stepped one index at a time.

Reordering to multiply first restores the textbook formula:

offset = low + (high - low) * (item - nums[low]) / (nums[high] - nums[low])

3. i32 subtraction overflow

nums[high] - nums[low] and *item - nums[low] were computed in i32, so a slice spanning
a wide range (e.g. [i32::MIN, 0, i32::MAX]) overflowed. The intermediates are now widened,
and the product is computed in i128 so it cannot overflow for any slice length.

4. Unused generic parameter

The signature was pub fn interpolation_search<Ordering>(nums: &[i32], item: &i32). That
generic parameter is never used and shadows std::cmp::Ordering, which forced every call
site into the nonsensical turbofish interpolation_search::<Ordering>(&nums, &item). It has
been removed. This is the only breaking part of the change; nothing else in the repository
called this function.

The Ok/Err contract is unchanged: Ok(index) when found, Err(0) when absent.

Tests

The five original assertions are preserved and extended to 25, including named regression
cases for each panic above, plus matches_linear_scan_exhaustively, which checks the search
against a linear scan over ~33k generated cases (runs in well under 300ms).

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• I ran bellow commands using the latest version of rust nightly.
• I ran cargo clippy --all -- -D warnings just before my last commit and fixed any issue that was found.
• I ran cargo fmt just before my last commit.
• I ran cargo test just before my last commit and all tests passed.
• I added my algorithm to the corresponding mod.rs file within its own folder, and in any parent folder(s).
• I added my algorithm to DIRECTORY.md with the correct link.
• I checked COUNTRIBUTING.md and my code follows its guidelines.

Note: no mod.rs or DIRECTORY.md change was needed — this fixes an existing entry
rather than adding a new algorithm.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.90%. Comparing base (2c53ddf) to head (f5ae7b5).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1062   +/-   ##
=======================================
  Coverage   95.89%   95.90%           
=======================================
  Files         396      396           
  Lines       30440    30451   +11     
=======================================
+ Hits        29190    29203   +13     
+ Misses       1250     1248    -2     

☔ View full report in Codecov by Harness.
📢 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.

[github-actions]

This pull request has been automatically marked as abandoned because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[SEPURI-SAI-KRISHNA]

Still relevant and ready for review, all 7 checks are green and Codecov reports every modified line covered.

Recapping the impact for whoever picks this up: interpolation_search divides by nums[high] - nums[low] without checking it is non-zero, so it panics whenever the search range converges onto equal endpoints. That includes any single-element slice
and ordinary cases like interpolation_search(&[0, 1, 10], &10). Fuzzing the old code over 39,600 random searches hit the panic ~5% of the time. The same expression also divided before multiplying, which truncated the probe to low and degraded the search to a linear scan.

@imp2002 would you have a moment to take a look?