On Sun, Jul 5, 2020, 10:25 PM Steven D'Aprano <st...@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.
_______________________________________________ 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/ZVBGV7UDCFC4OEFE5UFV7ZNUFK223ZIC/ Code of Conduct: http://python.org/psf/codeofconduct/
