Return Error::Overflow from WeightedIndex on float weight overflow

[teddytennant]

• Added a CHANGELOG.md entry

Summary

WeightedIndex::new and update_weights panic when the sum of float weights reaches infinity. Return Error::Overflow instead, as already documented and as done for integer weights.

Motivation

WeightedIndex::new documents Error::Overflow when the sum of weights overflows, but Weight::checked_add_assign never errors for floats — the sum just becomes infinite. UniformFloat::new then rejects the non-finite bound and the .unwrap() on X::Sampler::new panics:

WeightedIndex::new([f64::MAX, f64::MAX]); // panics: NonFinite

#1353 fixed this for integer weights; float weights were missed.

update_weights has the same unwrap, and worse: it panics after the cumulative weights have already been mutated, violating the documented "in case of error, self is not modified" contract.

Details

• In new, map the sampler error to Error::Overflow.
• In update_weights, construct the new sampler during the pre-mutation check phase (mapping the error the same way) so a failure leaves self untouched, and document Error::Overflow in its error list.
• Added an overflow_float test covering f64::MAX + f64::MAX, f32, an explicitly infinite weight, and that a failed update_weights leaves the distribution unmodified.

Tested with cargo test --lib weighted (14 tests pass); cargo fmt --check and cargo clippy --lib are clean.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[dhardy]

The issue here is that Weight::checked_add_assign was relied on to avoid overflow in fn new, yet it does no such thing for floats. Can you add a note to its docs clarifying that the implementation for floats does not trap overflow-to-inf or nan?

Otherwise, I think this approach is reasonable. Fn update_weights still has a potential issue with integer overflows but lets not address that here.