On Sun, Jul 05, 2020 at 09:42:07PM -0400, David Mertz wrote:
> The standard library *does* seem to have taken pains to avoid "finite
> nans."
I don't know what you mean by "finite nans". By definition, any NAN is
not considered finite.
py> math.isfinite(math.nan)
False
Do you mean, the stdlib has taken pains to avoid returning NANs ex
novo, i.e. from purely finite arguments? Then I agree.
> It kinda weakens your case about worrying about doing clamp() right
> in the face of NaNs :-).
Are you suggesting that we should do clamp() wrong instead? *wink*
What I intended is that the stdlib tends to raise rather than
return a NAN from some calculation not already including NANs or INFs.
But if you pass NANs into the calculation, then the stdlib honours them.
py> math.atan(math.nan)
nan
So if you pass a NAN to clamp(), it should do the right thing, which may
be returning a NAN:
clamp(NAN, -1, 1) # Should certainly return a NAN.
or may not:
clamp(NAN, 1, 1) # Should certainly return 1.
Only the behaviour when one or the other of the bounds are NANs is
controversial. I acknowledge that there are two good behaviours, and it
is reasonable for people to want one or the other. I have argued why one
is better and less inconvenient than the other, but I won't rehash that
argument here.
min() and max() are notable, and unfortunate, exceptions in that their
treatment of NANs depends on the order of argument. I would call that a
bug except that the statistics module (which I wrote) has the same flaw,
and I've argued in the past that this is not a bug :-)
But in both cases, statistics and min/max, it is clear that the
order-dependent behaviour satisfies nobody and is undesirable.
> It also looks like the trig functions are pruned to those that don't have
> undefined values for numbers I can type in. I can *type*
> `math.tan(math.pi/2)`, of course. But math.pi is a little bit smaller than
> the actual pi, so I just get a big number for an answer.
That's not the trig functions' fault, it's the fact that we cannot
exactly represent pi/2 exactly. I'm not sure what you mean by pruning
them, it is pretty much standard that tan(pi/2) doesn't fail:
https://stackoverflow.com/questions/20287765/math-tan-near-pi-2-wrong-in-net-right-in-java
and that comes out of the floating point representation, not tan.
> But I cannot try the hypothetical:
>
> >>> math.cot(0)
> nan
No, but you could try this instead:
py> math.log(0.0)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: math domain error
--
Steven
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/N7OCELBGCNAO5LUKBBTRKR35MB4AGSOJ/
Code of Conduct: http://python.org/psf/codeofconduct/
