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... 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