# Floating-point numbers **URL:** \ **Category:** Python Help\ **Created:** [December 17, 2022, 8:19pm UTC](https://discuss.python.org/t/floating-point-numbers/22009 "2022-12-17T20:19:12Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Ali\_Heydarov](https://avatars.discourse-cdn.com/v4/letter/a/77aa72/32.png) [@Ali\_Heydarov](https://discuss.python.org/u/Ali_Heydarov)\ **Post date:** [December 17, 2022, 8:19pm UTC](https://discuss.python.org/t/floating-point-numbers/22009/1 "2022-12-17T20:19:12Z")
The result of 12+12.23 is 35.120000000000005 The result of 23+12.23 is 35.230000000000004 And the result of 1.2-1 is 0.19999999999999996 But in C++ the results are true. Why?What is the difference between C++ and Python at floating-point numbers Note: The result of 0.1+0.1 is 0.2 It is true.But the result of 1.2-1 is false ---
**Author:** ![dstromberg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dstromberg/32/9047_2.png) [@dstromberg](https://discuss.python.org/u/dstromberg)\ **Post date:** [December 17, 2022, 8:42pm UTC](https://discuss.python.org/t/floating-point-numbers/22009/2 "2022-12-17T20:42:31Z")
Some language runtimes round floats and doubles. Decimal numbers sometimes do not have a precise representation in binary math - and floats and doubles are binary math. If you need precisely-represented decimal values (EG, for an accounting application), use decimal math like the decimal.Decimal class: > **[decimal — Decimal fixed point and floating point arithmetic](https://docs.python.org/3/library/decimal.html)** > > Source code: Lib/decimal.py The decimal module provides support for fast correctly rounded decimal floating point arithmetic. It offers several advantages over the float datatype: Decimal “is based... ---
**Author:** ![TeamSpen210](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/teamspen210/32/1004_2.png) [@TeamSpen210](https://discuss.python.org/u/TeamSpen210)\ **Post date:** [December 17, 2022, 10:36pm UTC](https://discuss.python.org/t/floating-point-numbers/22009/3 "2022-12-17T22:36:59Z")
Note in both languages the actual numerical result should be exactly the same - Python floats are going to be identical to C `double`s. The difference is how the language is choosing to convert them to strings to display them. Notice how if you rounded Python’s result to say 10 decimal places, it’d be exactly correct. If you modify your C program to specify a lot of decimals (20, say), it should produce the same inprecision in the end. The core problem here is that the numbers are stored in binary, not decimal, which means different numbers can be represented exactly. In decimal math, 1/3 can’t be written exactly - 0.3333 is close but not perfect, while 1/4 = 0.25 exactly. In binary math, it’s a different set of fractions which can be handled exactly - in particular ⅒ cannot be represented perfectly, so you end up with this very slight difference. In practice it’s really not a big deal, because the important first decimal points are all exact. ---
**Author:** ![Rosuav](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rosuav/32/3429_2.png) [@Rosuav](https://discuss.python.org/u/Rosuav)\ **Post date:** [December 17, 2022, 10:57pm UTC](https://discuss.python.org/t/floating-point-numbers/22009/4 "2022-12-17T22:57:18Z")
> [@TeamSpen210](#): > > Note in both languages the actual numerical result should be exactly the same - Python floats are going to be identical to C `double`s. I wonder if perhaps the OP was using a `float` in C, but untagged literals, which are of type `double`? `float x = 0.1 + 0.2;` This will do double-precision arithmetic, but then downcast to float. Even if 0.1 is put into a float, and then 0.2 is added afterwards, the float would most likely be upcast to double, then the arithmetic done, and then the result is downcast back to float. ---
**Author:** ![steven.daprano](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steven.daprano/32/1083_2.png) [@steven.daprano](https://discuss.python.org/u/steven.daprano)\ **Post date:** [December 18, 2022, 12:33am UTC](https://discuss.python.org/t/floating-point-numbers/22009/5 "2022-12-18T00:33:49Z")
> [@](#): > > The result of 12+12.23 is 35.120000000000005 No it isn’t. ```auto >>> 12 + 12.23 24.23 ``` Perhaps you mean: ```auto >>> 12 + 23.12 35.120000000000005 ``` Why is this not the same as you expect from school? Because floating point maths on the computer does not, **and can not,** use mathematical exact real numbers. Floats are limited to 64 bits of binary digits, which is approximately 16-17 decimal digits. See [the FAQs](https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate) and [the tutorial](https://docs.python.org/3/tutorial/floatingpoint.html#tut-fp-issues). **All** programming languages, including C++, suffer from [this same issue](https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html). But some programming languages try to hide the fact by lying to you. For example, the R interpreter only shows a few decimal places, so that numbers which are different look the same: ```auto > c(0.199999999, 0.2, 0.20000001) [1] 0.2 0.2 0.2 ``` I discovered this when I had a program calculate five numbers, which looked identical in the R interpreter, but weren’t: ```auto > fn [1] 0.2 0.2 0.2 0.2 0.2 > fn == 0.2 [1] TRUE TRUE FALSE FALSE FALSE ``` **Python will never lie to you like this** but other languages might.