Christopher Barker writes:
On Sun, Sep 13, 2020 at 8:10 AM Stephen J. Turnbull < email@example.com> wrote:
As Steven points out, it's an overflow, and IEEE *but not Python* is clear about that. In fact, none of the actual infinities I've tried (1.0 / 0.0 and math.tan(math.pi / 2.0)) result in values of inf. The former raises ZeroDivisionError and the latter gives the finite value 1.633123935319537e+16.
probably because math.pi is not exact, either -- I'm pretty sure Python is wrapping the C lib for math.tan, so that's not a Python issue.
The issue is that Python doesn't produce true infinities as far as I know, so "inf" is a very poor name for float('inf') in builtins. I wince at math.inf as well, but at least there it feels like "this is an IEEE 754 feature that Python uses".
In the Python world, numpy lets the user control the error handling:
Not every 1_000_000 line module needs to be a builtin. We're talking about adding these names to the builtins, what NumPy does is irrelevant (and NumPy already has its own inf).
As you've noticed, Python itself has limited use for Inf and NaN values, which is probably why it got as far as it did with the really bad support before 2.6. But these special values are used in external code called from Python (including numpy), an so it's helpful to have good support for them in Python anyway.
What's ungood about "from math import inf, nan"? Or "from numpy import inf, nan"?
IEEE 754 is a very practical standard -- it was well designed, and is widely used and successful. It is not perfect, and in certain use cases, it may not be the best choice. But it's a really good idea to keep to that standard by default.
I agree, but Python doesn't. It raises on some infs (generally speaking, true infinities), and returns inf on others (generally speaking, overflows). To change that you need to bring in C extensions.
Note that one of the key things about numpy, and why its defaults are different, is that it does array-oriented math. Most people do not want their entire computation to be stopped if only one value in an array under- or over-flows, etc.
That's fine, but Python doesn't give you that. In floats, 0.0 is not true 0, it's the set of all underflow results plus true 0. So by your argument, in float arithmetic, we should not have ZeroDivisionErrors. But we do raise them.
Anyway, the only thing on the table now is putting a couple names in the builtin namespace.
Which is why I've tried pretty hard to stick to those aspects of inf and nan that are builtin to Python or available directly with "from math import inf, nan".