[deleted]
Rounding Percentages
11–20 of 30 posts
Re: Rounding Percentages
#12> If your language has bad defaults, you may have to ask for the right rounding mode explicitly.
Is the author implying Rust's default rounding behavior is a bad default? In what world is "ties to even" a GOOD default?
Re: Rounding Percentages
#13A good rule is that showing progress or a stuck state appropriately at all stages takes precedence over other concerns in a progress bar.
So for a video upload from a photo app it's not at all unreasonable to make the first 50% the transcoding step and the second 50% the actual upload and show progress of each step within those percentages. Some people may read this with horror; the transcoding step might be much faster/slower! It's not accurate! But the point is the user can at least see progress/no progress. You aren't allowing an upload bar to sit at 0% because you prioritised a % accurate upload over a progress bar that represents all stages of progress. It's better the progress bar move faster/slower at various stages than a progress bar that simply misses stages.
This goes for loading screens that sit at 100% for a while too. I'd prefer if they reserved some percentage of the loading bar for those 'post 100%' steps and continued to show progress. End users won't care if it's not all the same speed as much as they'll care about stuck progress bars.
Re: Rounding Percentages
#14A good rule is that showing progress or a stuck state appropriately at all stages takes precedence over other concerns in a progress bar. So for a video upload from a photo app it's not at all unreasonable to make the first 50% the transcoding step and the second 50% the actual upload and show progress of each step within those percentages. Some people may read this with horror; the transcoding step might be much fas…
If you can cleanly segment the loading progress into multiple steps, you may as well render a label above the loading bar that says what it’s currently doing.
Re: Rounding Percentages
#15A good rule is that showing progress or a stuck state appropriately at all stages takes precedence over other concerns in a progress bar. So for a video upload from a photo app it's not at all unreasonable to make the first 50% the transcoding step and the second 50% the actual upload and show progress of each step within those percentages. Some people may read this with horror; the transcoding step might be much fas…
If you can cleanly segment the loading progress into multiple steps, you may as well render a label above the loading bar that says what it’s currently doing.
We're often limited to showing progress on a percentage bar UX wise for various reasons, particularly on mobile devices. I'd also give thought that each technical step may as well read something similar to 'reticulating splines' as far as an end user is concerned.
Re: Rounding Percentages
#16Earlier quoted context omitted.
If you can cleanly segment the loading progress into multiple steps, you may as well render a label above the loading bar that says what it’s currently doing.
We're often limited to showing progress on a percentage bar UX wise for various reasons, particularly on mobile devices. I'd also give thought that each technical step may as well read something similar to 'reticulating splines' as far as an end user is concerned.
Usually even technical terms are interesting since you have to wait anyway. Makes your imagination go.
Unfortunately it is much rarer nowadays and everything is hidden away.
Re: Rounding Percentages
#17> If your language has bad defaults, you may have to ask for the right rounding mode explicitly. Is the author implying Rust's default rounding behavior is a bad default? In what world is "ties to even" a GOOD default?
The motivation for the seemingly strange rounding is that a set of numbers can be rounded before summing without biasing the sum. It has good use cases but so do all rounding modes.
Re: Rounding Percentages
#18Earlier quoted context omitted.
If you can cleanly segment the loading progress into multiple steps, you may as well render a label above the loading bar that says what it’s currently doing.
We're often limited to showing progress on a percentage bar UX wise for various reasons, particularly on mobile devices. I'd also give thought that each technical step may as well read something similar to 'reticulating splines' as far as an end user is concerned.
The time a user will read it is when the program stalls unexpectedly on a particular step. A support ticket or forum post which includes the step it stopped at will be easier to troubleshoot.
Re: Rounding Percentages
#19Earlier quoted context omitted.
We're often limited to showing progress on a percentage bar UX wise for various reasons, particularly on mobile devices. I'd also give thought that each technical step may as well read something similar to 'reticulating splines' as far as an end user is concerned.
Usually even technical terms are interesting since you have to wait anyway. Makes your imagination go. Unfortunately it is much rarer nowadays and everything is hidden away.
Reticulating splines
Re: Rounding Percentages
#20I just got reminded that round(0.5) is poorly defined across different languages and your results may vary if you use this algorithm without properly understanding what round() does in your language vs. what is expected by the algorithm.
It is especially ill-defined when the input itself may have been rounded already, e.g. round(0.15, 1) = 0.1 because 0.15 is not exact in binary64 and the binary64 value closest to 0.15 is a bit smaller than 0.15. If you have to retain the exact rounded value for some reason, you should switch to fixed point from that point on.