I was writing some tests today and I ran into a peculiar floating point issue. I had generated a sequence of numbers using numpy.linspace:

>>> np.linspace(0.1, 1, 10)
array([ 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1. ])

Part of the code I was testing ended up testing whether the value 0.3 was in the range 0.3 – 0.8, including the end points. The answer should of course be yes, but there is a twist due to the actual values in the array returned by `linspace:`

>>> a = np.linspace(0.1, 1, 10)
>>> 0.3 in a
False
>>> 0.3 < a[2]
True

What’s happening is that the 0.3 returned by linspace is really 0.30000000000000004, but the 0.3 when I type 0.3 is really 0.29999999999999999. It’s not clear whether this situation would ever actually arise in the normal usage of the code I was testing, but I wanted to make sure this wouldn’t cause problems. My solution was to make a function which would test whether a value was in a given range with a tiny bit of fuzziness at the edges.

NumPy has a useful function for comparing floating point values within tolerances called allclose. But that’s for comparing equality, I need fuzzy (but not very fuzzy) less than / greater than comparisons. To provide just that little bit of fuzziness I turned to the numpy.nextafter function.

`nextafter`

gives the next representable floating point number after the first input value. The second input value controls the direction so you can get the next value either up or down. It turns out that the two numbers that are tripping me up are right next to each other in their floating point representation:

>>> np.nextafter(0.29999999999999999, 1)
0.30000000000000004
>>> np.nextafter(0.30000000000000004, 0)
0.29999999999999999

So to catch this case my range checking function only needs one ULP of fuzziness (which is not much at all) to handle this floating point error. To allow for this I wrote a function called fuzzy_between that takes a value and the lower and upper bounds of the test range and expands the test range by a couple ULP before doing a simple `minval <= val <= maxval`

comparison:

import numpy as np
def fuzzy_between(val, minval, maxval, fuzz=2, inclusive=True):
"""
Test whether a value is within some range with some fuzziness at the edges
to allow for floating point noise.
The fuzziness is implemented by expanding the range at each end `fuzz` steps
using the numpy.nextafter function. For example, with the inputs
minval = 1, maxval = 2, and fuzz = 2; the range would be expanded to
minval = 0.99999999999999978 and maxval = 2.0000000000000009 before doing
comparisons.
Parameters
----------
val : float
Value being tested.
minval : float
Lower bound of range. Must be lower than `maxval`.
maxval : float
Upper bound of range. Must be higher than `minval`.
fuzz : int, optional
Number of times to expand bounds using numpy.nextafter.
inclusive : bool, optional
Set whether endpoints are within the range.
Returns
-------
is_between : bool
True if `val` is between `minval` and `maxval`, False otherwise.
"""
# expand bounds
for _ in xrange(fuzz):
minval = np.nextafter(minval, minval - 1e6)
maxval = np.nextafter(maxval, maxval + 1e6)
if inclusive:
return minval <= val <= maxval
else:
return minval < val < maxval

For a great discussion on comparing floating point numbers see this randomascii post, and for some interesting discussion on the fallibility of range functions see this post on Google+ by Guido van Rossum. Guido actually calls out `numpy.linspace`

as a range function not susceptible to floating point drift (since it’s calculating intervals, not adding numbers), but it’s always possible to get surprises with floating point numbers.