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

[Chris Barker]

On Thu, Jan 15, 2015 at 1:52 PM, Neil Girdhar <mistersheik at gmail.com> wrote:

> The point is that this function is already in Python
>

I  don't think somethign being in an external package means that we have to
do it the same way in teh stdlib -- even a widely used and well regarded
package like numpy. And I say this as someone that has "import numpy" in
maybe 90% of my python files.

Maybe we should be careful to give it a very distinct name, however, to
avoid confusion.


> and if you want to do something different, you should have a really good
> reason to do it differently.
>

I'm not sure I agree, but we do in this case anyway. The truth is, while
really smart people wrote numpy, many of the algorithms in there did not go
through nearly the level of review currently required for the python
standard library


>   If you were to add a function to math, say math.close, it should work
> like numpy.allclose in my opinion.
>
> For reference, numpy does this:
>
> absolute(*a* - *b*) <= (*atol* + *rtol* * absolute(*b*))
>
> where atol is an absolute tolerance and rtol is a relative tolerance
> (relative to the actual value b).  This subsumes most of the proposals here.
>

adding atol  in there "takes care of" the near zero and straddleing zero
issue ( I suspect that's why it's done that way), but it is fatally wrong
for values much less than 1.0 --  the atol totally overwhelms the rtol.

See my post earlier today.

-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/20150115/45298e54/attachment.html>