[Python-Dev] should a float overflow or just equal 'inf' (original) (raw)

Tim Peters tim_one@email.msn.com
Sat, 6 May 2000 15:47:25 -0400

[Trent Mick]

I submitted a patch a coupld of days ago to have the 'b', 'i', and 'h' formatter for PyArgParseTuple raise an Overflow exception if they overflow (currently they just silently overflow). Presuming that this is considered a good idea, should this be carried to floats.

Floats don't really overflow, they just equal 'inf'. Would it be more desireable to raise an Overflow exception for this? I am inclined to think that this would not be desireable based on the following quote: """ the-754-committee-probably-did-the-best-job-of-fixing-binary-fp- that-can-be-done-ly y'rs - tim """ In any case, the question stands. I don't really have an idea of the potential pains that this could cause to (1) efficiecy, (2) external code that expects to deal with 'inf's itself. The reason I ask is because I am looking at related issues in the Python code these days.

Alas, this is the tip of a very large project: while (I believe) every platform Python runs on now is 754-conformant, Python itself has no idea what it's doing wrt 754 semantics. In part this is because ISO/ANSI C has no idea what it's doing either. C9X (the next C std) is supposed to supply portable spellings of ways to get at 754 features, but before then there's simply nothing portable that can be done.

Guido & I already agreed in principle that Python will eventually follow 754 rules, but with the overflow, divide-by-0, and invalid operation exceptions enabled by default (and the underflow and inexact exceptions disabled by default). It does this by accident <0.9 wink> already for, e.g.,

1. / 0. Traceback (innermost last): File "<pyshell#0>", line 1, in ? 1. / 0. ZeroDivisionError: float division

Under the 754 defaults, that should silently return a NaN instead. But neither Guido nor I think the latter is reasonable default behavior, and having done so before in a previous life I can formally justify changing the defaults a language exposes.

Anyway, once all that is done, float overflow will raise an exception (by default; there will also be a way to turn that off), unlike what happens today.

Before then, I guess continuing the current policy of benign neglect (i.e., let it overflow silently) is best for consistency. Without access to all the 754 features in C, it's not even easy to detect overflow now! "if (x == x * 0.5) overflow();" isn't quite good enough, as it can trigger a spurious underflow error -- there's really no reasonable way to spell this stuff in portable C now!