math.exp underflow (was: exp behaviour: is it a bug ?)

[Tim Peters]

[posted & mailed]

[Konrad Hinsen]
> I'd prefer a portable solution to one that reflects the system math
> library.

Konrad, make up your mind <wink> :  "portable" and "reflects the system" are
at each other's throats.

> I had the same problem under AIX, and I solved it by patching
> Python. I just wonder if someone has the patience to work out a
> patch that would create the same behaviour independently of what the
> math library does. Not me, unfortunately...

C gives almost no control over this, so it's not "a patch", but a whole
bunch of #ifdef'ed patches contributed by individual platform experts.  If
my new employer lets me, I'd like to work on setting up a usable framework
to make such patches possible and pleasant (& see below).


[Charles G Waldman]
> What do you think the consistent behavior should be?  Should
> math.exp(-10000) return 0, or raise some exception?

IEEE-754 has been around since the mid-80's and almost all platform HW
supports it directly now.  The next version (ISO's current version, in
fact!) of C ("C9X") mandates new features for good control over the 754
environment ("current" C offers *no* control).  So that's the only realistic
way to go.  In the 754 spirit, math.exp(-10000) should return +0 and set
"the underflow flag"; the user should also be given a runtime-settable
option to say whether or not "setting the underflow flag" also raises an
exception, and functions to query and set and clear the states of individual
754 flags (both the "did such-&-such a condition occur?" and the "when
such-and-such a condition occurs, should it raise an exception?" flags).
Guido and I agreed earlier that the "overflow", "divide by 0", and "invalid
operation" conditions should raise exceptions by default; "inexact" and
"underflow" should not; & all of those should be changeable by the user at
runtime.

python-*could*-be-an-outstanding-754-platform-ly y'rs  - tim