'%.2f' %(1/8) does not round correctly

[jowagner]

Bug report

Rounding with '%.2f' does not work as expected for numbers that are precisely represented in binary.

Minimal, reproducible example:

>>> '%.2f' %0.125
'0.12'

Note that 0.125 is precisely represented in binary as 0.125 = 2**(-3) and the exponent range of the default float type is sufficient to cover the exponent -3.

The discussion of a similar case but with a not precisely represented number in issue #49368 indicates that 0.125 should be rounded up to 0.13.

I understand why issue #49368 is invalid: We expect a loss when decimal numbers in source code are converted to the internal representation. This is not the case here as 0.125 is converted to binary without any loss.

Workaround

In my main use cases, I can work with fractions, e.g. reporting accuracy as count_correct / count_total. However, %.2f does not seem to support fractions properly:

>>> '%.2f' %Fraction(1, 8)
'0.12'

Presumably, '%.2f' first converts the fraction to float. (Side note: How about a feature request to fix this?)

Therefore, I wrote the following helper function:

from fractions import Fraction

def my_frac2decimal(n, d, prec = 2):
    retval = []
    if n*d < 0:
        retval.append('-')
        n = -n
    f = Fraction(n, d)
    f += Fraction(5, 10**(prec+1))
    # integer part
    i = f.numerator // f.denominator
    retval.append('%d' %i)
    # reduce to 0. fraction
    f -= Fraction(i)
    while prec > 0:
        if '.' not in retval:
            retval.append('.')
        f = f * Fraction(10)
        i = f.numerator // f.denominator
        assert 0 <= i <= 9
        retval.append('%d' %i)
        f -= Fraction(i)
        prec -= 1
    return ''.join(retval)

This also avoids issues with binary floating point numbers, e.g. for 2.545 from issue #49368

>>> my_frac2decimal(2545, 1000)
'2.55'

Environment

• CPython versions tested on: 3.7.3, 3.6.15 and 2.7.18
• Operating system and architecture: Debian 10 and openSUSE Leap 15.3

[pochmann]

What part in issue #49368 indicates that 0.125 should be rounded up to 0.13?

[stevendaprano]

From the documentation of round:

"if two multiples are equally close, rounding is done toward the even choice"

This is called Banker's Rounding or Round To Even, and is chosen because it has less bias on average than schoolroom rounding that always rounds half-way value up.

String formatting codes should do the same. And so we see:

>>> '%.2f' % 0.125  # rounds down to nearest even
'0.12'
>>> '%.2f' % 0.375  # rounds up to nearest even
'0.38'

So there's no bug here, the behaviour is correct.

[jowagner]

What part in issue #49368 indicates that 0.125 should be rounded up to 0.13?

The fact that the rounding behaviour expected by user Ultrasick is not rejected based on an alternative rounding behaviour such as "we always round towards zero" but based on that the number 2.545 is internally represented as a number that is smaller than 2.545, namely 2.5449999999999999289457264239899814128875732421875.

[stevendaprano]

However, %.2f does not seem to support fractions properly

I don't know why you think that. Your sample code shows that it does support fractions correctly. Rounding one eighth to two decimal places has to either round up to 0.13, or down to 0.12, which is what you get.

And yes, the %f code converts to float. That is part of the design of % formatting, which is supposed to be a close match to printf formatting from C.

% formatting is not going to change, that would be too difficult and would break too many programs. If you have specialist formatting needs, you can write your own formatting functions, or explore the format builtin.

[jowagner]

[...] the documentation of round

Interesting. Now we only need to find documentation that '%.f' uses this type of rounding and the issue can be closed.

[pochmann]

The fact that the rounding behaviour expected by user Ultrasick is not rejected based on an alternative rounding behaviour [...]

That doesn't indicate it. Wouldn't make sense to talk about rounding behaviour for equal-distance cases when you don't have one.

[jowagner]

'%f' formatting in https://docs.python.org/3/library/string.html refers to https://docs.python.org/3/library/decimal.html#decimal.Decimal and says that "coefficient digits" are printed. This suggests that digits are simply truncated. However, this is clearly not the case:

>>> '%.2f' %2.549
'2.55'
>>> from decimal import Decimal
>>> Decimal(2.549)
Decimal('2.548999999999999932498440102790482342243194580078125')

I assume here that coefficients are 2, 5, 4, 8, 9, ...

[pochmann]

The full sentence:

With no precision given, uses a precision of 6 digits after the decimal point for float, and uses a precision large enough to show all coefficient digits for Decimal.

Your '%.2f' %2.549 is three things away from the "coefficient digits": You do give a precision, so the whole sentence doesn't apply. And you're in the float branch of the sentence, not the Decimal branch. Also, that whole thing is about str.format, not about printf-style String Formatting.

[pochmann]

So this is what that talks about, showing all those digits:

from decimal import Decimal
print('{:f}'.format(Decimal(2.549)))

Output:

2.548999999999999932498440102790482342243194580078125

[pochmann]

I don't see the documentation specifying whether the result of '%.2f' % 0.125 should be '0.12' or '0.13'. But it's called "printf-style String Formatting" and it says "The effect is similar to using the sprintf() in the C language". And looking around, it seems that C's printf/sprintf also doesn't specify it but usually does "nearest, ties to even". See for example Stack Overflow answer or bug report (where 0.13 was considered wrong and it got fixed to 0.12).

[jowagner]

Thanks for noticing and pointing out I was using in a wrong section in the documentation.

Yes, I also see nothing about rounding in printf-style formatting.

Before updating the documentation, it would be nice to know more whether there is a specification and whether the behaviour is different on different platforms. Should we wait a few weeks to see if anybody else has something to comment before attempting a PR with a documentation update?

[mdickinson]

Documenting this in a way that's both correct and helpful is tricky. There's no guarantee on the rounding behaviour at the level of the Python language. It's true that for the CPython implementation, on most machines, both old-style (%-based) and new-style (.format or f-string based) formatting do round-ties-to-even, but it's still not true for all machines. The correct rounding comes from the use of dtoa.c for double-to-string and string-to-double conversions, and we don't (yet) use dtoa.c unconditionally: on platforms where double-rounding can occur and where we don't know the appropriate compiler invocations to fix the precision setting of the FPU, we can't use dtoa.c, so we end up falling back to some legacy code that can't give good guarantees on rounding behaviour.

[jowagner]

Saying that the rounding behaviour is undefined and may be platform-dependent and pointing to https://docs.python.org/3/library/decimal.html#rounding-modes for a hint on the multitude of ways rounding can be done would already help a lot.