<div dir="ltr">On Mon, Jan 12, 2015 at 6:32 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">Ok, but you're missing a huge issue, which is that according to the rule you suggest, 0.0 is not close to any non-zero value. </p></blockquote><div>Well, I did say I just threw something together (it's a gist, not a pull request!). and asked for test cases that would push it. At best it could be a starting point for experimentation and discussion - though Steven's code is probably a much better place to start.<br><br>Near zero clearly is one case to be considered. Perhaps that's why numpy used a relative AND absolute tolerance together -- I'll need to take a closer look at that.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">Handing such a function to users and claiming it's the one "is close" predicate they need is going to produce a lot of sad and confused users.</p></blockquote><div>I don't think we'll be able to come up with anything that is the "one" predicate anyone will even need. But I do think that it would be good to provide something that is useful for common cases, and more thought out than most folks will bother to write on their own.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p dir="ltr">I don't want to step on your positive let's-fix-it attitude, I think that's great, but... I do think you are really underestimating the complexity of the problem.</p></blockquote><div>I really didn't think I was done ;-)<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p dir="ltr">The right way to handle comparison with zero, or comparison between epsilon and negative epsilon, etc, really depends on the context. For common unit test cases it may even make sense to prefer a non-symmetric predicate -- e.g. if you're expecting 0 then 1e-100 is usually fine, but if you're expecting 1e-100 then getting 0 might be a huge problem.</p></blockquote><div>Sure, but no matter how you slice it, users will need to think. In fact, if you are expecting zero, you can write that test yourself pretty easily. Though that may be an example of why you want to provide an absolute tolerance method as well. It would be more appropriate if you are expecting zero.<br><br></div><div>From Bruce Dawson's article: "Zero is a huge nuisance. Avoid it if possible."</div><div><br></div><div>I don't love it, but numpy's allclose() has worked fine for me, and many other people, certainly well enough that I haven't bothered to write my own.<br></div><br></div>Also, thinking a bit about complex -- complex abs() is easy to think about, but maybe not as rigorous as both components being individually. For example:<br><br></div><div class="gmail_extra">1e100+0.1j and 1e100+10j -- should those be "close"? They are in the absolute value sense, but the imaginary part is not in the least.<br><br></div><div class="gmail_extra">-Chris<br><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>