This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Type: Multiplying 4.6*100 will result in 459.99999999999994 resolved Python 3.7
process
Status: Resolution: closed not a bug ahmad dana, eric.smith, remi.lapeyre, skrah, steven.daprano normal

Created on 2020-04-06 15:17 by ahmad dana, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Files
Screen Shot 2020-04-06 at 6.56.48 PM.png ahmad dana, 2020-04-06 16:00
Messages (7)
`While we using python3.7 to do some  number multiplication, we faced an issue with multiplying 4.6*100 which lead to strange output, the result was 459.99999999999994, while it should be something like 460.00`
msg365861 - (view) Author: Rémi Lapeyre (remi.lapeyre) * Date: 2020-04-06 15:22
```Hi ahmad, calculation with floating points in Python uses the IEE 754 (https://fr.wikipedia.org/wiki/IEEE_754) standard and will result in such quirks.

If you want to not loose precision you can use the decimal module:

>>> from decimal import Decimal
>>> Decimal('4.6')*100
Decimal('460.0')

Since this is not a bug if you have other questions when working with floats, try to ask on python-list or a forum.```
msg365864 - (view) Author: Eric V. Smith (eric.smith) * Date: 2020-04-06 15:35
`See https://docs.python.org/3.8/tutorial/floatingpoint.html`
msg365865 - (view) Author: Steven D'Aprano (steven.daprano) * Date: 2020-04-06 15:51
```Rémi, it is not true that the Decimal module won't lose precision. It will. Decimal is not exact either, it is still a floating point format similar to float.

py> Decimal(1)/3*3
Decimal('0.9999999999999999999999999999')

The two major advantages of Decimal are: it matches the number you type more closely, and you can choose how much precision to use. (At the cost of memory and speed.) But there are also disadvantages: rounding errors with Decimal tend to be larger on average than for binary floats.

If you want exact calculations that will never lose precision, you have to use Fractions, but that is slower and less convenient.```
`Regarding the comment about the decimal point precision , and solving the issue with the decimal library, the following attachment shows you that the decimal Library did exactly the same behaviour`
msg365869 - (view) Author: Rémi Lapeyre (remi.lapeyre) * Date: 2020-04-06 16:08
```@Steven Yes that's true, I only meant that in the context of the issue where only the multiplication is used. FWIW Fraction also would have issues with e.g. trigonometric functions right?

@ahmad, that's because you did Decimal(4.6) which first parse 4.6 as a float then call Decimal() with the result. You need to use Decimal('4.6') to avoid the parser reading 4.6 as a float. Have a look at the tutorial Eric Smith linked, the documentation of decimal and the response from Steven D'Aprano for more information.```
msg365903 - (view) Author: Stefan Krah (skrah) * Date: 2020-04-07 10:44
```You can also set the decimal.FloatOperation trap to avoid accidental
errors:

>>> from decimal import *
>>> c = getcontext()
>>> Decimal(4.6) * 100
Decimal('459.9999999999999644728632120')

>>> c.traps[FloatOperation] = True
>>> Decimal(4.6) * 100
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
decimal.FloatOperation: [<class 'decimal.FloatOperation'>]

>>> Decimal("4.6") * 100
Decimal('460.0')
>>>```
History
Date User Action Args
2020-04-07 10:44:05skrahsetnosy: + skrah
messages: + msg365903
2020-04-06 16:08:25remi.lapeyresetmessages: + msg365869
2020-04-06 16:00:53ahmad danasetfiles: + Screen Shot 2020-04-06 at 6.56.48 PM.png

messages: + msg365867
2020-04-06 15:51:16steven.dapranosetnosy: + steven.daprano
messages: + msg365865
2020-04-06 15:35:23eric.smithsetstatus: open -> closed

nosy: + eric.smith
messages: + msg365864

resolution: not a bug
stage: resolved
2020-04-06 15:22:55remi.lapeyresetnosy: + remi.lapeyre
messages: + msg365861