Rationale

dotnet/coreclr#20912 updated the existing Math.Min/Math.Max functions to be both IEEE 754:2008 compliant and to be inline with the C/C++ language standard (Annex F - IEC 60559 floating-point arithmetic). This also brought it inline with MSVC, GCC, and Clang for their implementations under 'precise' floating-point mode.

However, it looks like the draft for IEEE 754:2019 (a summary can be found here http://754r.ucbtest.org/background/, but I also have the latest draft locally) is changing things up a bit. Namely, they are removing minNum/maxNum from the list of "required" operations and replacing them with new minimum/maximum and minimumNumber/maximumNumber operations which are recommended by not required and which more clearly specify various behaviors.

• minimumNumber/maximumNumber are largely compatible with the existing minNum/maxNum functions. But also clarifies that +0 is greater than -0 for the purpose of this function and clarifies the behavior of signalling NaN.
• minimum/maximum are new and would propagate the NaN as expected here. They likewise clarify that +0 is greater than -0 for the purpose of this function.

Proposal

Given this change of behavior in the new spec and that partners, such as WPF, are dependent on the existing functionality. We should revert the behavior to continue propagating the NaN.

Notes

A separate proposal to expose methods which don't propagate the NaN is here: https://github.com/dotnet/corefx/issues/36925

We should keep the change that treats +0 as greater than -0 for the purposes of these functions. This ensures that there won't need to be future changes to the functions for IEEE 754:2019 compliance and makes the behavior deterministic regardless of whether you do Math.Min(-0.0, +0.0) or Math.Min(+0.0, -0.0).