Re: Exception handling
Michel, Guillaume, P1788
On 2013 Aug 12, at 19:01, Michel Hack wrote:
> 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.
...
> 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.
I agree entirely.
> 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.
Now this is interesting. We seem to have gone from a widespread hostility, a year or two ago, to NaI even for decorated intervals -- to general acquiescence in having decorated-interval NaI, and strong support for it from some -- and now Michel supports a bare-interval NaI (bNaI) "or two".
I have no objection in principle. I suggest Michel & Guillaume explore the idea, and propose a motion if they agree it is a good one.
I suppose the main use is in constructor calls, where "Otherwise the call fails and the result is Empty" can be changed to "Otherwise the call fails and the result is bNaI", which is more secure.
Some questions:
- How much standard-text would need changing? What new operations are required if any?
- With the deadline looming, have we the time to make such a change?
- For the commonest interval types, inf-sup based on a 754 number format, what would be a sensible Level 3 representation of bNaI and Empty jointly, that slows down arithmetic operations (done in software) as little as possible?
I guess that the effort to make such a change is modest, but would like to see it estimated.
John