Inconsistent decimal places

[janten]

go-units removes trailing zeros in its output. This makes the output in Docker's progress indicators not line up.

Current:

cba48ac2c991: Downloading    23 MB/37.18 MB
f19be92d17a1: Downloading  24.3 MB/64.6 MB

Better:

cba48ac2c991: Downloading  23.0 MB/37.18 MB
f19be92d17a1: Downloading  24.3 MB/64.60 MB

One decimal place should be enough when dealing with sizes:

cba48ac2c991: Downloading  23.0 MB/37.2 MB
f19be92d17a1: Downloading  24.3 MB/64.6 MB

[calavera]

I agree, what do you think about opening a pull request? This should be fairly simple to fix 🙌

[boaz0]

If I may - fmt.Printf("%.4g\n", 10.0) prints 10, even though I was expecting to see 10.0.
Reading the fmt godoc:

%g %e for large exponents, %f otherwise

gives the impression that I guessed correctly.
So did I get the wrong idea or we need to open a ticket to the Golang team?
Either way, I would like to work on that.

Thanks.

[thaJeztah]

Oh, I think I once suggested this moby/moby#9977

[boaz0]

From the fmt unit tests it looks like I got the wrong impression.

I guess we need to replace the "%.4g" format anyway.

If you don't mind, I will figure it out and post a PR in the next days.

Also (taken from https://golang.org/pkg/fmt/)

For floating-point values, width sets the minimum width of the field and precision sets the number of places after the decimal, if appropriate, except that for %g/%G it sets the total number of digits. For example, given 123.45 the format %6.2f prints 123.45 while %.4g prints 123.5. The default precision for %e and %f is 6; for %g it is the smallest number of digits necessary to identify the value uniquely.

[janten]

Thanks everybody for looking into this. I do currently not have the time to write a PR myself.