[Python-ideas] Floating point "closeness" Proposal Outline

[Chris Barker]

On Sun, Jan 18, 2015 at 11:51 PM, Stephen J. Turnbull <stephen at xemacs.org>
wrote:

>  > But I still think we can provide something that is useful for most
>  > use-cases, and would like to propose what that is, and what the
>  > decision points are:
>
> It would be useful, that is, if the user knows what she is doing.  The
> problem exposed by the plethora of use cases is that in many cases
> users don't know what they're doing, and it's *not* just a matter of
> forgetting to take the absolute value.
>

I was afraid of this -- my take is that EVERY algorithm has corner cases,
an special cases, and places where it is appropriate and where it is not.
And this list (and all lists...) is full of folks that like to hash this
stuff out. So the fact that there has been a long and drawn out discussion
does not mean that there is not a generally useful function to be had.

And I think, in fact, that such a function does is exist that will work
most of teh time, even for users that have not thought it out carefully.

We, in fact have a lot of evidence that this is needed:

* numpy has close() and all_close -- they are widely used, mostly
successfully

* Steven took that time to write one (and tests for it) for the statistics
module tests.

* The unittest module has something -- and a poor one (IMHO) at that -- but
is still useful.

* Boost has one (not Python, but still....)

 > It will not do a simple absolute comparison -- that is the job of a

>  > different function, or, better yet, folks just write it themselves:
>  >
>  > abs(x - y) <= delta
>  >
>  > really isn't much harder to write than a function call:
>  >
>  > absolute_diff(x,y,delta)
>
> for relative error
>
>     abs(x - y)/min(abs(x), abs(y))
>
> really isn't that hard to write -- if you know that's what you want.
>

that is, I think, just enough harder to think about and write than the
absolute comparison method, that it's worth it. And if others think an
absolute_close is worth adding, too, I have no problem with that.

But Neil and Ron *don't* want that: they know which value is correct
> and that it's never zero.
>

I think my proposal satisfies both Neil and Ron's use case -- or a version
of it can, and also Steven's.


>  > It will be designed for floating point numbers, and handle inf,
>  > -inf, and NaN "properly".
>
> Which means what?  Something different from what a conforming IEEE 754
> implementation would do?
>

no, sorry for being lazy in writing, -- I meant it would conform to IEEE
754. i.e. NaN would not be close to anything, including another NaN, and
inf and -inf would only be close to themselves. (though I don't know that
ieee ever mentions non-exact comparison...)


The farther we get into this, the more handwaving is being done by
> advocates.  Despite what I wrote above, it's not trivial to write a
> correct symmetric relative error: some such function would be useful.
>

if it's not trivial, then all the reason to to put it in the standard lib.


> But I think that it should have a name that (at least to some extent)
> indicates what it actually does (unlike is_close(), which users are
> likely to assume means what they think it means because they haven't
> thought about the alternatives).
>

Indeed -- I think that the name of the function, and it's parameters need
to be carefully chosen to  best convey what they mean. (and the docstring).

What I"d like to do is determine whether there is any hope of coming to a
consensus about what a reasonable implementation would look like. If not,
then so be it. If so, then I guess I"ll need to write a PEP and then hash
out the naming and details.

So I think the next step is to hear form the active participants in this
thread as to whether they think there's hope, and/or from Guido and other
core developers as to whether they're ready to reject it at this point -- I
don't want to waste any more of my or anyone else's time.

-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/20150119/47394981/attachment.html>