Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: Precision in the progress meter
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-users <curl-users_at_lists.haxx.se>
Date: Wed, 19 Nov 2025 13:16:02 +0100 (CET)
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.
Date: Wed, 19 Nov 2025 13:16:02 +0100 (CET)
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.htmlReceived on 2025-11-19