[Huaiyu Zhu]
> ...
> So can we set a flag to explicitly discount ERANGE? There are
> only 19 lines in the source code that contain ERANGE, and 8 lines
> containing math_error.
> All the latter are in Modules/{c,}mathmodule.c. Could we just
> add an ifdef IEEE754 on these 8 lines? This would go a long way to
> aleviate this problem before we find a perfect solution, if there
> is one.
That would stop the exception on exp() underflow, which is what you're
concerned about. It would also stop exceptions on exp() overflow, and on
underflow and overflow for all other math functions too. I doubt Guido will
ever let Python ignore overflow by default, #ifdef'ed or not. A semantic
change that jarring certainly won't happen for 2.0 (which is just a week
away).
> ...
> I'm not interested in where this comes from - the only thing that
> matters is that it worked in 1.5.2 and breaks in 2.0.
The behavior of underflowing exp() is hardly the only thing that matters,
although it's becoming clear it may be the only thing you care about <0.9
wink>. I would like to change that too for 2.0, but give a thought to the
other consequences. If some change to the Python config screwed up
exp(-1000) for you, what else is going wrong? You're not going to get an
answer to that until we know exactly "where this comes from".
> Whether the 1.5.2 behavior was> intended or not, it's not a bug. The
> 2.0 behavior is a bug. If Posix conflicts with IEEE floating point
> arithmetic, then confirming to Posix in this regard is a bug.
POSIX doesn't conflict w/ 754 here, as 754 is silent on the matter of errno,
as is POSIX on 754 issues. It was Python's decision (not POSIX's) to raise
an exception when errno gets set. Python wasn't designed to support 754,
and makes no claim to support any part of it, so conformance to 754 may be
presented as a feature request, but trying to beat Python over the head with
it won't work: there's no bug here, in the strong sense that no documented
(or even intended!) behavior has changed. What happened is that one
platform accident got changed to a different platform accident. You
certainly get sympathy for that, but not enough to buy radical last-minute
changes.
> I would suggest the next thing to do is to introduce an IEEE754
> flag and let those who do not like it to voice their opinions.
Nothing like that will happen without a PEP first. I would like to see
*serious* 754 support myself, but that depends too on many platform experts
contributing real work (if everyone ran WinTel, I could do it myself
<wink>).
> Since this is the same behavior as 1.5.2 I doubt any running code would be
> broken by this.
Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and
current code certainly relies on detecting overflows in math functions. It
would also break code on platforms that were setting errno to ERANGE all
along on underflow (as POSIX appears to require, and ANSI C doesn't appear
to forbid; I don't know of such a platform for sure offhand, but to judge
from their manpages, HPUX looks like one).
In no case can you expect to see overflow ignored in 2.0.
I want to know where this comes from, so we have *some* handle on what other
surprises may be lurking.
If no progress is made on determining the true cause over the next few days,
I'll hack mathmodule.c to ignore ERANGE in the specific case the result
returned is a zero (which would "fix" your exp underflow problem without
stopping overflow detection). Since this will break code on any platform
where errno was set to ERANGE on underflow in 1.5.2, I'll need to have a
long discussion w/ Guido first. I *believe* that much is actually sellable
for 2.0, because it moves Python in a direction I know he likes regardless
of whether he ever becomes a 754 True Believer.
like-herding-cats-indeed-ly y'rs - tim
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