From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Aug 24 11:15:25 2011 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id D15BA3568D5; Wed, 24 Aug 2011 11:15:25 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 2204 seconds by postgrey-1.33 at www5.open-std.org; Wed, 24 Aug 2011 11:15:24 CEST Received: from rcsinet14.oracle.com (rcsinet14.oracle.com [148.87.113.126]) by www.open-std.org (Postfix) with ESMTP id 03A5E35689A for ; Wed, 24 Aug 2011 11:15:24 +0200 (CEST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet14.oracle.com (Switch-3.4.4/Switch-3.4.1) with ESMTP id p7O8cfmS026239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 24 Aug 2011 08:38:41 GMT Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7O8cZSR019074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Aug 2011 08:38:37 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7O8cXFW009275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 08:38:34 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7O8cRYx032241; Wed, 24 Aug 2011 03:38:27 -0500 Received: from [10.132.140.77] (/10.132.140.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Aug 2011 01:38:27 -0700 Message-ID: <4E54B7BA.7020601@oracle.com> Date: Wed, 24 Aug 2011 01:35:06 -0700 From: Robert Corbett Reply-To: robert.corbett@oracle.com Organization: Oracle America User-Agent: Thunderbird 2.0.0.19 (X11/20090218) MIME-Version: 1.0 To: sc22wg5@open-std.org CC: j3@j3-fortran.org Subject: interpretation F03/0030 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090201.4E54B88E.0012,ss=1,re=3.899,fgs=0 Sender: owner-sc22wg5@open-std.org Precedence: bulk The answer and edits provided for F03/0030 are wrong. They are wrong in general and in specifics. I explained how they are wrong in the comments I included with my vote on J3 ballot #22. Since F03/0030 passed the ballot, my arguments obviously were not persuasive. Nonetheless, I shall try again. If anyone sees an error in what I claim, please let me know what my mistake is. The proposed edit for Clause 14.3, paragraph 1, of 10-007r1 includes the text IEEE_OVERFLOW occurs in an intrinsic real addition, subtraction, multiplication, division, or conversion by the intrinsic function REAL, as specified by IEC 60559:1989 if IEEE_SUPPORT_DATATYPE is true for the result of the operation or conversion, and as determined by the processor if IEEE_SUPPORT_DATATYPE for the result is not true. The specification of the result value of the function IEEE_SUPPORT_DATATYPE given in paragraph 5 of Clause 14.11.24 is Result Value. The result has the value true if the processor supports IEEE arithmetic for all reals (X does not appear) or for real variables of the same kind type parameter as X; otherwise, it has the value false. Here, support is as defined in the first paragraph of 14.9. The first paragraph of Clause 14.9 states The inquiry function IEEE_SUPPORT_DATATYPE can be used to inquire whether IEEE arithmetic is supported for a particular kind of real. Complete conformance with IEC 60559:1989 is not required, but o the normal numbers shall be exactly those of an IEC 60559:1989 floating- point format, o for at least one rounding mode, the intrinsic operations of addition, subtraction, and multiplication shall conform whenever the operands and result specified by IEC 60559:1989 are normal numbers, o the IEEE operation rem shall be provided by the function IEEE_REM, and o the IEEE functions copysign, scalb, logb, nextafter, and unordered shall be provided by the functions IEEE_COPY_SIGN, IEEE_SCALB, IEEE_LOGB, IEEE_NEXT_AFTER, and IEEE_UNORDERED, respectively, for that kind of real. Thus, even if IEEE_SUPPORT_DATATYPE is true for a kind of real, the intrinsic operations division and conversion by the intrinsic function REAL are not required to conform to IEC 60559:1989. Furthermore, because the result of an operation that overflows in IEEE arithmetic is not a normal number, Fortran 2008 does not require IEEE_OVERFLOW to occur for addition, subtraction, and multiplication if IEEE_SUPPORT_DATATYPE is true (see the text at the end of the second item of the list above). The intent of the proposed edits might be to extend the requirements presented in the first paragraph of Clause 14.9. If so, it is done in a manner that is certain to confuse readers. Furthermore, the functions IEEE_SUPPORT_DIVIDE and IEEE_SUPPORT_INF will be made pointless by such extensions. Robert Corbett