-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Automatic exponential formatting in Debug #86479
Conversation
* {:.PREC?} already had legitimately useful behavior (recursive formatting of structs using fixed precision for floats) and I suspect that changes to the output there would be unwelcome. (besides, precision introduces sinister edge cases where a number can be rounded up to one of the thresholds) Thus, the new behavior of Debug is, "dynamically switch to exponential, but only if there's no precision." * This could not be implemented in terms of float_to_decimal_common without repeating the branch on precision, so 'float_to_general_debug' is a new function. The name is '_debug' instead of '_common' because the considerations in the previous bullet make this logic pretty specific to Debug. * 'float_to_decimal_common' is now only used by Display, so I inlined the min_precision argument and renamed the function accordingly.
(rust-highfive has picked a reviewer for you, use r? to override) |
r? @yaahc since you left rust-lang/rfcs#2729 (comment) |
I'm not sure it's accurate to call this a breaking change, or I at least worry it will be misleading. We explicitly don't consider
If you wanted to go ahead and add some tests for the manual precision case that would be extremely appreciated though it is not required. |
Triage: What's next steps here? |
I think next steps are to run a crater experiment. @bors try |
⌛ Trying commit 8731d4d with merge 9bcd538c2638edd572fdfcbb0adddf2b83c494c3... |
💔 Test failed - checks-actions |
A job failed! Check out the build log: (web) (plain) Click to see the possible cause of the failure (guessed by this bot)
|
Looks like some sort of git error, not sure what's up with that... I guess let's see if that was a fluke. @bors retry |
⌛ Trying commit 8731d4d with merge d2e9fff28e244f1ea4927194f1f9b77f93e2ffe2... |
☀️ Try build successful - checks-actions |
@craterbot build-and-test |
🚨 Error: failed to parse the command 🆘 If you have any trouble with Crater please ping |
@craterbot run |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
I reviewed the results of the crater run and it seems like only 2 or 3 of the test failures were due to the float formatting change.
The rest seem to all be spurious failures. This seems like an acceptable level of breakage to me. I'm going to start an FCP since this does change runtime behavior, though this is category of runtime breakage that we explicitly reserve the right to make, so I'm going to treat this as a @rust-lang/libs issue rather than a libs-api issue. @rfcbot merge |
Team member @yaahc has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
Perhaps the relevant code authors should be tagged so they can update the affected projects?
For this small sample of three results it surprises me how different they are:
|
@ExpHP thanks for letting me know! My code is now fixed: https://github.com/cpmech/russell/pull/32/commits |
Not to nitpick, but I personally think a threshold of 1e-6 might be more readable more often. Either way, though: |
I don't disagree. The choice of this large threshold was partly motivated by the similarly large thresholds in languages like Javascript and Python where this formatting is done automatically. That said, it occurs to me now that python has implicit |
To clarify, I think 1e16 is a fine upper threshold. I'm suggesting that the lower threshold should be lowered to 1e-6, allowing (for instance) 0.00003 to display without switching to exponential notation. |
Ah. I misread. There is precedence for 1e-6 in Javascript, but I think 1e-4 is more common. I guess this boils down to personal preference. When I see |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
Thanks @ExpHP for the ping, I went with the regular Display impl because the trailing |
@bors r+ |
📌 Commit 8731d4d has been approved by |
Rollup of 10 pull requests Successful merges: - rust-lang#86479 (Automatic exponential formatting in Debug) - rust-lang#87404 (Add support for artifact size profiling) - rust-lang#87769 (Alloc features cleanup) - rust-lang#88789 (remove unnecessary bound on Zip specialization impl) - rust-lang#88860 (Deduplicate panic_fmt) - rust-lang#90009 (Make more `From` impls `const` (libcore)) - rust-lang#90018 (Fix rustdoc UI for very long type names) - rust-lang#90025 (Revert rust-lang#86011 to fix an incorrect bound check) - rust-lang#90036 (Remove border-bottom from most docblocks.) - rust-lang#90060 (Update RELEASES.md) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Context: See this comment from the libs team
Makes
"{:?}"
switch to exponential for floats based on magnitude. The libs team suggested exploring this idea in the discussion thread for RFC rust-lang/rfcs#2729. (note: this is not an implementation of the RFC; it is an implementation of one of the alternatives)Thresholds chosen were 1e-4 and 1e16. Justification described here.
This will require a crater run.
As mentioned in the commit message of 8731d4d, this behavior will not apply when a precision is supplied, because I wanted to preserve the following existing and useful behavior of
{:.PREC?}
(which recursively applies{:.PREC}
to floats in a struct):I looked around and am not sure where there are any tests that actually use this in the test suite, though?
All things considered, I'm surprised that this change did not seem to break even a single existing test in
x.py test --stage 2
. (even when I tried a smaller threshold of 1e6)