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

[Stephen J. Turnbull]

Chris Barker writes:

 > 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.

As you say about absolute error:

 > 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.
But Neil and Ron *don't* want that: they know which value is correct
and that it's never zero.

 > 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?

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.
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).

Steve