On Thu, Aug 4, 2016 at 5:35 AM, Steven D'Aprano <steve@pearwood.info> wrote:
The IEEE 754 standard tells us what min(x, NAN) and max(x, NAN) should
be: in both cases it is x.


I thought an earlier post said something about a alternatvie min and max? -- but anyway, consisetncy with min and max is a pretty good argument. 


    For instance max{x, y} should deliver the same result as max{y, x} but
    almost no implementations do that when x is NaN. There are good
    reasons to define max{NaN, 5} := max{5, NaN} := 5 though many would

I don't disagree that there are good reason, just that it's the final way to go :-) -- but if Kahan equivocates, then there isn't one way to go :-)

As you propose it, clamp() is no use to me: it unnecessarily converts the
bounds to float, which may raise an exception.

no it doesn't -- that's only one way to implement it. We really should decide on the behaviour we want, and then figure out how to implemt it -- not choose something because it's easier to implement.

there was an earlier post with an implementation that would give the NaN-poising behaviour, but would also work with any total-ordered type as well. not that's thought about possible edge cases.

I think this is it:

def clamp(x, a, b):
    if a <= x:
        if x <= b: return x
        else: return b
    else: return a

hmm -- doesn't work for x is NaN, but limits are not -- but I'm sure that could be worked out.

In [32]: clamp(nan, 0, 100)

Out[32]: 0



Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception