From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Sep 26 08:58:51 2012 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 9BB37356973; Wed, 26 Sep 2012 08:58:51 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10]) by www.open-std.org (Postfix) with ESMTP id AA07A3568FA for ; Wed, 26 Sep 2012 08:58:48 +0200 (CEST) Received: from Maru6 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105]) (authenticated bits=0) by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id q8Q6wgSA052110 for ; Wed, 26 Sep 2012 06:58:46 GMT (envelope-from malcolm@nag-j.co.jp) Message-ID: <97333DAD36594A66937AB7BC38AB25A9@Maru6> From: "Malcolm Cohen" To: "WG5" References: <501BB236.4000004@stfc.ac.uk><20120902160848.E514F35693A@www.open-std.org> <20120925072755.9745A3568FA@www.open-std.org> In-Reply-To: <20120925072755.9745A3568FA@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.4798) Fourth WG5 ballot on interpretations Date: Wed, 26 Sep 2012 15:58:43 +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.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Sender: owner-sc22wg5@open-std.org Precedence: bulk Nick Maclaren writes: >Upon checking on what this meant, I believe that the lists in tables >14.1 and 14.2 contain some errors. Specifically, I can see no reason >for IEEE_GET_ROUNDING MODE and IEEE_GET_UNDERFLOW MODE not to be pure >(but they aren't), It's possible that these were made non-pure to make them, or elemental procedures, easier to implement. That's not a very compelling reason, but it is not quite no reason. > but I can see good reasons for IEEE_SET_FLAG and >IEEE_SET_HALTING_MODE not to be (and they are). All of the functionality of IEEE_SET_FLAG that is visible outside the calling routine (the set flags in the called routine are merged into the flags of the calling routine) is already present in ordinary floating-point arithmetic. Therefore unless you wish to forbid X+Y inside an elemental procedure, there is absolutely no point in forbidding IEEE_SET_FLAG. Similarly, the effects of IEEE_SET_HALTING_MODE are not visible to the caller. Reasonable minds may differ on this one, since it runs counter to the possible rationale mentioned above for IEEE_GET_ROUNDING_MODE et al. But anyway, according to the Fortran standard, IEEE_SET_HALTING_MODE has no side-effect, because the model is that the halting mode is restored on return from the procedure. > However, even if true, >that is a matter for a separate interpretation. Please no. If you think it is a wart, it is a matter for a future revision. These are not a recent addition - far from it, they are a widely implemented part of F2003 and the original TR describing them was last century! I certainly see no actual error. Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.