[Python-ideas] math.inf and math.nan constants
Steven D'Aprano
steve at pearwood.info
Wed Jan 7 17:09:26 CET 2015
On Wed, Jan 07, 2015 at 02:33:54PM +0100, Todd wrote:
> The current way to get infinite and nan floats are to do float("inf") and
> float("nan"), respectively. For many applications, this is sufficient.
> However, for scientific and mathematical computing, using inf and nan
> values is very common, and the current approach is very verbose. So for
> those applications, I think it would be useful if the math standard library
> module provided "math.nan" and "math.inf", which would return the same
> thing as float("nan") and float("inf"), respectively.
Compare:
inf = float('inf')
func(inf)
versus:
from math import inf
func(inf)
Defining your module's own constant actually takes two characters fewer
than importing it from the math module.
In any case, we're talking about an utterly trivial micro-optimization.
This is Python, not Unix shell scripting. We don't use names like
"umount" to save one character over "unmount", we encouraging writing
for clarity and correctness over brevity.
The math module has constants pi and e because it would be truly an
inconvenience to have to create them yourself:
pi = 3.14159265389793
I can remember the first six digits of pi, 3.1415, anything more than
that I have to look up, and of course there is the considerable risk of
getting it wrong, as I did above.
But the same does not apply to creating your own inf constant. There is
no long series of digits to remember, just three letters, and it's hard
to get it wrong. Whether you write
import math
process(math.inf)
or
inf = float('inf')
process(inf)
is much the same effort. At worst, we might say that it is a matter of
personal taste which you prefer. But frankly, the difference is trivial.
Of course, writing float('inf') every single time you want an infinity
is wasteful and silly, but that's a matter of education. If you can't
teach people to write inf = float('inf') you won't be able to teach them
to use math.inf either.
Up to now, I have only discussed inf, not nan, because there is only one
inf value in floats. (Two if you count -inf.) But the IEEE 754 standard
provides many different NAN values, and offers a possible interpretion
of them: the extra "payload" on each NAN can be used to carry diagnostic
information on which numeric operation failed. Back in the 1980s, I was
a user of the Apple Standard Numerics Environment (SANE), which provided
easy access to NAN payloads and a standard interpretation for them. It
is a system which can work well and help in debugging.
Python today doesn't give us any simple way to access all those
different float NANs, or offer any interpretation of what they might
mean, but it might some day. I am strongly opposed to anything which
might pre-empt that or discourage future advances.
In summary:
- offering a math.inf is harmless but not especially useful;
- offering a single math.nan is harmful and I strongly oppose it.
--
Steve
More information about the Python-ideas
mailing list