This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 5 years ago.
Can someone explain this?
Input:
58/100*100
Result:
57.99999999999999
Yet...
Input:
26/100*100
Result:
26.0
Also, how can I consistently get results like in the second case?
This is all due to floating point arithmetic
and a subtle change in the way python evaluates expressions containing numeric literals.
Since python 3, your expressions above will be calculated in floating point; before then integer arithmetic would have be used.
In IEEE754 floating point, 0.58 is further away from the true value than 0.26. That's enough to throw off the heuristics that your output formatter is using.
Performing the multiplication before the division can help in some circumstances, and will do here as the product can be represented exactly.
Related
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 3 years ago.
I was using a simple for loop to add numbers but I found a strange result when adding float.
Can you explain why I have the following output ?
1.1
1.2000000000000002
1.3000000000000003
1.4000000000000004
1.5000000000000004
1.6000000000000005
1.7000000000000006
1.8000000000000007
1.9000000000000008
2.000000000000001
2.100000000000001
2.200000000000001
2.300000000000001
2.4000000000000012
2.5000000000000013
2.6000000000000014
2.7000000000000015
2.8000000000000016
2.9000000000000017
3.0000000000000018
3.100000000000002
3.200000000000002
3.300000000000002
3.400000000000002
3.500000000000002
3.6000000000000023
3.7000000000000024
3.8000000000000025
3.9000000000000026
This is based on Anaconda Spyder
a = 1
for i in range(1,30):
a = a+0.1
print(a)
It's a known limitation of floating point arithmetic, computers cannot store infinitely precise floating point numbers. See python docs.
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 4 years ago.
What is the explanation for this unexpected results in Python??!;
from math import *
>>>log(1000,10) ## expecting 3.0
2.9999999999999996
>>>1000**(1/3) ## expecting 10.0
9.999999999999998
Basically value of these functions are calculated using some series. As python by default uses floating values, so it calculates values very precisely.
You can see this...
Efficient implementation of natural logarithm (ln) and exponentiation
That`s why it gives these types of result.
You can use Fraction class from fractions to convert these values to integer.
https://docs.python.org/3.1/library/fractions.html
This question already has answers here:
Why does floating-point arithmetic not give exact results when adding decimal fractions?
(31 answers)
Closed 5 years ago.
I've run a simple python command and it derives the following result. Can anyone tell me why?
a=[[0.12,0.35],[0.66,0.79]]
b=[[10*i,10*j] for i,j in a]
and I got the following result:
b=[[1.2, 3.5], [6.6000000000000005, 7.9]]
This is simple representation "error". Binary numbers do not represent decimal values with prefect accuracy, any more than a terminating decimal can accurately represent, say, 1/7.
0.66 is a decimal whose binary representation is just a hair high (actually, they're all going to be a little "off", but this is the only one that shows at a factor of only 10). You can "fix" this by switching to a decimal data type.
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 6 years ago.
I was trying to calculate int((226553150*1023473145)/5.) using python and I got 46374212988031352 although it should be 46374212988031350.
Remove the period for integer division:
int((226553150*1023473145)/5)
Comes out as 46374212988031350 for me.
Edit after #tobias_k's comment:
This only works in Python2, where / is either floating point division (if either of the arguments is float) or integer division (if both arguments are integers).
In Python3 (or with from __future__ import division in Python2) / is always floating point division and the rounding problem comes up again, because the numbers you multiply are too large to be exactly expressed in floating point.
The solution is either to use //, which is always integer division in all Python versions or (if you really need the denominator to be float) to switch to mpmath, where you can increase the floating point precision until you don't have the rounding errors anymore.
This question already has answers here:
How can I force division to be floating point? Division keeps rounding down to 0?
(11 answers)
Closed 8 years ago.
I'm trying to have this function work, but i'm not getting the results expected. I fully believe it because I'm new to Python.... Here is my code:
waterLevel = (-(25/144) * sensorValue) + (14725/72) ;
And here is the equation:
y=-25x/144 + 14725/72
So when x=1178 then y=0 (y=waterLevel) and when x=602 then y=100.
I am getting this, when x=1178 then y=204.
What am I doing wrong here?
Update This is a different question because I didn't know it was floating point python nonsense .... just that my math wasn't working. Just because the answer is the same doesn't mean it is a duplicate. ;)
You are falling foul of integer division as opposed to float division.
In Python 2.x 25/144 will produce integer division which means it will result in 0.
If you're going to be dealing with floating point numbers then you should use floating point numbers, i.e. 25.0/144.0.
In Python 3.x the division of integers will default to returning the floating point value and instead you must explicitly choose integer division using //. If you would like this behaviour in Python 2 then use from __future__ import division at the top of your script (thanks to jwodder for the comment).
Use floats instead of ints
waterLevel = (-(25.0/144.0) * sensorValue) + (14725.0/72.0)
By the way, there is an adicional parethesis in the beginning of the equation, is it a typo?