From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Sep 5 10:59:49 2013 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 7A444356FDB; Thu, 5 Sep 2013 10:59:49 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from ppsw-42.csi.cam.ac.uk (ppsw-mx-f.csi.cam.ac.uk [131.111.8.149]) by www.open-std.org (Postfix) with ESMTP id F119C3568B7 for ; Thu, 5 Sep 2013 10:59:35 +0200 (CEST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:39223) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:nmm1) id 1VHVPa-0006EJ-8w (Exim 4.80_167-5a66dd3) for sc22wg5@open-std.org (return-path ); Thu, 05 Sep 2013 09:59:34 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1VHVPa-00012K-Nh (Exim 4.72) for sc22wg5@open-std.org (return-path ); Thu, 05 Sep 2013 09:59:34 +0100 Received: from [146.90.6.182] by old-webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 05 Sep 2013 09:59:34 +0100 Date: 05 Sep 2013 09:59:34 +0100 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.5086) WG5 ballot N1988 Message-ID: In-Reply-To: <20130905030921.4A63535725B@www.open-std.org> References: <20130905024923.1869835725C@www.open-std.org> <20130905030921.4A63535725B@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 I missed the deadline, due to chaos here, and this is a mere comment, anyway. Sorry about that. The executive summary is that I sympathise with Robert's position, but don't agree that change to the interpretation is needed. On Sep 5 2013, Malcolm Cohen wrote: > >>For example, consider the case of an Intel 386 CPU with a 387 >>numeric coprocessor. A Fortran processor for such a system might >>implement the statement >> >> X = X/Y >> >>where X and Y are represented in the double-precision format of >>IEC 60559:1989 by extending the values of X and Y to extended >>precision performing the division and converting the result back >>to double-precision. The resulting division would not always >>produce the result required by IEC 60559:1989. It would also >>not signal exceptions as required by IEC 60559:1989. > > It obviously does signal as required for IEEE_DIVIDE_BY_ZERO. It also > signals IEEE_OVERFLOW correctly on assignment to X. > > The Fortran standard permits evaluating an expression in a higher > precision under the rules of mathematical equivalence; that's how we > avoided the Java trap (which was a performance trap, not an IEEE > conformance trap). I have used systems that would expose the discrepancy that Robert describes, though they were a LOT more unusual than his example. However, hard cases make bad law, and one cannot close every loophole when matching IEEE 754 to all of the sort-of IEEE 754 hardware and usage models that currently exist, let alone have existed or might exist. If one wants to resolve this properly, one would need a rigorous model for 'Fortran IEEE 754', which would have to be incompatible with both versions of IEEE 754, because they are not entirely self-consistent. Count me out of any such project! > I am boggled by the apparent claim that the very chip that the IEEE > standard was written to describe, the Intel x87, does not conform to the > IEEE standard. I am not. The match is between IEEE 754 (1985) and a particular set if uses of the Intel x87, and it always has been possible to use the x87 in ways incompatible with IEEE 754. But I don't see why that is relevant to what Fortran says - it always HAS forbidden some possible uses of computer hardware. Regards, Nick Maclaren.