On Sat, Sep 12, 2020 at 5:05 PM Steven D'Aprano <steve@pearwood.info> wrote:
On Sat, Sep 12, 2020 at 12:56:25PM -0700, Christopher Barker wrote:

> Is there any guarantee in Python or the C spec, or the IEEE spec that, e.g.:
> 1e10000
> would create an Inf value, rather than an error of some sort?

IEEE-754 requires that float literals overflow to infinity.

sure, which means that, e.g.  1e100 * 1e300 would overflow to Inf.

But that doesn't say anything about interpreting a literal. I don't if C libs necessarily parse:


and then do xx * 10**yy, which would be an overflow, or if they do something more direct, in which case, they *could* note that the value is not representable and raise an error.

So that's what I'm wondering -- is there a standard that says the a too-large literal should overflow, and therefgor create and inf, rather than being an error.

by the way, this behavior is not consistent with python, which will give an error, rather than returning inf when the same operation overflows:

In [22]: math.pow(10, 1000)                                                    
OverflowError                             Traceback (most recent call last)
<ipython-input-22-6efc9a2b034c> in <module>
----> 1 math.pow(10, 1000)

OverflowError: math range error

So in Python, at least, interpreting the literal is not the same as computing the pow().


I don't have a source for this (I cannot find a copy of the IEEE-754
standard except behind paywalls) but I have a very strong memory of
either Tim Peters and Mark Dickinson stating this, and I believe them.
(If either of them are reading this, please confirm or deny.)

> And there's still NaN -- any way to get that with a literal?

If you have an INF, then you can generate a NAN with `INF - INF`.

In general though, Python doesn't support generating the full range of
NANs with payloads directly.

Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LX5XVAN3FZCXBBHVKU6MGKWXZAS63Y2D/
Code of Conduct: http://python.org/psf/codeofconduct/

Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython