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).
Rationale
dotnet/coreclr#20912 updated the existing
Math.Min/Math.Maxfunctions 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/maxNumfrom the list of "required" operations and replacing them with newminimum/maximumandminimumNumber/maximumNumberoperations which are recommended by not required and which more clearly specify various behaviors.minimumNumber/maximumNumberare largely compatible with the existingminNum/maxNumfunctions. But also clarifies that+0is greater than-0for the purpose of this function and clarifies the behavior of signalling NaN.minimum/maximumare new and would propagate theNaNas expected here. They likewise clarify that+0is greater than-0for 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
+0as greater than-0for 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 doMath.Min(-0.0, +0.0)orMath.Min(+0.0, -0.0).