Document precision considerations of Duration-float methods#155133
Merged
Conversation
A `Duration` is essentially a 94-bit value (64-bit sec and ~30-bit ns), so there's some inherent loss when converting to floating-point for `mul_f64` and `div_f64`. We could go to greater lengths to compute these with more accuracy, like rust-lang#150933 or rust-lang#154107, but it's not clear that it's worth the effort. The least we can do is document that some rounding is to be expected, which this commit does with simple examples that only multiply or divide by `1.0`. This also changes the `f32` methods to just forward to `f64`, so we keep more of that duration precision, as the range is otherwise much more limited there.
rustbot
added
S-waiting-on-review
Collaborator
|
r? @scottmcm rustbot has assigned @scottmcm. Use Why was this reviewer chosen?The reviewer was selected based on:
|
Collaborator
|
Member
|
This looks good to me. |
Member
|
Ok, no new API guarantees, it's just a note informing users about limited precision/lossiness. This was also previously discussed in an api-meeting which was generally on board with the idea of just clarifying instead of wasting performance on slightly improving precision. LGTM @bors r+ |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
rust-bors Bot
pushed a commit
that referenced
this pull request
Apr 22, 2026
…uwer Rollup of 10 pull requests Successful merges: - #154794 (Add on_unmatch_args) - #155133 (Document precision considerations of `Duration`-float methods) - #154283 (Remove `nodes_in_current_session` field and related assertions) - #155374 (rustdoc: fix a few spots where emit isn't respected) - #155587 (Immediately feed visibility on DefId creation) - #155622 (c-variadic: `va_arg` fixes ) - #155629 (rustc_public: Add `constness` & `asyncness` in `FnDef`) - #155632 (Some metadata cleanups) - #155639 (BinOpAssign always returns unit) - #155647 (rustc-dev-guide subtree update)
rust-timer
added a commit
that referenced
this pull request
Apr 22, 2026
Rollup merge of #155133 - cuviper:duration_fp_docs, r=the8472 Document precision considerations of `Duration`-float methods A `Duration` is essentially a 94-bit value (64-bit sec and ~30-bit ns), so there's some inherent loss when converting to floating-point for `mul_f64` and `div_f64`. We could go to greater lengths to compute these with more accuracy, like #150933 or #154107, but it's not clear that it's worth the effort. The least we can do is document that some rounding is to be expected, which this commit does with simple examples that only multiply or divide by `1.0`. This also changes the `f32` methods to just forward to `f64`, so we keep more of that duration precision, as the range is otherwise much more limited there.
github-actions Bot
pushed a commit
to rust-lang/rustc-dev-guide
that referenced
this pull request
Apr 24, 2026
…uwer Rollup of 10 pull requests Successful merges: - rust-lang/rust#154794 (Add on_unmatch_args) - rust-lang/rust#155133 (Document precision considerations of `Duration`-float methods) - rust-lang/rust#154283 (Remove `nodes_in_current_session` field and related assertions) - rust-lang/rust#155374 (rustdoc: fix a few spots where emit isn't respected) - rust-lang/rust#155587 (Immediately feed visibility on DefId creation) - rust-lang/rust#155622 (c-variadic: `va_arg` fixes ) - rust-lang/rust#155629 (rustc_public: Add `constness` & `asyncness` in `FnDef`) - rust-lang/rust#155632 (Some metadata cleanups) - rust-lang/rust#155639 (BinOpAssign always returns unit) - rust-lang/rust#155647 (rustc-dev-guide subtree update)
Contributor
|
Crater found a crate with a test that regressed, presumably due to this PR changing the precision of |
Member
Author
|
Yes, I think that's expected and acceptable -- in fact their division failure is the exact same operation updated in our own doctest here. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A
Durationis essentially a 94-bit value (64-bit sec and ~30-bit ns),so there's some inherent loss when converting to floating-point for
mul_f64anddiv_f64. We could go to greater lengths to compute thesewith more accuracy, like #150933 or #154107,
but it's not clear that it's worth the effort. The least we can do is
document that some rounding is to be expected, which this commit does
with simple examples that only multiply or divide by
1.0.This also changes the
f32methods to just forward tof64, so we keepmore of that duration precision, as the range is otherwise much more
limited there.