On Thu, Jan 15, 2015 at 9:42 AM, Ron Adam
The conservative, "safe" way to handle this is to just treat the error
function as symmetrical
What if we are not concerned with the location two points are relative to zero?
not sure what location two points are relative to zero means. Or if the numbers straddle zero? Good catch -- at least if the numbers are symmetric to zero -- i.e. a == -b, then they will never be "close" according to our working definition of relative tolerance: a = -b err == 2*a abs_tol = rel_tol * a #rel_tol is small and positive abs_tol is always smaller than a, so always smaller than the error, so never "close". In fact, this is true for any numbers that straddle zero: err == abs(a,b) abs_tol = rel_tol* max(abs(a), abs(b)) abs_tol <= err # provided 0< rel_tol < 1 So I was thinking the issues were near zero, but they actually are for any time: a <= 0 <= b (or b <= 0 <= a ) that is, any time they straddle or include zero. In this case, you need an absolute tolerance defined. Still figuring out how to use that and provide a smooth transition... Steven, does your code address this somehow? -Chris
and always report the larger of the two relative
errors (excluding the case where the denominator is 0, in which case the relative error is either 100% or it doesn't exist). Worst case, you may reject some values which you should accept, but you will never accept any values that you should reject.
Consider two points that are a constant distance apart, but moving relative to zero. Their closeness doesn't change, but the relative error in respect to each other (and zero) does change.
There is an implicit assumption that the number system used and the origin the numbers are measured from are chosen and relate to each other in some expected way.
When ever you supply all the numbers, like in a test, it's not a problem, you just give good numbers.
Note that you would never compare to an expected value of zero.
You *cannot* compare to an expected value of zero, but you certainly can be in a situation where you would like to: math.sin(math.pi) should return 0.0, but doesn't, it returns 1.2246063538223773e-16 instead. What is the relative error of the sin function at x = math.pi?
relerr(a - b, expected_feet) < tolerance # relative feet from b
relerr(a - 0, expected_feet) < tolerance # relative feet from zero relerr(a - b, ulp) # percentage of ulp's
I don't understand what you think these three examples are showing.
A percentage of an expected distance.
Error of two points compared to a specific distance.
>>> relerr(5 - -5, 10) 0.0
I think unless you use decimal, the ulp example will either be zero or some large multiple of ulp.
Take a look at the statistics test suite.
I definitely will. :-)
I'll be the first to admit
that the error tolerances are plucked from thin air, based on what I think are "close enough", but they show how such a function might work:
* you provide two values, and at least one of an absolute error tolerance and a relative error; * if the error is less than the error(s) you provided, the test passes, otherwise it fails; * NANs and INFs are handled apprpriately.
is_close(218.345, 220, 1, .05) # OHMs
is_close(a, b, ULP, 2) # ULPs is_close(a, b, AU, .001) # astronomical units
I don't see anyway to generalise those with just a function.
Generalise in what way?
I meant a function that would work in many places without giving some sort size and tolerance hints.
Given two floating point numbers and noting else, I don't think you can tell if they represent something that is close without assuming some sort of context. At best, you need to assume the distance from zero and the numbers used are chosen to give a meaningful return value. While that can sometimes work, I don't think you can depend on it.
By using objects we can do a bit more. I seem to recall coming across
measurement objects some place. They keep a bit more context with them.
A full system of
arithmetic is a *much* bigger problem than just calculating error estimates correctly, and should be a third-party library before even considering it for the std lib. Yes, I agree. There are a few of them out there already.
Cheers, Ron
_______________________________________________ Python-ideas mailing list Python-ideas@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@noaa.gov