Question

$ printf "%0.2f\n" 41.495
41.49
$ printf "%0.2f\n" 41.485
41.49
$ printf "%0.2f\n" 41.475
41.47
$ printf "%0.2f\n" 41.465
41.47
$ printf "%0.2f\n" 41.455
41.46
$ printf "%0.2f\n" 41.445
41.44
$ printf "%0.2f\n" 41.435
41.44
$ printf "%0.2f\n" 41.425
41.42
$ printf "%0.2f\n" 41.415
41.42
$ printf "%0.2f\n" 41.405
41.40

Why are the numbers with an uneven number as the second decimal not correctly rounded and even ones are? Additionally what is wrong with .445 that it never gets rounded?

Answer 1

It has to do with floating-point, but not with double-precision.

When you write

printf "%0.2f\n" 41.495

on your system, printf first rounds 41.495 to the closest x87 80-bit floating-point number[1]. How does that work? First write 41.495 in binary:

b101001.0111 11101011100001010001 11101011100001010001 11101011100001010001 ...

(the separated groups repeat ad infinitum). Now we round this number to have 64 binary digits:

b101001.0111111010111000010100011110101110000101000111101011100001

This is the number that is actually formatted by printf. Written in decimal, it is exactly:

41.4949999999999999990285548534529880271293222904205322265625

as you can see, it is just a little bit less than 41.495, so when printf rounds it to two fractional digits, it rounds down, and 41.49 is printed.

Now look at 41.485; after rounding to 64 binary digits, we get the value:

41.48500000000000000055511151231257827021181583404541015625

which is just a little bit bigger than 41.485, so printf rounds it up.

On my system, there is a warning about this in the printf manage:

Since the floating point numbers are translated from ASCII to floating-point and then back again, floating-point precision may be lost.

---

1. bash doesn’t use the x87 format on all operating systems (indeed, it isn’t even available on all architectures); on some other systems these values will be interpreted as doubles (and therefore rounded to 53 bits instead of 64), and the results will differ.