From Keith.Bierman@Eng.Sun.COM  Mon Sep 16 07:06:48 1996
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id HAA04953 for <sc22wg5@dkuug.dk>; Mon, 16 Sep 1996 07:06:47 +0200
Received: by mercury.Sun.COM (Sun.COM)
	id WAA11845; Sun, 15 Sep 1996 22:06:10 -0700
Received: from chiba.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id WAA23358; Sun, 15 Sep 1996 22:06:07 -0700
Received: from chiba by chiba.eng.sun.com (SMI-8.6/SMI-SVR4)
	id WAA25250; Sun, 15 Sep 1996 22:06:06 -0700
Message-Id: <199609160506.WAA25250@chiba.eng.sun.com>
To: Miles.Ellis@etrc.ox.ac.uk (Miles Ellis)
cc: sc22wg5 <sc22wg5@dkuug.dk>
Subject: Re: (SC22WG5.1163) Review of N1225 - Floating-Point Exception Handling TR 
In-reply-to: Your message of "Wed, 21 Aug 1996 18:29:50 BST."
             <199608211733.TAA07021@dkuug.dk> 
Date: Sun, 15 Sep 1996 22:06:05 -0700
From: Keith Bierman QED <Keith.Bierman@Eng.Sun.COM>


With regret I must vote no on forwarding the document as it stands. 

The most substantive point was raised by Robert P. Corbett:

	The IEEE floating point standard specifies that constants
	be evaluated in accordance with the rounding mode in effect
	(forcing all constants to be evaluated at runtime). This
	would appear to conflict with the Fortran requirement in
	4.1.2, that all literal constants that have the same form
	have the same value.

I note that I know of no *implementations* that faithfully follow the
IEEE standard in this area. I am disinclined to suggest that we make
Fortran follow it. But some text that makes it clear that constants
are *not* evaluated (or at least that it is processor dependent) in
this fashion (and that this is an area of non-IEEE compliance, perhaps
in a note). This is the basis of my vote, and I would happily change
to a yes after it is addressed.

Some other internal reviewers raised some questions, which if not
dealt with might eventually grow into interpretation requests (if not
from them, from like minded individuals elsewhere).

1) In example 4 we have "use only ieee_underflow_flag" but
   the comments talk about overflow. Is this consistent?
   If so, some explanatory text would be appreciated.

2) One commenter noticed (and was quite happy with the automatic
   flag setting) but wanted to know what was the status of
   rounding modes. Are they set to a particular state on routine
   entry and exit? For consistency we might want to have them
   follow the other flags, or we might prefer to make it easier
   to write things such as interval arithmetic (or at least the
   sort of ersatz things people sometimes do to test for numerical
   problems such as setting the rounding mode up (then down) doing
   the entire calculation both ways and comparing).

   In any event, we should make the situation clear.

3) One commenter felt that it was unclear that the case of 
   a matrix A (with IEEE handling turned on), what happens
   if during the evaluation of sin(A) exceptions occur?
   I thought it was "obvious" but is there some way we could
   make the text clearer?
	
I believe that the editor can easily address these issues.