Added next_up and next_down for f32/f64.

[orlp]

This is a pull request implementing the features described at rust-lang/rfcs#3173.

[rust-highfive]

r? @yaahc

(rust-highfive has picked a reviewer for you, use r? to override)

[kpreid]

In the RFC you mention “Repeatedly calling next_up on a negative number will iterate over all values above it, with the exception of +0.0, only -0.0 will be visited.” I think this point would be good to make explicitly in the documentation of these functions — it is a place where the two goals “exhaust the space of float-representable numbers” and “move along the number line in the smallest nonzero step” differ, and it's worth mentioning this to, if nothing else, prompt the programmer to think about which thing they're doing and whether the function's inherent behavior is correct for their use case.

[scottmcm]

👍 to having these. I think we should explicitly mention that these are expected to match IEEE's nextUp and nextDown operations, and keep the next_up and next_down names.

I don't think we'll find any name that's substantially better, so sticking with precedent seems best.

(And we can add another thing with different names if there ends up being a desire to have something that doesn't follow IEEE exactly, like if there were one that visited every bit sequence.)

[yaahc]

Everything looks good and I don't think I have anything to add other than to say thank you for the wonderful PR! I'm gonna go ahead and merge this since it's all nightly only and then I'll start an FCP on the RFC since it's already there, might as well not waste it.

@bors r+

[bors]

📌 Commit 4dd9b85 has been approved by yaahc

[matthiaskrgr]

Some test were failing in a rollup, looks like it was caused by this PR: #90178 (comment)

@bors r-

[bors]

☔ The latest upstream changes (presumably #90314) made this pull request unmergeable. Please resolve the merge conflicts.

[orlp]

So investigating why my pull request failed, I'm not sure that it's my fault. This fails on i586:

f32::from_bits(0x7F955555).to_bits() == 0x7F955555

This violates the standard library guarantees, which say that from_bits and to_bits are transmutes.

It's not my code that failed either way, it's just that the way I wrote the testcase assumes from_bits and to_bits are sane and do not magically change my bits under the hood:

let nan0 = f32::NAN.to_bits();
let nan1 = f32::NAN.to_bits() ^ 0x002a_aaaa;
let nan2 = f32::NAN.to_bits() ^ 0x0055_5555;
assert_eq!(f32::from_bits(nan0).next_down().to_bits(), nan0);
assert_eq!(f32::from_bits(nan1).next_down().to_bits(), nan1);
assert_eq!(f32::from_bits(nan2).next_down().to_bits(), nan2);

[scottmcm]

NANs are always a bit weird, and pre-i686 floats are particularly annoying. You might be interested in the conversations in #73328

But honestly for now I'd just say cfg out that test on i586.

[matthiaskrgr]

Still failing in ci I guess: #91983 (comment)

@bors rollup=never r-

[orlp]

I don't know how it was marked to be ready to merged since we knew it was failing two weeks ago, sorry for wasting your time.

The problem is that x87 floating point is very problematic for this set of functions. At first I thought it was just NaN bits not being preserved, but it appears that it's also flushing denormals to zero, not just when doing arithmetic operations, but also when passing values through function boundaries.

I think I'll disable testing on x87 floating point platforms for now and indeed add an unresolved question to the tracking issue. I honestly don't know what to do with this platform.

[matthiaskrgr]

Oh strange, you're right I didn't see that.
Sometimes bors acts funny and the queue shows prs that were already unapproved as approved, guess that was one of those times.
Sorry for the noise... 😄

[goffrie]

This is technically not true for x = NAN.

[orlp]

Why not?

[orlp]

Oh I think I see what you're getting at, == here is to be understood as a bitwise / definition equality, not floating point comparison where NaN != NaN.

[orlp]

Should I update this doc comment to say "for all non-NaN x"? Or maybe reword it to "x.next_up() is equivalent to -(-x).next_down() for all x" to prevent confusion with == failing for NaNs?

[JohnCSimon]

ping from triage:
@orlp Can you address the review comments and resolve the conversation? we have some build failures, too.

When it's ready for review send a message containing
@rustbot ready to switch to S-waiting-on-review

[Dylan-DPC]

@orlp any updates on this?

[orlp]

@Dylan-DPC I think I've been procrastinating on this because I don't see a good solution. Today I'll update the tracking issue with the unresolved question on what to do with x87, disable the testing for that platform for now and push my changes.

[orlp]

I've posted the unresolved question to the tracking issue: #91399 (comment)

Should I wait with asking a review for this until the unresolved question is resolved or do it now @JohnCSimon ?

[bors]

☔ The latest upstream changes (presumably #94546) made this pull request unmergeable. Please resolve the merge conflicts.

[JohnCSimon]

@orlp - if you think it's ready for review, go ahead and mark it ready for review. I'm just doing PR triage.

[JohnCSimon]

@orlp
Ping from triage: I'm closing this due to inactivity, Please reopen when you are ready to continue with this.
Note: if you do please open the PR BEFORE you push to it, else you won't be able to reopen - this is a quirk of github.
Thanks for your contribution.

@rustbot label: +S-inactive