<div dir="ltr">oops, forgot ot reply-all<br><br><div><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Chris Barker</b> <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>></span><br>Date: Sat, Jan 17, 2015 at 8:38 PM<br>Subject: Re: [Python-ideas] Way to check for floating point "closeness"?<br>To: Terry Reedy <<a href="mailto:tjreedy@udel.edu">tjreedy@udel.edu</a>><br><br><br><div dir="ltr"><span class="">On Fri, Jan 16, 2015 at 8:09 PM, Terry Reedy <span dir="ltr"><<a href="mailto:tjreedy@udel.edu" target="_blank">tjreedy@udel.edu</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br></span>
As near as I can tell,<br>
assertAlmostEqual(first, second, places=7, msg=None, delta=None)<br>
does one of two possible absolute difference checks<br>
(round(first, places) - round(second, places)) == 0.0<br>
abs(first - second) < = delta<br>
<br>
There has been discussion of making it more complicated, but I remember that being rejected because other tests require more thought and can be implemented with the above anyway.<span><br></span></blockquote><div><br></div></span><div>anything could be implemented with a simple absolute tolerance method, and for that matter, that is simple enough that there's not much point in having a built in function for it.anted (and a bit harder to write yourself)<br>
</div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<br></span>
assertAlmostEqual((a-b)/d, 0, delta = tol)<br>
where d is a, b, and (a+b)/2 as one thinks is appropriate.<br></blockquote><div><br></div></span><div>while yopu're at it, why not jsut write your own assertion:<br><br></div><div>assert (a-b)/b <= tol<br><br></div><div>that function buys you nothing but potential confusion.<br><br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The discussion on the thread seems mostly divorced from the multiple use cases.  What do each of a and b represent? Different numbers?  or successive approximations of the same number?  Are they theoretical 'exact' numbers, approximations of theoretical numbers, or calculations from measurements with error?  If the latter, how big is the error?  And why are we asking anyway?  We are usually asking 'close enough' for some purpose, but purposes differ.<br></blockquote><div><br></div></span><div>yes, they sure do -- but anything in the standard library would be for general use, where the details don't matter too much -- if you are doing something really specific, write your own test.<br></div><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  (Someone claimed that 'nothing is close to zero'.  This is nonsensical both in applied math and everyday life.)  </blockquote><div><br></div></span><div>I'm pretty sure someone (more than one of use) asserted that "nothing is *relatively* close to zero -- very different.<br><br></div><div>And indeed, that is still a primary stumbling block (at least for me) to putting a relative tolerance function into the stdlib: it will work fine in most cases, and be easy to understand and reason about, but it will not work if one of the input values is zero, and casual users may get tripped up by that. But at this point, i think that just needs  note in the docs -- after all, they are likely to get tripped up by that if they write the code themselves anyway.<br><br></div><div>And I really wanted a way to have a default behavior that would do a reasonable transition to an absolute tolerance near zero, but I no longer thing that's possible. (numpy's implimentaion kind of does that, but it is really wrong for small numbers, and if you made the default min_tolerance the smallest possible representable number, it really wouldn't be useful.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>-Chris<br><br></div></font></span></div><span class=""><br>-- <br><div><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            <a href="tel:%28206%29%20526-6959" value="+12065266959" target="_blank">(206) 526-6959</a>   voice<br>7600 Sand Point Way NE   <a href="tel:%28206%29%20526-6329" value="+12065266329" target="_blank">(206) 526-6329</a>   fax<br>Seattle, WA  98115       <a href="tel:%28206%29%20526-6317" value="+12065266317" target="_blank">(206) 526-6317</a>   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</span></div></div>
</div><br><br clear="all"><br>-- <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>