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.

Sign up for GitHub

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

Jump to bottom

PowerToys Run - Unit Conversion: Preserve all significant figures from the integer part of the result #25789

Open
DL444 opened this issue May 1, 2023 · 5 comments
Open

PowerToys Run - Unit Conversion: Preserve all significant figures from the integer part of the result #25789

DL444 opened this issue May 1, 2023 · 5 comments
Labels
Needs-Triage For issues raised to be triaged and prioritized by internal Microsoft teams

Comments

@DL444
Copy link

DL444 commented May 1, 2023

Description of the new feature / enhancement

Currently, the unit conversion plugin in PowerToys Run forces the rounding of results to 5 significant figures (UnitHandler.cs:107). Even though it seems that this behavior is by design (UnitHandlerTest.cs:106), I believe it can cause trouble for results that do have more significant figures in their integer part.

For example, it can be expected for queries %% 1234567 m to cm and %% 1 MiB to Bytes to produce results 123456700 cm and 1048576 Bytes respectively. But the actual results from the tool are rounded to 123460000 cm and 1048600 Bytes, which is especially unfortunate for the latter case.

Therefore, I propose that we preserve at least all significant figures from the integer part of the result, and then probably more from the decimal part. Alternatively, a switch or query parameter can be implemented to skip the rounding all together. It can also be desirable to be able to configure how many significant figures to preserve when rounding does happen (maybe I'm asking for too much here).

Scenario when this would be used?

All unit conversions with a result having a lot of significant digits in the integer part will benefit from this change. Especially for binary (1024-based) data volume conversions, whose results tend to be this way.

Supporting information

No response
@DL444 DL444 added the Needs-Triage For issues raised to be triaged and prioritized by internal Microsoft teams label May 1, 2023
@PesBandi PesBandi mentioned this issue Sep 12, 2024
Open
@ethanfangg
Copy link
Contributor

go for it @PesBandi !

@PesBandi
Copy link
Contributor

Hi @ethanfangg, should I just remove the Round() function and have it formatted later with G14 (14 significant places; that already happens, but only has an effect on large numbers i.e. use scientific notation when the number is over 14 digits), or should I add some more complicated logic?

@ethanfangg
Copy link
Contributor

I agree with the author here that we should "preserve at least all significant figures from the integer part of the result" plus minimum maybe 2 decimals.

Additionally, for irrational numbers, or results that would exceed the number of characters we would typically show (say 14 for example), then we should include an ellipses.

The copy action should attempt to be as accurate as possible within the bounds of not copying infinitely long numbers, again here maybe limited to a certain character amount.

At minimum here, I would like to get rid of mis-leading behavior around rounding and instead show ellipses and/or additional sig figs.

@PesBandi
Copy link
Contributor

Hi @ethanfangg, thanks for the quick response.
This is my current implementation, let me know what you think

  • Title:
    • Use G14 - rounds to 14 sig figs and shows scientific notation above 14 digits
    • Show an ellipses when decimal places are cut off
    • Issue #​1: If the result has exactly 14 digits in the integer part (e.g. 12345678901234.1) it will display 12345678901234.... I'm not sure what the right behavior here should be. On one hand, .1 was cut off, but on the other, adding ... to the end of an integer seems weird.
    • Issue #​2: G14 rounds the number up, so for example 1.234...789 would display as 1.234...79, which is technically incorrect. I know this isn't a difficult issue to solve, I just don't think it's worth the effort/computation time.
  • Copy:
    Format with R - uses scientific above e+17 and cuts off the decimal part at the double limit. (This causes some inaccuracy with very large/small numbers, not sure what I can do about that)

@PesBandi
Copy link
Contributor

Another thing to consider is adding an ellipsis to scientific notation.
Should it be 1.2345678…E-14 or just 1.2345678E-14. I would personally prefer the latter, but I'd appreciate someone else's opinion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Needs-Triage For issues raised to be triaged and prioritized by internal Microsoft teams
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@DL444 @ethanfangg @PesBandi