-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Improve floating point documentation #95483
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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.