<div dir="ltr">On Sun, Jan 18, 2015 at 11:51 PM, Stephen J. Turnbull <span dir="ltr"><<a href="mailto:stephen@xemacs.org" target="_blank">stephen@xemacs.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""> > But I still think we can provide something that is useful for most<br>
> use-cases, and would like to propose what that is, and what the<br>
> decision points are:<br>
<br>
</span>It would be useful, that is, if the user knows what she is doing. The<br>
problem exposed by the plethora of use cases is that in many cases<br>
users don't know what they're doing, and it's *not* just a matter of<br>
forgetting to take the absolute value.<br></blockquote><div><br></div><div>I was afraid of this -- my take is that EVERY algorithm has corner cases, an special cases, and places where it is appropriate and where it is not. And this list (and all lists...) is full of folks that like to hash this stuff out. So the fact that there has been a long and drawn out discussion does not mean that there is not a generally useful function to be had.<br><br></div><div>And I think, in fact, that such a function does is exist that will work most of teh time, even for users that have not thought it out carefully.<br><br></div><div>We, in fact have a lot of evidence that this is needed:<br><br></div><div>* numpy has close() and all_close -- they are widely used, mostly successfully<br><br></div><div>* Steven took that time to write one (and tests for it) for the statistics module tests.<br><br></div><div>* The unittest module has something -- and a poor one (IMHO) at that -- but is still useful.<br><br></div><div>* Boost has one (not Python, but still....)<br></div><br> > It will not do a simple absolute comparison -- that is the job of a<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> different function, or, better yet, folks just write it themselves:<br>
><br>
> abs(x - y) <= delta<br>
><br>
> really isn't much harder to write than a function call:<br>
><br>
> absolute_diff(x,y,delta)<br>
<br>
</span>for relative error<br>
<br>
abs(x - y)/min(abs(x), abs(y))<br>
<br>
really isn't that hard to write -- if you know that's what you want.<br>
</blockquote><div><br></div><div>that is, I think, just enough harder to think about and write than the absolute comparison method, that it's worth it. And if others think an absolute_close is worth adding, too, I have no problem with that.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But Neil and Ron *don't* want that: they know which value is correct<br>
and that it's never zero.<span class=""><br></span></blockquote><div><br></div><div>I think my proposal satisfies both Neil and Ron's use case -- or a version of it can, and also Steven's.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> It will be designed for floating point numbers, and handle inf,<br>
> -inf, and NaN "properly".<br>
<br>
</span>Which means what? Something different from what a conforming IEEE 754<br>
implementation would do?<br></blockquote><div><br></div><div>no, sorry for being lazy in writing, -- I meant it would conform to IEEE 754. i.e. NaN would not be close to anything, including another NaN, and inf and -inf would only be close to themselves. (though I don't know that ieee ever mentions non-exact comparison...)<br></div><div><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The farther we get into this, the more handwaving is being done by<br>
advocates. Despite what I wrote above, it's not trivial to write a<br>
correct symmetric relative error: some such function would be useful.<br></blockquote><div><br></div><div>if it's not trivial, then all the reason to to put it in the standard lib.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But I think that it should have a name that (at least to some extent)<br>
indicates what it actually does (unlike is_close(), which users are<br>
likely to assume means what they think it means because they haven't<br>
thought about the alternatives).<br></blockquote><div><br></div><div>Indeed -- I think that the name of the function, and it's parameters need to be carefully chosen to best convey what they mean. (and the docstring).<br><br></div><div>What I"d like to do is determine whether there is any hope of coming to a consensus about what a reasonable implementation would look like. If not, then so be it. If so, then I guess I"ll need to write a PEP and then hash out the naming and details.<br><br></div><div>So I think the next step is to hear form the active participants in this thread as to whether they think there's hope, and/or from Guido and other core developers as to whether they're ready to reject it at this point -- I don't want to waste any more of my or anyone else's time.<br><br></div><div>-Chris<br><br></div></div><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>