Re: Exception handling
On 2013-08-20 09:26:25 +0200, Guillaume Melquiond wrote:
> Le 11/08/2013 03:54, Guillaume Melquiond a écrit :
> >Hi,
> >
> >The standard draft needs to say a few words about status, exceptions,
> >and their handling. I intend to work on it starting August 20th. If you
> >have comments regarding this matter, please contact me.
> >
> >I can think of three points that need wordings:
> >
> >1. Should interval operations signal things?
> >2. Can exceptional situations be encountered and how should this
> >information be conveyed to the user?
> >3. How does IEEE-1788 interact with IEEE-754 exception handling?
>
> There seems to have been some confusion around these questions, so let me
> clarify things a bit.
>
> Question 1. Obviously, I was not talking about everything that is already
> covered by decorations, but about other kinds of status. For instance, do
> people care about knowing whether bounds were computed exactly or with a
> bounded relative accuracy? My opinion is that people do not care, but it was
> important to ask.
I fear that this would be bad for performance. I'd let this for a
future revision of the standard. Implementations are free to provide
more information.
> Question 2. By "exceptions", I meant the IEEE-754 meaning, not the meaning
> you find in programing languages. In other words, exceptions encompass
> everything that is out of the scope of the natural behavior of a given
> function. For instance, what happens when an interval addition encounters an
> input that does not match the bit-pattern of an interval?
Dealing with invalid input (such as an invalid bit-pattern, i.e.
something that is meaningless for the type) could also be bad for
performance. But P1788 needs to specify the cases where valid input
in used in an invalid way (e.g. nums2interval(1,0) or the midpoint
of an empty interval).
> Question 3. This question at least got some answers. If I interpret them
> correctly, Ian and Michel expect operations returning an IEEE-754 result to
> also properly signal IEEE-754 exceptions. Vincent considers that whether
> IEEE-754 exceptions are signaled is out of the scope of the standard, while
> my opinion is that the standard should recommend that they are not.
Actually this depends on the function. If the function returns an
IEEE-754 number (in the context of a 754-conforming implementation),
I think that the implementation should signal the IEEE-754 exceptions
(to be specified). I'd say that other than that, this would be out of
the scope of the standard: library functions are already concerned by
similar problems (e.g. whether spurious exceptions can be generated),
and languages / OS / ABI's should already deal with them.
> Question 4. Should there be a NaI for bare intervals? There are two points
> to remember though. First, signaling NaNs almost got phased out from the
> IEEE-754 revision (and I believe they will not survive the next revision),
> and their bit-pattern is not even specified anyway; so any solution based on
> signaling NaNs might be short-sighted. Second, whichever representation is
> chosen, it will have a non-negligible cost for some interval operations
> implemented using IEEE-754 arithmetic.
I have a neutral point of view for NaI for bare intervals. There are
plenty of ways to represent "special intervals" without using signaling
NaNs. So, I don't think that the representation would be a problem. But
IMHO, P1788 shouldn't specify a representation for the first version of
the standard because we are not ready, unless there is a strong
consensus on some representation for 754-conforming types. Otherwise
there is a risk to do a wrong choice.
> Question 5. For the sake of bounded space/time, some operations like
> text2interval can be specified so that they always return a correct result
> (containment-wise) in the normal case, but fail to signal an exceptional
> case (e.g. inverted bounds). Assuming that we allow such a specification,
> the question is: should these potential failures be reported to the user?
> And if so, how?
I don't think this is really useful, but this may depend on the
function. Concerning the failure to detect inverted bounds (so that
a non-Empty interval is returned), this isn't much a problem because
containment is valid, and this would occur only in very specific cases.
In such cases, the user and/or the implementation probably knows what
to do.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)