Implement LowerBounded and UpperBounded for Ratio

[tyilo]

No description provided.

[cuviper]

I wonder, is there a reason you chose these one-sided bounds rather than just Bounded?

[mikem8891]

I am pretty sure it is related to BigUint. The pull rust-num/num-bigint#330 makes impl LowerBounded for BigUint but not UpperBound, so I think impl<T: Bound> Bound for Ratio<T> would exclude BigUint and prevent impl<T: LowerBound> LowerBound for Ratio<T> because there is already a blanket impl in num-traits. Ideally, I think Bound would be trait Bound: LowerBound + UpperBound {} instead of having a blanket impl for UpperBound and LowerBound, but I don't know all the details of why it was implemented this way.

A compromise might be impl<T: Bound> Bound for Ratio<T> and impl LowerBound for Ratio<BigUint>, but I haven't tried it and the second impl needs to be behind the num-bigint feature flag.

[cuviper]

Yeah, there's a FIXME in num-traits about changing to a supertrait (if we ever do a breaking change there). It's just a historical artifact that Bounded came first, on its own.

In the current places where we do use T: Bounded ourselves, we only call max_value(). We could switch those to T: UpperBounded, which is even semver-safe since there's a blanket impl in that direction. I doubt there's any real T: Integer that has an upper and not lower bound though.

impl LowerBound for Ratio<BigUint>

This is basically just Zero though -- is Ratio<T>: LowerBounded otherwise useful in some generic context?

FWIW, the original num-traits motivation was about ranges: rust-num/num-traits#208

[tyilo]

I think my original use-case was making a generic exponential search which can then be combined with a binary search to search over BigUint or Ratio<BigUint>. Note that only a lower bound is needed and this doesn't have to be zero - it can also work for i32, however not for BigInt.

No matter what, why not just add the implementation?