Tracking Issue for float_minimum_maximum

[Urgau]

View all comments

Feature gate: #![feature(float_minimum_maximum)]

This is the tracking issue for the f{32,64}::{min,max}imum functions.

It provide IEEE 754-2019 minimum and maximum functions to f32/f64.

Public API

impl f32 {
    pub const fn minimum(self, other: f32) -> f32;
    pub const fn maximum(self, other: f32) -> f32;
}

impl f64 {
    pub const fn minimum(self, other: f64) -> f64;
    pub const fn maximum(self, other: f64) -> f64;
}

Steps / History

• Implementation: Adds IEEE 754-2019 minimun and maximum functions for f32/f64 #91008
• Constified in Make some float methods unstable const fn #130568
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Should the implementation be stabilized in it's current state (ie. without intrinsic: explanation and llvm issue) ?
  • Use intrinsics for {f16,f32,f64,f128}::{minimum,maximum} operations #140792
  • [aarch64] Cannot select: constant:i128<0> for llvm.maximum.f128 llvm/llvm-project#139380
  • [x86]: Cannot select: constant:i128<0> for llvm.maximum.f128 llvm/llvm-project#139381
  • [arm] Cannot select i32 = setcc 0x00000000, Constant:i64 llvm/llvm-project#140445
• Should it be called like IEEE 754-2019 (minimum and maximum) or something else ? Tracking Issue for float_minimum_maximum #91079 (comment)
• Should the standard library have this function at all (we already have min/max) ?

[CryZe]

Just so it's tracked here: This currently does not compile to the corresponding instruction on WASM (fmin / fmax) and I believe Aarch64 has an instruction for this too (FMIN / FMAX), which it also doesn't compile to.

Godbolt

[workingjubilee]

I believe there is an LLVM instruction for this. We can teach Rust to emit the appropriate LLVMIR directly, at the cost of adding the weight of an intrinsic. As we have discussed doing so for the portable SIMD API anyways, it might be profitable to do this in general.

[scottmcm]

LLVM does have an intrinsic for this, but as the PR that added these showed (https://godbolt.org/z/czz71M9KT), it doesn't actually work yet, which is why rustc isn't using it to implement these.

[workingjubilee]

Ah, Damn.

[rben01]

Everything that follows will be stated in terms of the min and minimum functions but applies equally to max and maximum.

Does the function have to be called minimum? I know that's the IEEE name but I think I'd find having both min and minimum confusing, as their names don't really say which is which. "The function that requires both inputs be NaN for its output to be NaN is the one with the shorter name" is not a natural rule to remember IMO. I think I'd prefer having minimum be called (say) partial_min to suggest that it follow the same rules as PartialEq and PartialOrd, which is that a single NaN in the input is sufficient to produce a missing output.

[m-ou-se]

Nominated at the request of @Urgau.

[m-ou-se]

The confusion between maximum vs max is definitely a problem, so we'll need to do something about that before we can stabilize that. The max and min functions are already stable, so we have limited flexibility.

We'll need some more input: How do other languages and libraries handle this? How are these named in the standard? What are the use cases for max vs maximum?

[alistaircarscadden]

I agree that having pairs of functions such that min != minimum and max != maximum is an issue. I had to check the documentation for why there were two functions to do the same thing to realize that they were functionally different. I think whatever the most explicit possible name is should be chosen. I don't think minimum / maximum is correct.

Here are some suggestions to add to the brainstorm. Any of these can be min or minimum and apply to both min and max.

• min_nan,
• min_propigate_nans
• min_any_nan
• min_ieee_754_2019
• min_nans_win
• etc.

I think that min with some suffix is preferable to minimum because it shows it is an alteration of the existing min function, not a competing function. I don't know the whole history of relevance of IEEE 754 2019 but I think choosing minimum because that's how it is named in that standard is not clear to the average Rust programmer.

[rben01]

To throw some other ideas in the mix:

By analogy with the distinction between quiet NaN and signaling NaN, maybe the new minimum (maximum) function should be called signaling_min (signaling_max).

I also like lesser_of (greater_of), as it kind of implies that < (>) will be used, which obviously return NaN if at least one argument is NaN. You could imagine the following conversation: "Which is the lesser of 1 and NaN?" "That makes no sense, they can't be compared." "Exactly."

IMO min_all/min_both (max_all/max_both) also get the idea across -- all/both of the arguments will affect the output. In particular, even if one of the args is -inf (+inf) you still have to look at the other.

[CryZe]

This might also influence the naming situation: There's more than just these two algorithms.

Rust's max is IEEE Std 754-2008 maxNum
This new one is IEEE Std 754-2019 maximum
And there's also IEEE Std 754-2019 maximumNumber
And I feel like WebAssembly's pmax / C++'s std::max is also worth considering having (ignores NaN for a fast impl)

[scottmcm]

The new one is arguably the "best" one, as it's the one that behaves most similarly to everything else with respect to NANs -- the other binary functions like add and atan2 do the same "NAN if either input is NAN", same as what maximum does.

So one option might be to deprecate max under that name and offer it as max_ignoring_nans or something, letting the new one get the name maximum.

(Thought that does have the obvious downside of being different from the max method on everything that's Ord.)