exception handling

[Douglas Priest]

[McKenney]

> Someone told me
> that NCEG was discussing IEEE exceptional value handling, but
> that none of the proposals has anything to say about floating
> point exception traps or trap handling.
> 
>     Is this true?
> 
>     If so, I am surprised not to see any complaints about it here.

I suspect that's because no one has yet discovered any more efficient
means of handling exceptions than computing away and testing flags
afterwards.

> 3.  I remember W. Kahan giving a talk on floating-point exceptions,
>     and what you could do with flexible exception handling; this
>     sounds like something of interest to this mailing list.

Prof. Kahan's proposed scheme is quite complicated, far more so than
the "compute-and-test-flags" approach, so not all programmers would
be able to make effective use of the features he advocates.  If using
those features could be shown to be more efficient than testing flags,
though, then some people might use them.  Unfortunately, without a
standard interface, the people who might be able to make the best
use of them, programmers of commercial and public domain numerical
software libraries, won't use those features, and we won't be able
to determine how efficient they would be.

>     However, this cannot be done (in present systems) without
>     having trap handlers, and ones that are given a fair amount
>     of FPU state.
> 
>     Instead, the trend seems to be not to give trap handlers any
>     information, not even what exception(s) occurred or where
>     it/they occurred.

Kahan's idea is that system libraries should supply all the necessary
trap handlers so users never need to write their own.  My experience
implementing parts of his scheme for some Solaris platforms has been
that it is possible, though not easy, to write such handlers.

(diverging from exception handling for the moment)

[Hough]

> Of course, most incorrect numerical results produced by programs are due 
> source program bugs and optimizer bugs and incorrect input data, but aside
> from those kinds of issues, the most common problem is roundoff.   But 
> roundoff occurs during most programs deliver correct results, too, and there
> isn't any way to distinguish good from bad except by human or automatic
> analysis.     That's why interval methods are so important - they encompass
> errors in the input data and its conversion to binary, in truncating analytic
> processes to computational ones, in roundoff due to finite precision, AND
> they handle underflow and overflow in a useful way as well.

Interval methods don't "distinguish good [errors] from bad", they just
provide bounds on errors from some sources.  Such methods are important
because they are the only way to reliably solve problems that require
global knowledge about functions.  They can be used to estimate the
effects of errors and uncertainty in input data, though I would think
that condition estimation would be a better way to do that.  Certainly
there are much better ways than interval arithmetic to cope with roundoff.

[McKenney]

>     I grant you, not all errors which produce wrong answers also
>     generate floating-point exceptions.  However, since 99% of
>     all exceptions are due to bugs,

As David Hough pointed out, more than 99% of all exceptions are benign
rounding errors.  Most of the rest are due to attempts to use a program
to solve a problem that lies outside the domain that program was designed
to cope with, and exception handling schemes such as Kahan's are intended
to help programmers design their programs to cope with a larger domain
of problems or at least respond less mysteriously when their domain is
exceeded.

>    I would be happy if everyone would start implementing Sun's
>    ieee_* calls.  Sun is, in my experience, the only vendor to
>    provide a decent interface to access the IEEE functionality.
>
>    Does Sun consider the specification of the ieee_* calls proprietary?
>    If not, maybe we could whip up a standard real quick :-)

Standardizing Sun's ieee_flags and ieee_handler interfaces would be
a big mistake, as observed by J. R. Hauser in "Handling Floating-
point Exceptions in Numeric Programs" (submitted to ACM Transactions
on Programming Languages and Systems).

I believe the FPCE proposes a much better interface for accessing
exception flags; I wish it had proposed an interface for something
like Kahan's scheme as well, so that system vendors would be able
to implement it with some assurance that it would be exercised.

Douglas M. Priest
(speaking only for myself)