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?
Related
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:
Is floating point math broken?
(31 answers)
Why does Python return 0 for simple division calculation?
(6 answers)
Closed 5 years ago.
This is driving me mad... Of all the years I've been using python, this is just now starting to present itself. How I managed to dodge it up until now is beyond me.
If you open a python idle and try this equation...
4/32*100
You'll get '0' as an answer. Now try the same equation using floats....
4.0/32.0*100.0 (or just the first number 4.0/32*100)
You now get an actual percentage.
WTF!?
Is this some kind of python error!? Even a calculation can do the equation and spit out a percentage.
So why can't python see a 4 as 4.0. Better question... What is the interpreter actually seeing if it's not seeing a 4(4.0)?
Someone please clear this up so I can feel professional with python again (lol).
In Python 2, int type division ignores the decimal values of the division.
For example, 1/2 = 0.5, but in int type division, 1/2 will evaluate to 0 because it ignores the decimal values.
Thus, in your case with 4/32*100, 4/32will first evaluate to 0 and then 0*100 will finally equal 0.
On the other hand, in float type division, it will evaluate answers as we would expect (not in a strictly precise definition though, look here for further information).
For Python 2.x, dividing two integers or longs uses integer division, also known as "floor division"(applying the floor function after division)
For Python 3.x, "/" does "true division" for all types.
To make python perform true division, cast any of the denominator for numerator to become float.
float(4)/32*100
or
4/float(32)*100
or doing below to make python 2 division behave like python 3 division
from __future__ import division
4/32*100
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.
This question already has answers here:
Why does integer division yield a float instead of another integer?
(4 answers)
Closed 6 years ago.
I was writing a Python 3.5.2 program which includes division.
When I ran the following:
>>> 10/2
5.0
Though the answer is correct, it has a decimal point. What should be done to get quotient without decimal point, for example, 10/2 should yield 5, not 5.0?
Check out this answer. In Python 3 Integer division is performed using the // operator, and the regular division operator can yield float. Check 1/2 for example - if you get 0.5, that's not Integer division, 0 is. IDLE is irrelevant here.
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.