Mismatch for ordering operations between -0.0 and +0.0 #838
Description
As noted in rust-lang/libm#415 (comment), our implementations currently do not align with musl/MPFR. There are a couple different specs to follow here.
N3047 (C23) states:
Ideally, fmax would be sensitive to the sign of zero, for example fmax(−0.0, +0.0) would return +0; however, implemen-
tation in software might be impractical
IEEE 754-2008 states:
- minNum(x, y) is the canonicalized number x if x < y, y if y < x, the canonicalized number if one operand is a number and the other a quiet NaN. Otherwise it is either x or y, canonicalized (this means results might differ among implementations). When either x or y is a signalingNaN, then the result is according to 6.2.
But does not really specify the order between -0.0 and 0.0.
IEEE 754-2019 states:
- minimum(x, y) is x if x < y, y if y < x, and a quiet NaN if either operand is a NaN, according to 6.2. For this operation, −0 compares less than +0. Otherwise (i.e., when x = y and signs are the same) it is either x or y
- minimumNumber(x, y) is x if x < y, y if y < x, and the number if one operand is a number and the other is a NaN. For this operation, −0 compares less than +0. If x = y and signs are the same it is either x or y. If both operands are NaNs, a quiet NaN is returned, according to 6.2. If either operand is a signaling NaN, an invalid operation exception is signaled, but unless both operands are NaNs, the signaling NaN is otherwise ignored and not converted to a quiet NaN as stated in 6.2 for other operations
C23 provides fmaximum, fminimum, fmaximum_num, and fminimum_num to reflect these newer specs.
So, my read of this is that we should be matching musl and MPFR in saying that +0.0 > -0.0, which is consistent with minimum in 754-2019 (note that NaN handling is still different).