Bug when adding float values

[fouzhe]

Bug report

Bug description:

Here is a bug when adding two special float point values:

Python 3.13.2 (main, Mar 18 2025, 03:30:45) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 0.262476+0.168787
0.43126299999999995
>>> 0.262475+0.168788
0.431263
>>> 0.262477+0.168786
0.431263

Thanks.

CPython versions tested on:

3.13

Operating systems tested on:

Linux

[brianschubert]

Hi! This appears to be an example of floating-point limitations and not a CPython bug. I'd advise reviewing https://docs.python.org/3/tutorial/floatingpoint.html and https://stackoverflow.com/questions/588004/is-floating-point-math-broken, and opening a thread on https://discuss.python.org/c/help/7 if you have further questions.

[skirpichev]

It's not a bug, it's how binary floating-point arithmetic works. Please take look on the Python Tutorial: https://docs.python.org/3/tutorial/floatingpoint.html

For example, 0.262476 is not a decimal floating-point number '0.262476' (=Fraction(65619, 250000)). It's actual value is:

>>> from fractions import Fraction
>>> Fraction(0.262476)  # 4728347263174793/2**54
Fraction(4728347263174793, 18014398509481984)
>>> from decimal import Decimal
>>> Decimal(0.262476)
Decimal('0.262475999999999987100096632275381125509738922119140625')

[fouzhe]

Why is adding other float values normal?

>>> 0.262476+0.168788
0.431264
>>> 0.262476+0.168786
0.431262

>>> 0.262476+0.168787
0.43126299999999995

[skirpichev]

Why is adding other float values normal?

By "normal" I guess you meant "be like decimal fractions in school, with infinite precision"?

In first two cases it's just an accident of how binary floating-point values are shown by CPython repl and rounding of floating-point values to fixed precision (floating point numbers in Python usually are in IEEE 756 Double-precision floating-point format). You can add above floating-point numbers exactly, using the decimal module. And you will see, that to represent exact answer you will need much more digits of precision than IEEE doubles have (15-17 significant decimal digits):

>>> decimal.Decimal(0.262476) + decimal.Decimal(0.168786)
Decimal('0.4312619999999999786943760682')
>>> decimal.Decimal(0.262476) + decimal.Decimal(0.168787)
Decimal('0.4312629999999999796944649688')
>>> decimal.Decimal(0.262476) + decimal.Decimal(0.168788)
Decimal('0.4312639999999999806945538694')
>>> decimal.getcontext().prec  # default precision is too small
28
>>> decimal.getcontext().prec = 80  # that one enough
>>> decimal.Decimal(0.262476) + decimal.Decimal(0.168786)
Decimal('0.431261999999999978694376068233395926654338836669921875')
>>> decimal.Decimal(0.262476) + decimal.Decimal(0.168787)
Decimal('0.4312629999999999796944649688157369382679462432861328125')
>>> decimal.Decimal(0.262476) + decimal.Decimal(0.168788)
Decimal('0.431263999999999980694553869398077949881553649902343750')
>>> 0.431261999999999978694376068233395926654338836669921875
0.431262
>>> 0.4312629999999999796944649688157369382679462432861328125
0.43126299999999995
>>> 0.431263999999999980694553869398077949881553649902343750
0.431264

Note that after rounding exact values you get same results as for float addition.

Some time ago (before CPython 3.1 and 2.7) CPython repl behave differently. As you know now from the Tutorial, decimal representation of the binary floating-point value is not unique:

>>> (0.431262).hex()
'0x1.b99cbee807bbbp-2'
>>> (0.431261999999999978694376068233395926654338836669921875).hex()
'0x1.b99cbee807bbbp-2'
>>> (0.43126199999999998).hex()
'0x1.b99cbee807bbbp-2'

Historically, the Python repr() for floats was like orepl = lambda x: f"{x:.17g}". You try this and see how will be displayed floating-point values in your examples (and addition results). Now Python repr() chooses shortest decimal representative.