[Python-ideas] Way to check for floating point "closeness"?

[Chris Barker]

On Mon, Jan 12, 2015 at 6:32 PM, Nathaniel Smith <njs at pobox.com> wrote:

> Ok, but you're missing a huge issue, which is that according to the rule
> you suggest, 0.0 is not close to any non-zero value.
>
Well, I did say I just threw something together (it's a gist, not a pull
request!). and asked for test cases that would push it. At best it could be
a starting point for experimentation and discussion - though Steven's code
is probably a much better place to start.

Near zero clearly is one case to be considered. Perhaps that's why numpy
used a relative AND absolute tolerance together -- I'll need to take a
closer look at that.

> Handing such a function to users and claiming it's the one "is close"
> predicate they need is going to produce a lot of sad and confused users.
>
I don't think we'll be able to come up with anything that is the "one"
predicate anyone will even need. But I do think that it would be good to
provide something that is useful for common cases, and more thought out
than most folks will bother to write on their own.

> I don't want to step on your positive let's-fix-it attitude, I think
> that's great, but... I do think you are really underestimating the
> complexity of the problem.
>
I really didn't think I was done ;-)

> The right way to handle comparison with zero, or comparison between
> epsilon and negative epsilon, etc, really depends on the context. For
> common unit test cases it may even make sense to prefer a non-symmetric
> predicate -- e.g. if you're expecting 0 then 1e-100 is usually fine, but if
> you're expecting 1e-100 then getting 0 might be a huge problem.
>
Sure, but no matter how you slice it, users will need to think. In fact, if
you are expecting zero, you can write that test yourself pretty easily.
Though that may be an example of why you want to provide an absolute
tolerance method as well. It would be more appropriate if you are expecting
zero.

>From Bruce Dawson's article: "Zero is a huge nuisance. Avoid it if
possible."

I don't love it, but numpy's allclose() has worked fine for me, and many
other people, certainly well enough that I haven't bothered to write my own.

Also, thinking a bit about complex -- complex abs() is easy to think about,
but maybe not as rigorous as both components being individually. For
example:

1e100+0.1j  and 1e100+10j -- should those be "close"? They are in the
absolute value sense, but the imaginary part is not in the least.

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150112/9a6d0112/attachment-0001.html>