<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 15, 2015 at 9:42 AM, Ron Adam <span dir="ltr"><<a href="mailto:ron3200@gmail.com" target="_blank">ron3200@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The conservative, "safe" way to handle this is to just treat the error<br>
function as symmetrical<br>
</blockquote></span>
What if we are not concerned with the location two points are relative to zero? </blockquote><div><br></div><div>not sure what location two points are relative to zero means.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Or if the numbers straddle zero?</blockquote><div><br></div><div>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:</div><div><br></div><div>a = -b</div><div><br></div><div>err == 2*a</div><div>abs_tol = rel_tol * a</div><div><br></div><div>#rel_tol is small and positive</div><div><br></div><div>abs_tol is always smaller than a, so always smaller than the error, so never "close".</div><div><br></div><div>In fact, this is true for any numbers that straddle zero:</div><div><br></div><div>err == abs(a,b)</div><div><br></div><div>abs_tol = rel_tol* max(abs(a), abs(b)) <br></div><div><br></div><div>abs_tol <= err # provided 0< rel_tol < 1</div><div><br></div><div>So I was thinking the issues were near zero, but they actually are for any time:</div><div><br></div><div>a <= 0 <= b (or b <= 0 <= a )</div><div><br></div><div>that is, any time they straddle or include zero.</div><div><br></div><div>In this case, you need an absolute tolerance defined.</div><div><br></div><div>Still figuring out how to use that and provide a smooth transition...</div><div><br></div><div>Steven, does your code address this somehow?</div><div><br></div><div>-Chris</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
and always report the larger of the two relative<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
errors (excluding the case where the denominator is 0, in which case<br>
the relative error is either 100% or it doesn't exist). Worst case, you<br>
may reject some values which you should accept, but you will never<br>
accept any values that you should reject.<br>
</blockquote>
<br></span>
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.<br>
<br>
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.<br>
<br>
When ever you supply all the numbers, like in a test, it's not a problem, you just give good numbers.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Note that you would never compare to an expected value of zero.<br>
</blockquote>
<br>
You *cannot* compare to an expected value of zero, but you certainly can<br>
be in a situation where you would like to: math.sin(math.pi) should<br>
return 0.0, but doesn't, it returns 1.2246063538223773e-16 instead. What<br>
is the relative error of the sin function at x = math.pi?<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
relerr(a - b, expected_feet) < tolerance # relative feet from b<br>
relerr(a - 0, expected_feet) < tolerance # relative feet from zero<br>
relerr(a - b, ulp) # percentage of ulp's<br>
</blockquote>
<br>
I don't understand what you think these three examples are showing.<br>
</blockquote>
<br></span>
A percentage of an expected distance.<br>
<br>
Error of two points compared to a specific distance.<br>
<br>
>>> relerr(5 - -5, 10)<br>
0.0<br>
<br>
I think unless you use decimal, the ulp example will either be zero or some large multiple of ulp.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Take a look at the statistics test suite.<br>
</blockquote>
<br></span>
I definitely will. :-)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'll be the first to admit<br>
that the error tolerances are plucked from thin air, based on what I<br>
think are "close enough", but they show how such a function might work:<br>
<br>
* you provide two values, and at least one of an absolute error<br>
tolerance and a relative error;<br>
* if the error is less than the error(s) you provided, the test<br>
passes, otherwise it fails;<br>
* NANs and INFs are handled apprpriately.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
is_close(218.345, 220, 1, .05) # OHMs<br>
is_close(a, b, ULP, 2) # ULPs<br>
is_close(a, b, AU, .001) # astronomical units<br>
<br>
<br>
I don't see anyway to generalise those with just a function.<br>
</blockquote>
<br>
Generalise in what way?<br>
</blockquote>
<br></span>
I meant a function that would work in many places without giving some sort size and tolerance hints.<br>
<br>
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.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
By using objects we can do a bit more. I seem to recall coming across<br>
measurement objects some place. They keep a bit more context with them.<br>
</blockquote>
<br>
A full system of <value + unit> arithmetic is a *much* bigger problem<br>
than just calculating error estimates correctly, and should be a<br>
third-party library before even considering it for the std lib.<br>
</blockquote>
<br></span>
Yes, I agree. There are a few of them out there already.<br>
<br>
Cheers,<br>
Ron<div class=""><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/<u></u>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/<u></u>codeofconduct/</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>