On Sun, Jul 5, 2020 at 6:51 PM David Mertz <me...@gnosis.cx> wrote:
>
> will always return x for every finite and infinite value, so it must
>> return x for NANs too.
>>
>
> I strongly agree with Steven here. Also about order-dependence in results
> of min() and max() being disturbing and contrary to IEEE-754.
>
> ... so, umm... Steven... statistics.median()?!
>
Since you brought that up -- I recall a lot of debate about whether NaN's
should be considered missing values or "poisoning" in the statistics module
-- there are arguments for both, and neither was clear or obvious. So using
NaN to mean "not specified" in this context would not be obvious to
everyone, and when we have the perfectly good None instead, why do it?
Btw, definitely +1 on math.clamp(value, *, lower=None, upper=None) .
>
what about:
math.clamp(value, *, lower=-math.inf, upper=math.inf) .
Also it seems we can have "NaN poisoning" behaviour without explicitly
checking for it. The real key is not that it's a NaN, but that it doesn't
compare as True to anything. Someone smarter than me could probably make
this cleaner, but this works:
In [112]: def min(x, y):
...: if x < y:
...: return x
...: elif y <= x:
...: return y
...: else:
...: return x if not (x < math.inf) else y
Note that I did that ugly ternary expression at the end in hopes that it
would work with non-float NaN-like objects, but no luck there, at least not
with Decimal:
In [113]: min(1, Decimal('NaN'))
---------------------------------------------------------------------------
InvalidOperation Traceback (most recent call last)
<ipython-input-113-3bedbbbf79f2> in <module>
----> 1 min(1, Decimal('NaN'))
<ipython-input-112-77103db78666> in min(x, y)
1 def min(x, y):
----> 2 if x < y:
3 return x
4 elif y <= x:
5 return y
InvalidOperation: [<class 'decimal.InvalidOperation'>
It seems that Decimal Nan does not behave like FP NaNs :-(
-1 on built-in. -0 on any other function signature. Actually, I'm fine
with math.clip() as well, but clamp seems more popular.
One thing about putting it in the math module is that we could then make
assumptions about the float type. And we'd have to write it in C, so it
would be fast, even if there is some ugly NaN-checking behavior and the
like.
-CHB
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/V3XVFUNWATUWEJUS64JNLEJBPJ6HWGJH/
Code of Conduct: http://python.org/psf/codeofconduct/
