[Python-ideas] PEP 485: A Function for testing approximate equality (original) (raw)

Chris Barker chris.barker at noaa.gov
Fri Feb 6 02:12:32 CET 2015

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

> 0.0 < reltol < 1.0)

I can just about see the point in restricting reltol 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. reltol=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 reltol=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>

More information about the Python-ideas mailing list