You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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).
The text was updated successfully, but these errors were encountered:
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 newminimum
/maximum
andminimumNumber
/maximumNumber
operations which are recommended by not required and which more clearly specify various behaviors.minimumNumber
/maximumNumber
are largely compatible with the existingminNum
/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 theNaN
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 doMath.Min(-0.0, +0.0)
orMath.Min(+0.0, -0.0)
.The text was updated successfully, but these errors were encountered: