From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Sep 14 11:07:11 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 54A10356936; Fri, 14 Sep 2012 11:07:11 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by www.open-std.org (Postfix) with ESMTP id C7B5F35688D for ; Fri, 14 Sep 2012 11:07:10 +0200 (CEST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:54351) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:nmm1) id 1TCRrh-0002dh-XD (Exim 4.72) (return-path ); Fri, 14 Sep 2012 10:07:09 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1TCRrh-00037H-8v (Exim 4.72) (return-path ); Fri, 14 Sep 2012 10:07:09 +0100 Received: from [87.112.138.201] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 14 Sep 2012 10:07:09 +0100 Date: 14 Sep 2012 10:07:09 +0100 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.4773) [Letter ballot 3 on Fortran 2008interpretations] Message-ID: In-Reply-To: <20120914084826.3E660356935@www.open-std.org> References: <20120914011923.8BC2F356931@www.open-std.org> <20120914084826.3E660356935@www.open-std.org> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Sep 14 2012, Malcolm Cohen wrote: >Van Snyder wrote: >>My most fundamental objection to the interpretation is that it is >>inconsistent with the requirements of 4.1.2, 4.2, and 13.7.2. According >>to 4.1.2 and 4.2, A type is characterized by a kind type parameter. The >>type and kind type parameter value together specify a set of valid >>values. According to 13.7.2, a function is required to return a value >>that is a member of the set of valid values for the type and kind of its >>result. The interpretation violates this requirement. > > That is simply not the case. That is not what 13.7.2 says. either before > or after other interps changed that wording. I am fairly good at seeing multiple interpretations, but I must say that I have some difficulty finding one compatible with Van's. However, I do find it hard to be sure EXACTLY what 13.7.2 does specify. > Furthermore, even if it did, such an interpretation of the "valid values" > wording would not result in "better answers" but (in the vast majority of > cases) worse answers, quite apart from the effects on optimisation. I agree. But this is another example of the concerns that some of us have about the increasing problems that the concept of "what is a value?" is causing. Inter alia, this is because the prevailing views of what both computational reals and floating-point are have changed drastically since 1977, but without the main standards (including IEEE 754) defining their abstract models precisely enough to resolve such questions. The LIA-x standards did, but unfortunately lost the politics. In my view, these issues are too pervasive and difficult to be solved by interpretations, but do need addressing. And, yes, I accept that I had better write a proper paper if I want that done :-( Regards, Nick Maclaren.