On Sat, 4 Feb 2023 13:24:11 GMT, Tagir F. Valeev <tval...@openjdk.org> wrote:
> clamp() methods added to Math and StrictMath
>
> `int clamp(long, int, int)` is somewhat different, as it accepts a `long`
> value and safely clamps it to an `int` range. Other overloads work with a
> particular type (long, float and double). Using similar approach in other
> cases (e.g. `float clamp(double, float, float)`) may cause accidental
> precision loss even if the value is within range, so I decided to avoid this.
>
> In all cases, `max >= min` precondition should met. For double and float we
> additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare
> do. In double and float overloads I try to keep at most one arg-check
> comparison on common path, so the order of checks might look unusual.
>
> For tests, I noticed that tests in java/lang/Math don't use any testing
> framework (even newer tests), so I somehow mimic the approach of neighbour
> tests.
src/java.base/share/classes/java/lang/Math.java line 2209:
> 2207: * @param max maximal allowed value
> 2208: * @return a clamped value that fits into {@code min..max} interval
> 2209: * @throws IllegalArgumentException if {@code min < max}
Maybe I'm missing something but shouldn't this say `if {@code min > max}`? It's
also repeated throughout the rest of the javadoc.
-------------
PR: https://git.openjdk.org/jdk/pull/12428
