This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 5 years ago.
this is my first time asking on stackoverflow, and I have a trouble when programming with python 2.7.
Here I have a calculation:
1350/2.7
The exact answer must be 500, but python give the answer 499.99999999999994
I know about the fact that some numbers cannot be represented exactly in binary, causing error on floating calculation.
So can anybody give me an advice? How to deal exactly with it?
You could use the Decimal module. However in your specific case, you can avoid the problem by multiplying both numerator and divisor by the same number so to make the divisor an integer, like this:
(1350*10)/(2.7*10)
which is of course the same as:
13500/27
That is a representation error, see https://docs.python.org/2/tutorial/floatingpoint.html#representation-error
you can check if it is 500.00 with
eps=1.0e-10
if abs(1350/2.7-500) < eps:
...
Or, just use round(number[, ndigits])
You can use python's built-in round function, or math's ceil function to round up
$ python
>>> round(1350/2.7)
500.0
>>> import math
>>> math.ceil(1350/2.7)
500.0
Here is more of an explanation of why this happens
Related
This question already has answers here:
How do I replace floats with rationals in a sympy expression?
(2 answers)
Closed 8 months ago.
I get very weird fractions in sympy.
I have no clue why it is given me these unusual fractions
To answer your question:
Rational("0.1")
# out: 1 / 10
Rational(0.1)
# out: 3602879701896397/36028797018963968
The second output happens because 0.1 is a number of type float, hence it is inherently inaccurate.
sympy manual: https://docs.sympy.org/latest/explanation/gotchas.html#python-numbers-vs-sympy-numbers
in short:
you type Rational(0.1), then sympy has to test a float.
but Rational("0.1") works. str keep the number.
if you don't like this.
First convert it to sympy's type Integer(1)/10. Also works.
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 2 years ago.
int(10000000000000000000000000000000000/10**10)
It should return the exact value like 10000000000000000000000, but the returned value is 999999999999999983222784. What is the reason behind it??
The floating point division operator (/) produces an inexact result. Converting it to an int after the fact doesn't fix that.
If you use the integer division operator (//) you get an exact integer result:
>>> 10000000000000000000000000000000000//10**10
1000000000000000000000000
This question already has answers here:
Is floating point math broken?
(31 answers)
Python floating-point math is wrong [duplicate]
(2 answers)
Closed 4 years ago.
I have some strange result in my python 3.6.3. Once i tried some code and i reach this problem.
>>> a = 10**32
>>> print(a/1000/1000)
9.999999999999999e+25
As you see it not actually right, but if i go other way, i reach what i expect
>>> print(a/1000000)
1e+26
Same thing with
>>> 10**26
>>> 10**31
Can somebody explain me what's wrong? i tried write it in one line no result
>>> a = 10**32
>>> a/1000/1000
9.999999999999999e+25
As you know, Python 3 division is no longer an integer division (a//1000//1000 would have worked fine), so you're performing 2 floating point divisions here, introducing an (unnecessary) floating point accumulation error.
>>> a/1000000
1e+26
this only performs one division, so lower floating point error effect, even if result is now floating point.
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 5 years ago.
I have the code already figured out and have found a way to get around the problem that for k > 6 the largest denominator is very large. But when my code adds up for example
1/float(2) + 1/float(3) + 1/float(7) + 1/float(42)
python says that it is not equal to 1, but it should be. Why does python recognize other sums as being equal to 1 but not this one?
It is because you are asking for floating point arithmetic, and when the roundoff errors add up, you'll get wrong answers.
Use the https://docs.python.org/3/library/fractions.html module to get real fractions and roundoff issues should disappear for you.
You need to be extremely careful when hard-comparing any decimal values. Computer don't provide unlimited precision, thus it could be that your argument adds up to something like 0.99999998 instead of 1. Then the comparison might fail.
Thus you should always compare corresponding to an allowed difference of delta, like 1 - 0.99999998 < delta where delta = 0.0001 or something like that.
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 7 years ago.
When I divide 1/5e-5 it gives the correct answer but 1/5e-6 gives an answer close to the correct one.
>>> 1/5e-5
20000.0
>>> 1/5e-6
199999.99999999997 (should be 200000)
>>>
How can I get it to show the exact value. I tried importing decimel, numpy and scipy but none of them change the result.
You can get decimal to do this properly -- You just have to avoid using floating point numbers along the way:
>>> import decimal
>>> decimal.Decimal('1') / (decimal.Decimal('5') / decimal.Decimal('1000000'))
Decimal('2E+5')