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

[George N. White]

On 7 Jun 2000, Johann Hibschman wrote:

> Konrad Hinsen writes:
> 
> > Charles G Waldman <cgw at fnal.gov> writes:
> >> 
> >> What do you think the consistent behavior should be?  Should
> >> math.exp(-10000) return 0, or raise some exception?
> 
> > I have yet to encounter a case where returning 0 would cause a problem,
> > so I'd vote for that solution. But raising an execption systematically
> > would be fine as well, one could then catch it and return 0 if that's
> > what is wanted.
> 
> Unsignalled underflows are very bad.  Most of my work conceptually
> fits on a log-log scale, so the difference between 0 and 10^-100 is
> immense.  If something underflows, I want to know that at the point of
> underflow, not at the point where I try to take the log of it.
> 
> -- 
> Johann Hibschman                           johann at physics.berkeley.edu

There are a couple issues in this thread:

1)  cross-platform consistency

2)  treatment of exceptions: underflow, overflow, invalid, ...

For 1), Sun's freely distributable math library should eliminate the
effects of differences in vendor-supplied math libraries

For 2), support for reliable reporting of f.p. exceptions when they occur
conflicts with techniques (e.g., combined multiply+add: y=a*x+b) used to
get better f.p. performance in new processor designs.  Since the
marketplace favors speed over all else, the conflict will likely be
resolved in favor of performance.  This is reflected in the lack of
support for f.p. exceptions in language standards.  It is much faster and
easier to simply store a 0, +/-Inf, or NaN and keep going.  Until we have
benchmarks that explicity test underflow and overflow behaviour, vendors
are going to focus on performance for the simplest cases.  In practical
terms, users need to a) write code that doesn't rely on exception handlers
and b) push for support in language stds. for features needed to work with
signed 0, NaN's and Inf's in (e.g.: don't optimize away expressions like
'x != x').

As it happens, just this week I encountered a subroutine that was
returning NaN's from a calculation of the form: y*log(y) where y=exp(-x)
and x was large enough to cause underflow, giving 0*(-Inf)=NaN.  I tried
trapping the underflow, but there were _thousands_ of log(y) expressions
used in a way that did not cause any difficulty before I reached the one
that was returning a NaN.  In this case, trapping underflows gave so many
false positives that it didn't help identify the real problem area in the
code.

Perhaps a better approach for Johann's specific example would be to use a
special non-underflow function, exp_p(-x), that calls an error routine
when x exceeds some threshold, or add a test before exp(-x) is called.

--
George N. White III <gnw3 at acm.org> Bedford Institute of Oceanography