Skip to content

Mismatch for ordering operations between -0.0 and +0.0 #838

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tgross35 opened this issue Jan 13, 2025 · 1 comment
Open

Mismatch for ordering operations between -0.0 and +0.0 #838

tgross35 opened this issue Jan 13, 2025 · 1 comment
Labels
libm Issues relating to libm

Comments

@tgross35
Copy link
Contributor

tgross35 commented Jan 13, 2025

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).

@tgross35
Copy link
Contributor Author

tgross35 commented Jan 24, 2025

Also note from N3220:

The functions fmin and fmax have been superseded by fminimum_num and fmaximum_num. The fmin and fmax functions provide the minNum and maxNum operations specified in (the superseded) ISO/IEC/IEEE 60559:2011.

tgross35 referenced this issue in tgross35/rust-libm Jan 24, 2025
These can be used for `fmin`, `fminf`, `fmax`, and `fmaxf`. No changes
to the implementation are made, so [1] is not fixed.

[1]: https://github.com/rust-lang/libm/issues/439
tgross35 referenced this issue in rust-lang/libm Apr 18, 2025
These can be used for `fmin`, `fminf`, `fmax`, and `fmaxf`. No changes
to the implementation are made, so [1] is not fixed.

[1]: https://github.com/rust-lang/libm/issues/439
@tgross35 tgross35 transferred this issue from rust-lang/libm Apr 19, 2025
@tgross35 tgross35 added the libm Issues relating to libm label Apr 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
libm Issues relating to libm
Projects
None yet
Development

No branches or pull requests

1 participant