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

[Guido van Rossum]

On Wed, Jan 7, 2015 at 8:09 AM, Steven D'Aprano <steve at pearwood.info> wrote:

> 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)
>

But using a more common style, you already have math imported anyway, and
you can just write math.inf rather than having to interrupt your coding
flow, see if you already have an inf variable defined, if not define it,
etc.


>
> Defining your module's own constant actually takes two characters fewer
> than importing it from the math module.
>

But that's not the (whole) point. The existing idioms are commonly used and
unintuitive. I suppose you would also be in favor of defining e =
math.exp(1) in favor of math.e?

>
> 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.
>
> I say bah to that long-winded diatribe.


> 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.
>

I don't see how the existence of a nan constant pre-empts anything. Your
imagined new mechanism will have to co-exist with float("nan") anyway.


> In summary:
>
> - offering a math.inf is harmless but not especially useful;
>
> - offering a single math.nan is harmful and I strongly oppose it.


That's your opinion and you're entitled to it.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150107/29500d27/attachment.html>