Skip to content
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

Expose tests for {f32,f64}.total_cmp in docs #115412

Merged
merged 1 commit into from
Nov 18, 2023

Conversation

eswartz
Copy link
Contributor

@eswartz eswartz commented Aug 31, 2023

Expose tests for {f32,f64}.total_cmp in docs

Uncomment the helpful assert_eq! line, which is stripped out completely in docs, and leaves the reader to mentally play through the algorithm, or go to the playground and add a println!, to see what the result will be.

(If these tests are known to fail on some platforms, is there some mechanism to conditionalize this or escape the test so the assert_eq! source will be visible on the web? I am a newbie, which is why I was reading docs ;)

@rustbot
Copy link
Collaborator

rustbot commented Aug 31, 2023

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @scottmcm (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 31, 2023
@eswartz
Copy link
Contributor Author

eswartz commented Aug 31, 2023

Hmm, I see that #73328 might already explain why this is commented out (i.e. that the sign bit may change on NaN unexpectedly under some optimization cases) but I'm not sure this would occur with the constants used in the sample code.

@RalfJung
Copy link
Member

RalfJung commented Sep 5, 2023

It might be due to #115567, in which case adding a suitable cfg that disables the assertion on target_arch = "x86" might help.

@RalfJung
Copy link
Member

RalfJung commented Sep 5, 2023

OTOH, # means the test is actually being run, so I guess it does work despite #115567. I see no reason why we'd hide this test from users.

@workingjubilee
Copy link
Member

I'm approving this under the interpretation that a test passing does not constitute an API guarantee.

@bors r+

@bors
Copy link
Contributor

bors commented Oct 6, 2023

📌 Commit b7d8417 has been approved by workingjubilee

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 6, 2023
@RalfJung
Copy link
Member

RalfJung commented Oct 6, 2023

I do generally interpret doctests that are shown in rustdoc as lib API guarantees. If I can't rely on the explicitly given examples then what can I rely on?

@workingjubilee
Copy link
Member

Ah, well,
@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 6, 2023
@workingjubilee workingjubilee added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed T-libs Relevant to the library team, which will review and decide on the PR/issue. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 6, 2023
@RalfJung
Copy link
Member

RalfJung commented Oct 6, 2023

That said, is there any reason not to make this an API guarantee?

@scottmcm
Copy link
Member

scottmcm commented Oct 6, 2023

Hmm, seems like it'd have to be a lang guarantee, no? Because it's obviously a guarantee in a world where the library code always gets exactly the nans they wrote, and they never change out from under them.

This test needs it to stay the canonical nan, I guess, since it's comparing with to_bits()? If NANs are allowed to spuriously change when passed around or loaded, it's not trivially true to me that that would continue to work...

I guess the test could be updated to check bits-equal for everything except the NAN, and check is_nan for the other? That would be guaranteed, I think. (Especially if it worked by removing the NANs from both ends as the way to find the things that will be exact bits-equal.)

@RalfJung
Copy link
Member

RalfJung commented Oct 6, 2023

Don't we have consensus that NaN bits stay stable when floats are just passed around?

Should we do t-lang FCP on that question? This doesn't have to wait for the broader set of questions around what exactly the NaNs are that come out of a float operation.

@RalfJung
Copy link
Member

RalfJung commented Oct 6, 2023

Though I guess there also is the question of what we guarantee about the bit pattern in f32::NAN, except that it is a NAN. For instance, do we guarantee the sign? The test will fail if it becomes a negative NAN one day.

The docs about that constant even explicitly say

This constant isn’t guaranteed to equal to any specific NaN bitpattern, and the stability of its representation over Rust versions and target platforms isn’t guaranteed.

So, in that sense the test is already bogus.

@eswartz eswartz force-pushed the docs/total_cmp-test-result-in-docs branch from b7d8417 to 08f10c2 Compare October 6, 2023 21:13
@eswartz
Copy link
Contributor Author

eswartz commented Oct 6, 2023

Given the discussion, I updated the PR to make it clear there may be different results. (My main concern was just seeing an example with an expected output, since "#" inside the comment -- likely done for the same reasons discussed here -- was stripped out of the HTML.)

@rust-log-analyzer

This comment has been minimized.

Comment on lines 1427 to 1439
/// ```
/// Since the NaN constant does not have a well-defined sign,
/// this test may result in either:
/// ```
/// assert!(bois.into_iter().map(|b| b.weight)
/// .zip([-5.0, 0.1, 10.0, 99.0, f32::INFINITY, f32::NAN].iter())
/// .all(|(a, b)| a.to_bits() == b.to_bits()))
/// ```
/// or:
/// ```
/// assert!(bois.into_iter().map(|b| b.weight)
/// .zip([f32::NAN, -5.0, 0.1, 10.0, 99.0, f32::INFINITY].iter())
/// .all(|(a, b)| a.to_bits() == b.to_bits()))
Copy link
Member

@workingjubilee workingjubilee Oct 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of separating this out (and getting error messages when it can't be compiled) why not make this logical disjunction part of the code: simply wrap this in

if f32::NAN.is_sign_negative() {
   assert!(..)
} else {
   assert!(..)
};  

Copy link
Contributor Author

@eswartz eswartz Oct 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done (for real?)

@workingjubilee workingjubilee added T-lang Relevant to the language team, which will review and decide on the PR/issue. and removed T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Oct 6, 2023
@workingjubilee
Copy link
Member

Don't we have consensus that NaN bits stay stable when floats are just passed around?

They should. They should support checking their sign without that changing, too.

@eswartz eswartz force-pushed the docs/total_cmp-test-result-in-docs branch 2 times, most recently from cfc285d to 2a62677 Compare October 6, 2023 22:50
/// # .zip([-5.0, 0.1, 10.0, 99.0, f32::INFINITY, f32::NAN].iter())
/// # .all(|(a, b)| a.to_bits() == b.to_bits()))
///
/// if f32::NAN.is_sign_negative() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// if f32::NAN.is_sign_negative() {
//// // `f32::NAN` could be positive or negative, which will affect the sort order.
/// if f32::NAN.is_sign_negative() {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Applied (manually) since f64.fs also needs the change.

Uncomment the assert! line and account and document that the sign
of NaN is not positive, necessarily.
@eswartz eswartz force-pushed the docs/total_cmp-test-result-in-docs branch from 2a62677 to 8066079 Compare October 7, 2023 16:19
Copy link
Member

@RalfJung RalfJung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@scottmcm
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Nov 18, 2023

📌 Commit 8066079 has been approved by scottmcm

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 18, 2023
@bors
Copy link
Contributor

bors commented Nov 18, 2023

⌛ Testing commit 8066079 with merge 6416e2e...

@bors
Copy link
Contributor

bors commented Nov 18, 2023

☀️ Test successful - checks-actions
Approved by: scottmcm
Pushing 6416e2e to master...

1 similar comment
@bors
Copy link
Contributor

bors commented Nov 18, 2023

☀️ Test successful - checks-actions
Approved by: scottmcm
Pushing 6416e2e to master...

@bors bors added merged-by-bors This PR was explicitly merged by bors. labels Nov 18, 2023
@bors bors merged commit 6416e2e into rust-lang:master Nov 18, 2023
12 checks passed
@rustbot rustbot added this to the 1.76.0 milestone Nov 18, 2023
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (6416e2e): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.6% [0.6%, 0.6%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.3% [-2.3%, -2.3%] 1
All ❌✅ (primary) 0.6% [0.6%, 0.6%] 1

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
3.2% [3.2%, 3.2%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.4% [-3.1%, -1.9%] 6
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 678.192s -> 675.683s (-0.37%)
Artifact size: 313.84 MiB -> 313.83 MiB (-0.00%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants