On Sun, Jul 5, 2020, 10:25 PM Steven D'Aprano <steve@pearwood.info> 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.
The scare quotes because I know that's not a real thing. Maybe "genetically finite" ... I.e. do some operations on regular finite values that wind up with NaN. I know, I know... That's not really right either, since finite values can overflow to infinities on their own. Do you mean, the stdlib has taken pains to avoid returning NANs ex novo,
i.e. from purely finite arguments? Then I agree.
Yes. That's it. :-)
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 :-)
Personal growth is healthy! 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:
Of course. math.pi is a number that isn't really pi, as any finite representation must be. tan() is doing the right thing. I just meant that if math.cot() were added to the standard library, I could pass an exact zero as argument. None of the trig or hyperbolic functions that are undefined at ZERO are included. But yes, math.log(0) is another one where a NaN is avoided in favor of an exception. A few different log bases, but same story for all.