-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Improve floating point documentation #95483
Conversation
- Refine the "NaN as a special value" top level explanation of f32 - Refine `const NAN` docstring. - Refine `fn is_sign_positive` and `fn is_sign_negative` docstrings. - Refine `fn min` and `fn max` docstrings. - Refine `fn trunc` docstrings. - Refine `fn powi` docstrings. - Refine `fn copysign` docstrings. - Reword `NaN` and `NAN` as plain "NaN", unless they refer to the specific `const NAN`. - Reword "a number" to `self` in function docstrings to clarify. - Remove "Returns NAN if the number is NAN" as this is told to be the default behavior in the top explanation. - Remove "propagating NaNs", as full propagation (preservation of payloads) is not guaranteed.
r? @yaahc (rust-highfive has picked a reviewer for you, use r? to override) |
Also attempts to fix (documentation issues of) #71355 |
…}_{be,le,ne}_bytes
I think that people who were active over #72599 might have something to say about the wording here...? |
I think it might be a good idea to keep the original wording of
as you'd otherwise require the reader to read the whole documentation instead of just the one on the function they're interested in. |
@tbu- I see. In that case, I think we should add it to other operations too. That's entirely doable, but bloats the explanations a bit. |
It's especially interesting for the
Which other functions were you thinking about? For stuff like |
Well, I only removed the "Returns |
Ah, sorry, I pointed out the wrong thing then. Thanks for your patience with me. :) You removed the NaN propagation from the first line of the |
Ahh, I see the problem now: the one-line explanation could be better indeed. I thought the explanation of the semantics after the first line was pretty thorough, so mentioning "propagating NaNs" on the first line wouldn't be needed. The reason I decided to remove it is because I thought the word "propagating" would falsely give the impression that the "propagation/conservation" of NaN bitpatterns would be guaranteed, while making a point not to guarantee that was an important motivation for this PR. (As you can see from the refined "NaN as a special value" top level explanation). |
…NaN" to `max`/`min`, add disclaimer about the "propagation".
@tbu- How about this? |
This comment has been minimized.
This comment has been minimized.
Yes, this is a lot better, thanks for following up on my comments. :) |
I'm reassigning this PR because I'm taking a break from the review rotation for a little while. Thank you for your patience. r? rust-lang/libs |
@yaahc It's totally OK! Btw. it just crossed my mind that we should maybe document things around denormals better too. This PR is somewhat focused to NaN, but I think subnormals have similar problems as NaN patterns: apparently some hardware don't allow for gradual loss of precision, but I'm totally unaware which pieces of hardware, and whether those are currently supported in any capacity by Rust. Also, I wonder what are LLVM's commitments to protect deterministicness of calculations with subnormals. |
TIL that we have both This documentation seems like an improvement across the board, thank you! Posted suggestions with minor grammatical nits. r=me with those applied. |
@bors d+ |
@bors r=joshtriplett |
@golddranks: 🔑 Insufficient privileges: Not in reviewers |
@joshtriplett Sorry, it seems that bors didn't accept the delegation command. Could you accept it? |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
@bors r=joshtriplett |
📌 Commit dea7765 has been approved by |
@davidtwco Thank you! |
@bors delegate+ |
✌️ @golddranks can now approve this pull request |
Yeah, we have both, but that's because IEEE also has both -- though IIRC it has deprecated |
Yep, the standard |
@bors rollup=always |
…askrgr Rollup of 6 pull requests Successful merges: - rust-lang#95483 (Improve floating point documentation) - rust-lang#96008 (Warn on unused `#[doc(hidden)]` attributes on trait impl items) - rust-lang#96841 (Revert "Implement [OsStr]::join", which was merged without FCP.) - rust-lang#96844 (Actually fix ICE from rust-lang#96583) - rust-lang#96854 (Some subst cleanup) - rust-lang#96858 (Remove unused param from search.js::checkPath) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This is my attempt to improve/solve #95468 and #73328 .
Added/refined explanations:
const NAN
docstring: add an explanation about there being multitude of NaN bitpatterns and disclaimer about the portability/stability guarantees.fn is_sign_positive
andfn is_sign_negative
docstrings: add disclaimer about the sign bit of NaNs.fn min
andfn max
docstrings: explain the semantics and their relationship to the standard and libm better.fn trunc
docstrings: explain the semantics slightly more.fn powi
docstrings: add disclaimer that the rounding behaviour might be different frompowf
.fn copysign
docstrings: add disclaimer about payloads of NaNs.minimum
andmaximum
: add disclaimer that "propagating NaN" doesn't mean that propagating the NaN bit patterns is guaranteed.max
andmin
docstrings: add "ignoring NaN" to bring the one-row explanation to parity withminimum
andmaximum
.Cosmetic changes:
NaN
andNAN
as plain "NaN", unless they refer to the specificconst NAN
.self
in function docstrings to clarify.abs
, as this is told to be the default behavior in the top explanation.