[Python-ideas] math.inf and math.nan constants

[Steven D'Aprano]

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