# What is the best way to compare floats for almost-equality in Python?

Posted on

Solving problem is about exposing yourself to as many situations as possible like What is the best way to compare floats for almost-equality in Python? and practice these strategies over and over. With time, it becomes second nature and a natural way you approach any problems in general. Big or small, always start with a plan, use other strategies mentioned here till you are confident and ready to code the solution.
In this post, my aim is to share an overview the topic about What is the best way to compare floats for almost-equality in Python?, which can be followed any time. Take easy to follow this discuss.

What is the best way to compare floats for almost-equality in Python?

It’s well known that comparing floats for equality is a little fiddly due to rounding and precision issues.

What is the recommended way to deal with this in Python?

Surely there is a standard library function for this somewhere?

Python 3.5 adds the `math.isclose` and `cmath.isclose` functions as described in PEP 485.

If you’re using an earlier version of Python, the equivalent function is given in the documentation.

``````def isclose(a, b, rel_tol=1e-09, abs_tol=0.0):
return abs(a-b) <= max(rel_tol * max(abs(a), abs(b)), abs_tol)
``````

`rel_tol` is a relative tolerance, it is multiplied by the greater of the magnitudes of the two arguments; as the values get larger, so does the allowed difference between them while still considering them equal.

`abs_tol` is an absolute tolerance that is applied as-is in all cases. If the difference is less than either of those tolerances, the values are considered equal.

Is something as simple as the following not good enough?

``````return abs(f1 - f2) <= allowed_error
``````

I would agree that Gareth’s answer is probably most appropriate as a lightweight function/solution.

But I thought it would be helpful to note that if you are using NumPy or are considering it, there is a packaged function for this.

``````numpy.isclose(a, b, rtol=1e-05, atol=1e-08, equal_nan=False)
``````

A little disclaimer though: installing NumPy can be a non-trivial experience depending on your platform.

Use Python’s `decimal` module, which provides the `Decimal` class.

It is worth noting that if you’re
doing math-heavy work and you don’t
absolutely need the precision from
decimal, this can really bog things
down. Floats are way, way faster to
deal with, but imprecise. Decimals are
extremely precise but slow.

The common wisdom that floating-point numbers cannot be compared for equality is inaccurate. Floating-point numbers are no different from integers: If you evaluate “a == b”, you will get true if they are identical numbers and false otherwise (with the understanding that two NaNs are of course not identical numbers).

The actual problem is this: If I have done some calculations and am not sure the two numbers I have to compare are exactly correct, then what? This problem is the same for floating-point as it is for integers. If you evaluate the integer expression “7/3*3”, it will not compare equal to “7*3/3”.

So suppose we asked “How do I compare integers for equality?” in such a situation. There is no single answer; what you should do depends on the specific situation, notably what sort of errors you have and what you want to achieve.

Here are some possible choices.

If you want to get a “true” result if the mathematically exact numbers would be equal, then you might try to use the properties of the calculations you perform to prove that you get the same errors in the two numbers. If that is feasible, and you compare two numbers that result from expressions that would give equal numbers if computed exactly, then you will get “true” from the comparison. Another approach is that you might analyze the properties of the calculations and prove that the error never exceeds a certain amount, perhaps an absolute amount or an amount relative to one of the inputs or one of the outputs. In that case, you can ask whether the two calculated numbers differ by at most that amount, and return “true” if they are within the interval. If you cannot prove an error bound, you might guess and hope for the best. One way of guessing is to evaluate many random samples and see what sort of distribution you get in the results.

Of course, since we only set the requirement that you get “true” if the mathematically exact results are equal, we left open the possibility that you get “true” even if they are unequal. (In fact, we can satisfy the requirement by always returning “true”. This makes the calculation simple but is generally undesirable, so I will discuss improving the situation below.)

If you want to get a “false” result if the mathematically exact numbers would be unequal, you need to prove that your evaluation of the numbers yields different numbers if the mathematically exact numbers would be unequal. This may be impossible for practical purposes in many common situations. So let us consider an alternative.

A useful requirement might be that we get a “false” result if the mathematically exact numbers differ by more than a certain amount. For example, perhaps we are going to calculate where a ball thrown in a computer game traveled, and we want to know whether it struck a bat. In this case, we certainly want to get “true” if the ball strikes the bat, and we want to get “false” if the ball is far from the bat, and we can accept an incorrect “true” answer if the ball in a mathematically exact simulation missed the bat but is within a millimeter of hitting the bat. In that case, we need to prove (or guess/estimate) that our calculation of the ball’s position and the bat’s position have a combined error of at most one millimeter (for all positions of interest). This would allow us to always return “false” if the ball and bat are more than a millimeter apart, to return “true” if they touch, and to return “true” if they are close enough to be acceptable.

So, how you decide what to return when comparing floating-point numbers depends very much on your specific situation.

As to how you go about proving error bounds for calculations, that can be a complicated subject. Any floating-point implementation using the IEEE 754 standard in round-to-nearest mode returns the floating-point number nearest to the exact result for any basic operation (notably multiplication, division, addition, subtraction, square root). (In case of tie, round so the low bit is even.) (Be particularly careful about square root and division; your language implementation might use methods that do not conform to IEEE 754 for those.) Because of this requirement, we know the error in a single result is at most 1/2 of the value of the least significant bit. (If it were more, the rounding would have gone to a different number that is within 1/2 the value.)

Going on from there gets substantially more complicated; the next step is performing an operation where one of the inputs already has some error. For simple expressions, these errors can be followed through the calculations to reach a bound on the final error. In practice, this is only done in a few situations, such as working on a high-quality mathematics library. And, of course, you need precise control over exactly which operations are performed. High-level languages often give the compiler a lot of slack, so you might not know in which order operations are performed.

There is much more that could be (and is) written about this topic, but I have to stop there. In summary, the answer is: There is no library routine for this comparison because there is no single solution that fits most needs that is worth putting into a library routine. (If comparing with a relative or absolute error interval suffices for you, you can do it simply without a library routine.)

I’m not aware of anything in the Python standard library (or elsewhere) that implements Dawson’s `AlmostEqual2sComplement` function. If that’s the sort of behaviour you want, you’ll have to implement it yourself. (In which case, rather than using Dawson’s clever bitwise hacks you’d probably do better to use more conventional tests of the form `if abs(a-b) <= eps1*(abs(a)+abs(b)) + eps2` or similar. To get Dawson-like behaviour you might say something like `if abs(a-b) <= eps*max(EPS,abs(a),abs(b))` for some small fixed `EPS`; this isn’t exactly the same as Dawson, but it’s similar in spirit.

math.isclose() has been added to Python 3.5 for that (source code). Here is a port of it to Python 2. It’s difference from one-liner of Mark Ransom is that it can handle “inf” and “-inf” properly.

``````def isclose(a, b, rel_tol=1e-09, abs_tol=0.0):
'''
Python 2 implementation of Python 3.5 math.isclose()
https://hg.python.org/cpython/file/tip/Modules/mathmodule.c#l1993
'''
# sanity check on the inputs
if rel_tol < 0 or abs_tol < 0:
raise ValueError("tolerances must be non-negative")
# short circuit exact equality -- needed to catch two infinities of
# the same sign. And perhaps speeds things up a bit sometimes.
if a == b:
return True
# This catches the case of two infinities of opposite sign, or
# one infinity and one finite number. Two infinities of opposite
# sign would otherwise have an infinite relative tolerance.
# Two infinities of the same sign are caught by the equality check
# above.
if math.isinf(a) or math.isinf(b):
return False
# now do the regular computation
# this is essentially the "weak" test from the Boost library
diff = math.fabs(b - a)
result = (((diff <= math.fabs(rel_tol * b)) or
(diff <= math.fabs(rel_tol * a))) or
(diff <= abs_tol))
return result
``````

``````from nose.tools import assert_almost_equals