| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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.
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?
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.
There are also two new questions that have surfaced in the course of this discussion (partly in private correspondences, so do not be alarmed if that does not ring a bell).
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.
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?
Best regards, Guillaume