<div dir="ltr">It really doesn't make sense to me that a clamp() function would *limit to* a NaN. I realize one can write various implementations that act differently here, but the principle of least surprise seems violated by letting a NaN be an actual end point IMO. <span style="font-size:11.2px">numpy.clip() seems to behave just right, FWIW.</span><div><span style="font-size:11.2px"><br></span></div><div><span style="font-size:11.2px">If I'm asking for a value that is "not more than (less than) my bounds" I don't want all my values to become NaN's. by virtue of that. A regular number is not affirmatively outside the bounds of a NaN in a commonsense way. It's just not comparable to it at all. So for that purpose—no determinable bound—a NaN amounts to the same thing as an Inf (but just for this purpose, they are very different in other contexts).</span></div><div><span style="font-size:11.2px"><br></span></div><div><span style="font-size:11.2px">I guess I think of clamping as "pulling in the values that are *definitely* outside a range." Nothing is definite that way with a NaN. So 'clamp(nan, -1, 1)' is conceptually 'nan' because the unknown value might or might not be "really" outside the range (but not definitely). And likewise 'clamp(X, nan, nan)' has to be X because we can't *know* X is outside the range.</span></div><div><span style="font-size:11.2px"><br></span></div><div><span style="font-size:11.2px">A NaN, conceptually, is a value that *might* exist, if only we knew more and could determine it.... but as is, it's just "unknown."<br></span><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 4:50 PM, Chris Barker <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Tue, Aug 2, 2016 at 11:45 AM, Random832 <span dir="ltr"><<a href="mailto:random832@fastmail.com" target="_blank">random832@fastmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Sure, but what the standard doesn't say is exactly what sequence of<br>
comparisons is entailed by a clamp function.<br>
<br>
def clamp(x, a, b):<br>
if x < a: return a<br>
else:<br>
if x > b: return b<br>
else: return x<br>
<br>
def clamp(x, a, b):<br>
if a <= x:<br>
if x <= b: return x<br>
else: return b<br>
else: return a<br>
<br>
There are, technically, eight possible naive implementations, varying<br>
along three axes:<br>
</blockquote><div><br></div></span><div>Exactly-- I thought this was self evident, but apparently not -- thanks for spelling it out.</div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">All such functions are equivalent if {a, b, x} is a set over which the<br>
relational operators define a total ordering, and a <= b. However, this<br>
is not the case if NaN is used for any of the arguments.<br>
<div><div></div></div></blockquote><div><br></div></span><div>Exactly again -- NaN's are kind of a pain :-(</div><div><br></div><div>As for the convert to floats issue -- correctness is more important than performance, and performance is probably most important for the special case of all floats. (or floats and integers, I suppose) -- i'm sure we can find a solution. LIkely something iike the second option above would work fine, and also work for anything with an ordinary total ordering.</div><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div>-Chris</div><div><br></div><div><br></div></font></span></div><span class="gmail-">-- <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>
<br>_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Keeping medicines from the bloodstreams of the sick; food <br>from the bellies of the hungry; books from the hands of the <br>uneducated; technology from the underdeveloped; and putting <br>advocates of freedom in prisons. Intellectual property is<br>to the 21st century what the slave trade was to the 16th.<br></div>
</div></div></div>