Chris Angelico writes: > In mathematics, "infinity" isn't a value. One cannot actually perform > arithmetic on it.
That's a rather controversial opinion. Even intuitionist mathematicians perform arithmetic on infinities; they just find it very distasteful that they have to do so. > Computers can't do that. This is flat wrong. It is very *inefficient* to have *current* computers perform arithmetic on infinities (transcendental quantities, etc), but Stephen Wolfram (and his net worth) would be very surprised at your statement. > So we have a set of rules for approximating mathematics in ways > that are useful, Exactly right. > even though they're not true representations of real numbers. That's imprecise. They are *true* representations of certain real numbers, but they are also *approximate* representations of other real numbers, and the function from value to representation is not invertible (as an extended-real-valued function). > They're *good enough* for real-world usage. True for *finite* IEEE floats. Very controversial for inf and nan, and especially for Python's rather inconsistent API for IEEE float. > And that's why we need "Infinity" to be a value, of sorts. That's a non sequitur. First, inf already *is a value* in Python, it has a name both as str and repr, and it even has a pseudo-literal name in the math module. It just doesn't have a pseudo-literal name in builtins (and that is all that is on offer here -- the proponents say over and over again that they're not asking for keywords, and haven't proposed a literal name for -inf yet). Second, that the connected spaces of positive and negative reals which have float representations are usefully approximated by floats does not imply that the isolated points of -infinity, zero, and +infinity are equally useful approximations. They may be, but my strongly-held opinion is "nah." In practice, the justification for inf and nan is that in an inner loop it's extremely inefficient to raise and handle exceptions every time an overflow, underflow, or domain error occurs. So you substitute inf or nan as appropriate, keep looping until done, and then work with the presumed accurate finite values that remain. *inf and nan don't need to have names to serve such functions*, let alone names in builtins. > If you want to define infinity as any particular value, you're going > to get into a contradiction somewhere sooner or later. But its > behaviour in IEEE arithmetic is well defined and *useful* even without > trying to make everything make sense. As Ben Rudiak-Gould shows, the behavior of operations whose results do not have representation as Python floats is anything but "well-defined". > Let's stick to discussing whether "inf" (or "Infinity") should become > a new builtin name Definitely not "Infinity" (unless you want to go for a keyword, in which case a capitalized keyword in the tradition of None, False, and True seems appropriate). We've used "inf" for (a) decade(s), we don't need a new name. As for builtins, "what's so ungood about 'from math import inf, nan'?" I don't see a persuasive answer to that. _______________________________________________ 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/XQHR4N7M3AHYYDPN3C73JYOAIEJFUDV4/ Code of Conduct: http://python.org/psf/codeofconduct/
