Re: Exception handling
Ian McIntosh, on Guillaume Melquiond's remarks:
> For operations which produce an IEEE 754 floating point result instead
> of an IEEE 1788 interval result, standard 754 floating point exception
> handling should apply; for example, a result that needs rounding could
> signal inexact, or an operation like dot product could signal overflow.
Exactly what I was going to say. On the other hand, it must also be the
case that actual Interval Arithmetic is allowed to leave the 754 state
in an unpredictable state. I think it would be onerous to require that
each interval operation must save and restore the 754 status flags. It
should however preserve the 754 rounding direction of the current block
of execution -- though it might be useful to have a compile-time pragma
that provides the programmer some control. Such a mechanism already
exists for C, based on <fenv.h> and #pragma STDC FENV_ACCESS on/off, to
declare whether the program depends on maintaining IEEE 754 flags, or not.
Some of this might be an implementation choice, in which case 1788 should
state the documentation requirements.
For bare intervals, implementations might offer a choice of trapping
exceptions, but generally it seems to be that the default interval
result could be NaI, Entire or Empty, depending on the operation --
and clearly the standard needs to define these situations.
That leaves constructors and I/O operations in general. For I/O, the
standard should describe the conceptual strings, leaving details such
as whether an input is a stream or not, or whether the output might
have to be truncated and hence end up as unusable for input, to the
implementation. If the environment supports trapping exceptions,
this should/could be exploited. If not -- we should define at least
a bare-interval NaI or two, with defined propagation rules. We should
avoid old mistakes, such as 754 never having made clear what the purpose
of Signalling NaN should be.
Michel.
---Sent: 2013-08-12 18:45:40 UTC