<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 1, 2016 at 1:10 PM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It means that this clamp() function would have to be implemented in C.<br>
It *doesn't* mean that it will have to convert its arguments to floats,<br>
or reject non-float arguments.<br></blockquote><div><br></div><div>sure -- though I hope it would special-case and be most efficient for floats.  However, for the most part, the math module IS all about floats -- though I don't suppose there is any harm in allowing other types.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> This follows the IEEE spec -- so the only correct result from<br>
><br>
> clip(x, float('nan')) is NaN.<br>
<br>
</span>I don't agree that this is the "only correct result".<br></blockquote><div><br></div><div>I don't think IEE754 says anything about a "clip" function, but a NaN is neither greater than, less than, nor equal to any value -- so when  you ask if, for example, for the input value if it is less than or equal to NaN, but NaN if NaN is great then the input, there is no answer -- the spirit of IEEE NaN handling leads to NaN being the only correct result.</div><div><br></div><div>Note that I'm pretty sure that min() and max() are wrong here, too.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That's why I said that it was an accident of implementation that passing<br>
a NAN as one of the lower or upper bounds will be equivalent to setting<br>
the bounds to minus/plus infinity: </blockquote><div><br></div><div>exactly -- and we should not have the results be an accident of implimentation -- but rather be thougth out, and follow IEE754 intent.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I suppose we could rule that case out: if either bound is a NAN, raise<br>
an exception. But that will require a conversion to float, which may<br>
fail. I'd rather just document that passing NANs as bounds will lead to<br>
implementation-specific behaviour that you cannot rely on it.</blockquote><div><br></div><div>why not say that passing NaNs as bounds will result in NaN result? At least if the value is a float -- if it's anything else than maybe an exception, as NaN does not make sense for anything else anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> If you<br>
want to specify an unbounded limit, pass None or an infinity with the<br>
right sign.</blockquote><div><br></div><div>exactly -- that's there, so why not let NaN be NaN?</div><div><br></div><div>-CHB</div><div><br></div><div><br></div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="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>