<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 23, 2015 at 8:05 AM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> The primary expected use case is various forms of testing -- "are the<br>
> results computed near what I expect as a result?" This sort of test<br>
> may or may not be part of a formal unit testing suite.<br>
><br>
> The function might be used also to determine if a measured value is<br>
> within an expected value.<br>
<br>
</span>This section is very weak.</blockquote><div><br></div><div>I'll see what I can do to strengthen it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> As someone who doesn't do numerically<br>
intensive computing I would start with the assumption that people who<br>
do would have the appropriate tools in packages like numpy, and they<br>
would have the knowledge and understanding to use them properly. So my<br>
expectation is that this function is intended specifically for<br>
non-specialists like me.<br></blockquote><div><br></div><div>Indeed that is the idea (though there are plenty of specialists using numpy as well ;-) )</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Based on that, I can't imagine when I'd use this function. You mention<br>
testing, but unittest has a function to do this already. Sure, it's<br>
tied tightly to unittest, so it's not useful for something like<br>
py.test, but that's because unittest is the stdlib testing framework.<br>
If you wanted to make that check more widely available, why not simply<br>
make it into a full-fledged function rather than an assertion? </blockquote><div><br></div><div>That would be an option, but I don't think the one in unittest is the right test anyway -- its focus on on number of decimal digits after the decimal place is not generally useful. (that would make some sense for the Decimal type...)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And if<br>
it's not suitable for that purpose, why does this PEP not propose<br>
updating the unittest assertion to use the new function?</blockquote><div><br></div><div>well, for backward compatibility reasons, I had just assumed it was off the table -- or a long, painful road anyway. And the unitest is very vested in it's OO structure -- would we want add free-form functions to it?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> It can't be<br>
right to have 2 *different* "nearly equal" functions in the stdlib.<br></blockquote><div><br></div><div>Well, they do have a different functionality -- maybe some people really do want the decimal digits thing. I'm not sure we'd want one function with a whole bunch of different ways to call it -- maybe we would, but having different functions seems fine to me.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Outside of testing, there seems to be no obvious use for the new<br>
function. You mention measured values, but what does that mean?<br>
"Measure in the length of the line and type in the result, and I'll<br>
confirm if it matches the value calculated"? That seems a bit silly.<br></blockquote><div><br></div><div>This came up in examples in the discussion thread -- I'd don't think I would use it that way myself, so I'm going to leave it to others to suggest better examples or wording. Otherwise, I'll probably take it out. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'd like to see a couple of substantial, properly explained examples<br>
that aren't testing and aren't specialist. </blockquote><div><br></div><div>In practice, I think testing is the biggest use case, but not necessarily formal unit testing. That's certainly how I would use it (and the use case that prompted me to start this whole thread to begin with..). I'll look in my code to see if I use it other ways, and I'm open to any other examples anyone might have.</div><div><br></div><div>But maybe it should be with testing code in that case -- but I don't see any free-form testing utility functions in there now. Maybe it should go in unitest.util ? I'd rather not, but it's just a different import line.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My worry is that what this<br>
function will *actually* be used for is to allow naive users to gloss<br>
over their lack of understanding of floating point:<br>
<br>
    n = 0.0<br>
    while not is_close_to(n, 1.0): # Because I don't understand floating point<br>
        do_something_with(n)<br>
        n += 0.1<br></blockquote><div><br></div><div>Is that necessarily worse? it would at least terminate ;-) floating point is a bit of an attractive nuisance anyway.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
BTW, when writing that I had to keep scrolling up to see which order<br>
actual and expected went in. I'd imagine plenty of naive users will<br>
assume "it's symmetrical so it shouldn't matter" and get the order<br>
wrong.<br></blockquote><div><br></div><div>Well, I think the biggest real issue about this (other than should it be in the stdlib at all) is the question of a symmetrical vs. symmetrical test. I decided to go (for this draft, anyway) with the asymmetric test, as it is better defined and easier to reason about, and more appropriate for some cases. And the biggest argument for a symmetric test is that it is what people would expect.</div><div><br></div><div>So I tried to make the parameter names that would make it clear (rather than a,b or x,y) -- I think I failed on that, however -- anyone have a better suggestion for names? It turns out "actual" is far too similar in meaning to "expected".</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"> In summary - it looks too much like an attractive nuisance to me,</blockquote><div><br></div><div>If it's not there, the folks will cobble somethign up themselves (and I'm sure do, all the time). If they know what they are doing, and take care, then great, but if not then they may get something with worse behavior that this. Maybe they will at least understand it better, but I suspect the pitfalls will all still be there in a typical case. And in any case, have to take the time to write it. That's my logic anyway.</div><div><br></div><div>-Chris </div></div><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>