Re: Exception handling

[Ian McIntosh <ianm@xxxxxxxxxx>]

For question 3, Vincent and I actually agree more than it may appear.

The reason I believe operations returning an IEEE 754 result should properly signal IEEE 754 exceptions is that while those are defined in the 1788 standard they are effectively extensions to 754 and have been described in this committee as things missing from 754, so they should obey 754 rules.  If 1788 says nothing about their exception behaviour then 754 should apply, and if 1788 does say anything it should just be that the 754 standard applies to operations on or producing 754 values.

- Ian McIntosh          IBM Canada Lab         Compiler Back End Support and Development


Ralph Baker Kearfott ---08/20/2013 09:20:24 AM---Guillaume, P-1788: Please see my interpolated comments.

From:	Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx>
To:	Ian McIntosh/Toronto/IBM@IBMCA
Date:	08/20/2013 09:20 AM
Subject:	Re: Exception handling

---

Guillaume, P-1788:

Please see my interpolated comments.

Best regards,

Baker

On 08/20/2013 02:26 AM, Guillaume Melquiond wrote:
> Le 11/08/2013 03:54, Guillaume Melquiond a écrit :
>> Hi,
>>
  .
  .
  .
> 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.
>

   As appropriate, I'd like to encourage someone to submit a motion
   to unambiguously clarify P-1788's sentiment concerning this issue.

> 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.
>

Thank you for the information.

> 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?
>

Should there be additional formal discussion, or is the issue now clear
enough to formulate a motion?


-- 

---------------------------------------------------------------
Ralph Baker Kearfott,   rbk@xxxxxxxxxxxxx   (337) 482-5346 (fax)
(337) 482-5270 (work)                     (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------