[Python-ideas] PEP 485: A Function for testing approximate equality

[Chris Barker]

On Thu, Feb 5, 2015 at 4:44 PM, Steven D'Aprano <steve at pearwood.info> wrote:

> > 0.0 < rel_tol < 1.0)
>
> I can just about see the point in restricting rel_tol to the closed
> interval 0...1, but not the open interval. Mathematically, setting the
> tolerance to 0
> should just degrade gracefully to exact equality,


sure -- no harm done there.

and a tolerance of
> 1 is nothing special at all.
>

well, I ended up putting that in because it turns out with the "weak" test,
then anything compares as "close" to zero:

tol>=1.0
a = anything
b = 0.0

min( abs(a), abs(b) ) = 0.0

abs(a-b) = a

tol * a >= a

abs(a-b) <= tol * a

Granted, that's actually the best argument yet for using the strong test --
which I am suggesting, though I haven't thought out what that will do in
the case of large tolerances.


> Values larger than 1 aren't often useful, but there really is no reason
> to exclude tolerances larger than 1. "Give or take 300%" (ie.
> rel_tol=3.0) is a pretty big tolerance, but it is well-defined: a
> difference of 299% is "close enough", 301% is "too far".
>

yes it is, but then the whole weak vs string vs asymmetric test becomes
important. From my math the "delta" between the weak and strong tests goes
with  tolerance**2 * max(a,b).  So if the tolerance is >=1, then it makes a
big difference which test you choose. IN fact:

Is a within 300% of b makes sense, but "are a and b within 300% of
each-other" is poorly defined.

The goal of this is to provide an easy way for users to test if two values
are close - not to provide a general purpose relative difference function.
and keeping the scope small keeps things cleaner.

You might argue that if you want exact equality, you shouldn't use a
> tolerance at all but just use == instead. But consider a case where
> you might be trying calculations repeatedly and decreasing the tolerance
> until it fails:
>

sure -- then might as well include 0.0


> Negative error tolerances, on the other hand, do seem to be meaningless
> and should be prevented.


you could just take the abs(rel_tol), but really?  what's the point?


> I don't see why a tolerance over 1 should behave any more oddly with
> zero than a tolerance under 1.
>

see above.


> And as for "close", some people would argue that rel_tol=0.5 is "hardly
> close". Sometimes you might accept anything within an order of magnitude
> the expected value: anything up to 10*x is "close enough". Or 20 times.
> Who knows?
>

with some more thought, we may be able to let rel_tol be anything > 0.0
with the string test. I"ll have to investigate more if folks think this is
important.



> (E.g. "guess the number of grains of sand on this beach".) Any upper
> limit you put in is completely arbitrary,


somehow one doesn't feel arbitrary to me -- numbers aren't close if the
difference between them is larger than the largest of the numbers -- not
arbitrary, maybe unneccesary , but not arbirtrary




> and this function shouldn't be
> in the business of telling people how much error they are allowed to
> tolerate. It's easy for people to put in their own restrictions, but
> hard for them to work around yours.
>
>
> > if a and/or b are inf or nan, it follows IEE754 (which mostly "just
> works"
> > with no special casing in the code.
>
> That is very nice.
>
>
>
> --
> Steve
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 

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/20150205/b64301d8/attachment-0001.html>