Let's do a small quiz. I've pick an example of basic math. I would like to demonstrate how limited our knowledge about the types we use is. If you are a floating point expert you can feel good that you score 100%. For the 99,99% of developers enjoy the ride.
On the way I point out heuristics I find important to
consider while developing code. I think those make success more likely.
def div(a, b): return a / b assert div(1,1) == 1
This is the code I would like to test. Looks pretty
simple: we divide a by b. We also have a test.
Test branch coverage says we're done.
A looks good or did we miss something?
Yes, there is more than 1 float value.
How big is the problem space?
1<<(64 + 64) # I think, haven't read the IEEE standard to give the correct number
Heuristic: Reading documentation is better than not reading
documentation.
If we want to tackle a problem we have to know how big
it is. If the surface area is small it's easier to know all valid states. For
example testing a function that takes a boolean value is easier than a function
that takes an integer value.
How bad is that?
from datetime import timedeltapflop = 1<<50 200pf="" 2018="" 9.7="" comparison:="" ibm="" mw="" nov="" span="" summit="" supercomputer="" with="">problem = 1<<(64+64) billion_years_with_1_pflop = problem / (timedelta(days=365).total_seconds() * pflop) / (10**9)billion_years_with_1_pflop#Pretty bad9583696.5659455
Heuristic: Use brute-force if possible.
In this instance we cannot test all values with
brute-force. Testing exhaustively should always be the first approach. If this
doesn't work we have to use our knowledge of floating point arithmetic to
produce software that is good enough for the context it's used in.
Domain Knowledge
If you doing anything other than scientific computation, float is
the incorrect type.
For other applications decimal type, or other types (date, complex,
etc.) are appropriate.
Heuristic: Know your domain.
Depending on your domain, you're already doomed.
If you doing anything other than scientific
computations with float it is the incorrect type. It won't work for your currencies, interest rate and book keeping
calculations. Your those you would use a decimal type.
Now let's start the quiz to see how good our float
knowledge is.
This should be true, right?
In the quiz we test the
div function from before with the assert_div function. This test succeeds if the first parameter a is equal to dividing and then multiplying by b.def assert_div(a, b): assert div(a,b) * b == aassert_div(1,1)assert_div(2,3)
This is true for a lot of float values but not all.
Can you come up with 1-2 examples where this is false?
The Quiz
It's not such a hard quiz really. I'll just give you
examples and we try to explain why it's not working.
assert_div(1,0) #Let's start simple--------------------------------------------------------------------------- ZeroDivisionError Traceback (most recent call last) in () ----> 1 assert_div(1,0) #Let's start simple in assert_div(a, b) 1 def assert_div(a, b):----> 2 assert div(a,b) * b == a in div(a, b) 1 def div(a, b):----> 2 return a / b 3 4 assert div(1,1) == 1 ZeroDivisionError: division by zero
This example is simple: division by zero. This is the
same as in normal math and not specific to floating point.
Not a number is fun
Floating point introduces Nan to represent all values
that cannot be represented by any other value.
NaN is pretty special. You cannot treat it as any
other value. Any operation with NaN returns NaN.
assert_div(float(1), float("nan"))--------------------------------------------------------------------------- AssertionError Traceback (most recent call last) in () ----> 1 assert_div(float(1), float("nan")) in assert_div(a, b) 1 def assert_div(a, b):----> 2 assert div(a,b) * b == a AssertionError: float(1) / float("nan")nanNot a number is even funnier
assert_div(float("nan"), 1.0)--------------------------------------------------------------------------- AssertionError Traceback (most recent call last) in () ----> 1 assert_div(float("nan"), 1.0) in assert_div(a, b) 1 def assert_div(a, b):----> 2 assert div(a,b) * b == a AssertionError:
Given what we saw in the last test, this test looks
like it could work. It doesn't because NaN equal to itself.
n = float("nan")(n == n, n is n)(False, True)
This is actually pretty odd.
https://docs.python.org/3.7/reference/expressions.html
Equality comparison should be reflexive. In other
words, identical objects should compare equal:
x is y implies x == y
By flipping the arguments to
div we get the result NaN. NaN is a weird type that even
though is the same memory address we still do not consider it the same object.Inifinity is also fun
Infinity and negative infinity support to represent
values smaller and larger than a regular value float.
assert_div(float("inf"), float("inf"))--------------------------------------------------------------------------- AssertionError Traceback (most recent call last) in () ----> 1 assert_div(float("inf"), float("inf")) in assert_div(a, b) 1 def assert_div(a, b):----> 2 assert div(a,b) * b == a AssertionError: float("inf")/float("inf")nanLosing it
assert_div(3e-5, 7)--------------------------------------------------------------------------- AssertionError Traceback (most recent call last) in () ----> 1 assert_div(3e-5, 7) in assert_div(a, b) 1 def assert_div(a, b):----> 2 assert div(a,b) * b == a AssertionError:
Here we lose precision, which again leads to the input
value not machting the result.
3e-5 / 7 * 7 2.9999999999999997e-05Big and small
import sysassert_div(sys.float_info.max, sys.float_info.min)--------------------------------------------------------------------------- AssertionError Traceback (most recent call last) in () 1 import sys----> 2 assert_div(sys.float_info.max, sys.float_info.min) in assert_div(a, b) 1 def assert_div(a, b):----> 2 assert div(a,b) * b == a AssertionError:
In this instance the division produces infinity and
there's no way to go back from infity to a.
sys.float_info.max / sys.float_info.mininfSmall and big
assert_div(sys.float_info.min, sys.float_info.max)--------------------------------------------------------------------------- AssertionError Traceback (most recent call last) in () ----> 1 assert_div(sys.float_info.min, sys.float_info.max) in assert_div(a, b) 1 def assert_div(a, b):----> 2 assert div(a,b) * b == a AssertionError:
Something similar happens if we flip the input values.
The division leads to 0 and we cannot go back to a.
sys.float_info.min / sys.float_info.max0.0Precisely wrong
assert_div((1<<64 1="" span="">--------------------------------------------------------------------------- AssertionError Traceback (most recent call last) in () ----> 1 assert_div((1<<64 1="" span=""> in assert_div(a, b) 1 def assert_div(a, b):----> 2 assert div(a,b) * b == a AssertionError:
This is a more interesting problem.
Float's internal representation doesn't allow to represent all
1<<64 span="">integer values in a 64 bit float value. In this
example (1<<64 span=""> is the same
as (1<<64 span="">.( (1<<64 float="" int="" span="">(18446744073709551615, 18446744073709551616)_[1]-_[0]1Bonus round of weirdness
If this wasn't bad enough. There is additional
weirdness that is implementation specific. You'll not find this by reading the
documentation.
Heuristic: Test small values exhaustively. Test with random input.
ma = sys.float_info.max * 1.1mi = sys.float_info.min / 10 (ma, mi)(inf, 2.225073858507203e-309)mi < sys.float_info.minTrue
The upper and lower bound are not treated the same.
You can have a min value that is smaller than the value returned by float_info.
Wrap up
How did you do in the quiz?
If you can use an int don't use an float. You will
avoid a whole class of problems.
Heuristic: Simpler software is better than complex software.
How did you do? I'm pretty sure most developers
struggle with this quiz. I'm one of them. We work casually with complexity. We
use concepts without thoroughly understanding them. This is true for nearly
everything in software as we're building layer over layer of software.
In general this is a good thing, it's the only way we
know of how to use the hardware we have. On the other hand, we should be
conservative in estimating our software quality. It's probably way worse than
we think. The only way out is to make the implementation as simple as possible.
Posts
