From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Aug 26 05:32: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 54A453568CA; Fri, 26 Aug 2011 05:32:25 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 928 seconds by postgrey-1.33 at www5.open-std.org; Fri, 26 Aug 2011 05:32:23 CEST Received: from ns.nag-j.co.jp (218-42-159-107.cust.bit-drive.ne.jp [218.42.159.107]) by www.open-std.org (Postfix) with ESMTP id 7E92D3568C5 for ; Fri, 26 Aug 2011 05:32:23 +0200 (CEST) Received: from 218-42-159-108.cust.bit-drive.ne.jp ([218.42.159.108] helo=Maru6) by ns.nag-j.co.jp with smtp (Exim 4.50) id 1QwmuQ-0005xg-A3 for sc22wg5@open-std.org; Fri, 26 Aug 2011 12:16:42 +0900 Message-ID: <452AD9DD2AB34C97BD9B86540AB957BF@Maru6> From: "Malcolm Cohen" To: References: <20110824091526.E590E3568C2@www.open-std.org> In-Reply-To: <20110824091526.E590E3568C2@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.4517) interpretation F03/0030 Date: Fri, 26 Aug 2011 12:16:48 +0900 Organization: =?UTF-8?B?5pel5pysTkFH?= MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 Sender: owner-sc22wg5@open-std.org Precedence: bulk BTW, please reply to WG5 (and preferably not to both J3 and WG5 as J3 is a subset of WG5). Robert Corbett claimed: >The answer and edits provided for F03/0030 are wrong. >They are wrong in general and in specifics. The answer and edits provided for F03/0030 are correct. Your claims are wrong. They are wrong in general and specifics. >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. That is correct. >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). Actually F2008 as published ***NEVER*** requires IEEE_OVERFLOW to be raised. That is not an argument in favour of keeping the current definition! With the edits provided, it now requires IEEE_OVERFLOW to be raised when IEC 60559 so requires. I hope we are all agreed that Fortran 2008's definition of IEEE_OVERFLOW is wrong in the first place! The removal of unnecessary processor dependencies by the new definition is a good thing, not a bad one. ASIDE: I don't know how we managed to omit all of those from Annex A - fortunately the edits insert correct notes here. >The intent of the proposed edits might be to extend >the requirements presented in the first paragraph of >Clause 14.9. The edits do not change the result value of the operation. And the first paragraph of 14.9 has never been the only requirement on arithmetic in Fortran! > If so, it is done in a manner that is >certain to confuse readers. Apparently at least one. > Furthermore, the functions >IEEE_SUPPORT_DIVIDE and IEEE_SUPPORT_INF will be made >pointless by such extensions. Not so. The edits do not say anything about the result value, they merely make the operation of IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO follow the rules of (the now superceded) IEC 60559 for numbers with IEEE_SUPPORT_DATATYPE true. The previous text required IEEE_DIVIDE_BY_ZERO to be raised in situations where IEC 60559 forbade it, and implied (though it did not actually require it with a sufficiently nitpicky reading) that IEEE_OVERFLOW would be raised in situations where IEC 60559 forbade it. IEEE_SUPPORT_INF did not previously affect the operation of IEEE_OVERFLOW, and I think that it still does not directly affect the operation of IEEE_OVERFLOW. The previous definition of IEEE_DIVIDE_BY_ZERO was certainly COMPLETELY UNAFFECTED by IEEE_SUPPORT_DIVIDE. The new definition of IEEE_DIVIDE_BY ZERO correctly remains completely unaffected by IEEE_SUPPORT_DIVIDE, it has merely been corrected not to be raised in the situations where IEC 60559 forbids it to be raised. (Actually the new definition greatly weakens the requirements on a non-IEC 60559 processor, but that is a horse of a different colour.) Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.