Re: Precision in the progress meter

On Tue, 18 Nov 2025, Nicolas George via curl-users wrote:

> I am not really seeing a difference between your two series of examples: 
> four significant digits plus decimal point plus unit prefix equals six 
> characters, one more significant digit when decimal point not necessary, and 
> one more when the prefix is absent.

What I have merged now is 5 digits when there is no unit present (plain 
bytes), then NNN.Mu when there is a unit there.

I opted to go with this simple version even when the decimal is 0 just to 
avoid frequent switching between layouts. Like when 99.9k goes to 100.0k and 
then 100.1k. It does not switch to 100k in between to avoid the extra flicker.

> Two significant digits like coreutils does at it worst is not enough. I 
> think three significant digits starts to be enough. Four is absolutely fine.

> In other words (showing padding with an underscore):
>
> 	_9999K

The current model goes for displaying < 1000 numbers with units so 9999 KiB 
instead shows as 9.8M.

> 	9.766M

We stick to single precision float: 9.8M. Even if of course anumber below 100 
or 10 *can* have more precision in the output. Again, I picked a fixed format 
to make it move between 9.9 to 10.0 instead of 9.99 to 10.0. In particular 
perhaps interesting when that is used for transfer speeds, as they might 
toggle back and forth quite a lot.

We can of course also try with adding two-digit fractions when displaying less 
than 100 with unit. Might be worth testing to get a feel for how that looks.

-- 

  / daniel.haxx.se || https://rock-solid.curl.dev
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
Etiquette:   https://curl.se/mail/etiquette.html