[Trent Mick]
> I submitted a patch a coupld of days ago to have the 'b', 'i', and 'h'
> formatter for PyArg_ParseTuple 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!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4