From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Aug 31 14:37:22 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 3EEFC3569AC; Fri, 31 Aug 2012 14:37:22 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by www.open-std.org (Postfix) with ESMTP id B33653569A7 for ; Fri, 31 Aug 2012 14:37:21 +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]:47875) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:nmm1) id 1T7QTQ-0005L5-SH (Exim 4.72) (return-path ); Fri, 31 Aug 2012 13:37:20 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1T7QTQ-0002su-O1 (Exim 4.72) (return-path ); Fri, 31 Aug 2012 13:37:20 +0100 Received: from [91.125.224.214] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 31 Aug 2012 13:37:20 +0100 Date: 31 Aug 2012 13:37:20 +0100 From: "N.M. Maclaren" To: "Malcolm Cohen esq." , sc22wg5 Subject: Re: [ukfortran] (SC22WG5.4748) (j3.2006) Comments on comments on Ballot 3 on Fortran 2008 interpretations Message-ID: In-Reply-To: <20120831103538.81AB83569A7@www.open-std.org> References: <20120804040444.460F63568DA@www.open-std.org><20120806212738.70CE53568F2@www.open-std.org><20120807182349.20E743568F8@www.open-std.org><20120818115719.C0FDD35691B@www.open-std.org><20120831064101.E6D09356925@www.open-std.org> <20120831093120.3E91535699F@www.open-std.org> <20120831103538.81AB83569A7@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 Aug 31 2012, Malcolm Cohen esq. wrote: >I think this will bounce from the J3/WG5 list, as I am sending via my >hotmail account ... for technical reasons I cannot send from my work email >when I am at home (my ISP blocks that connection). If you want to discuss >further on the public list, please first forward my whole message to the >list... It got through to the SC22WG5 list, but I will copy the whole section that is relevant to my points on F03/0065. >I wrote: >> The clear meaning of "all possible values" is "all values that are >> possible". Otherwise we'd have simply written "mathematically equivalent" >> if that is what we meant. > >Nick wrote: >>I am sorry, but that does not make sense. > >Yes it does. > >> There is a continuum from >>mathematically and computationally different values down to ones that >>have different bit-patterns but represent the same number and cannot be >>distinguished by any numeric or quasi-numeric operation specified in >>either the Fortran or C standards. > >That makes zero difference in context. > >> If you were to say that the clear >>meaning of "all possible values" is "all values that are distinguishable >>using defined operations", I might agree. > >That makes zero difference in context. > >>But that STILL doesn't specify it precisely. We had this argument at >>length in WG14, with regard to pointer equivalence, but we failed to >>resolve it and the C standard was left "constructively ambiguous". >>But let's stick with arithmetic values, which are much simpler, but >>still fiendishly complicated. > >ABSOLUTELY NOT. > >>Inter alia, are two values different > >That is not the bloody question. > >The question is whether the RELATIONAL OPERATION returns the same answers. > >There is NO AMBIGUITY HERE. All possible values is all possible values! We are seriously at cross-purposes. To try to reduce confusion, my objection to this interpretation is NOT that compilers should be allowed to break 7.1.5.5.2 paragraph 2, nor that the erroneous example should be restored. I fully agree that this interpretation is correct in that conclusion, and do NOT want to reverse it. My objection is on the grounds that this interpretation sweeps this very nasty issue further under the carpet, and thus (potentially) makes it harder to resolve in the future. And, yes, I have seen it cause trouble even on modern systems. With hindsight, I made a mistake in not spending a lot more time in explaining my point and in thinking of wording that I would be happy with. I apologise for that. Many of us will remember why Fortran 66 and 77 allowed I .GT. J to be evaluated as J-I .LT. 0, but I think that it was an oversight not to remove it in Fortran 90, as such machines are long gone. But only THAT issue has gone away - not the problem in all its arcane horror. Let's take a specific example. IEEE 754-2008 defines two zeroes, and cohorts and more for decimal numbers, so you can have two values that are numerically equal but are not the same; IBM System/370 had the same property. Implementations of both of those are permitted to have numbers that are non-zero in memory but become zero when they are operated on - and that can include loading them into a register in order to compare them! Also, I have used at least one language where A <= B, A >= B and A /= B could all be true, simultaneously - I can't remember which it was, but this aspect stuck in my mind, for obvious reasons! The point was that the first two tested the numeric values, but the last tested for identical representations (and that was semantically significant, as it is with IEEE 754 zeroes and cohorts). The point is that, except for the most perverse implementations, there is no ambiguity about whether two values are the same once you have decided whether a value is a number or a representation. But, until then, it is an open question. For the record, IEEE 754 answers it, but only in part (e.g. not the becoming zero on being loaded aspect). Regards, Nick Maclaren.