From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Jul 27 11:35:34 2019 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 851D4358B84; Sat, 27 Jul 2019 11:35:34 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.open-std.org (Postfix) with ESMTP id 5192B356840 for ; Sat, 27 Jul 2019 11:35:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cam.ac.uk; s=20180806.ppsw; h=Sender:Content-Type:Mime-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ob/WFHorJ/m4ixsPKpZ3ajxn56yc2zLgjTQt6w2CH40=; b=jOZK49bSkPvAYAv0Nh10x7PXC9 H0D4RaKyOmuUMIsqx9mr2330wjEKNoqlOeXF8gGLtHipBhhpCNse5vvWUae8qSR+n9+pPRENUR7Fc j5ilAkjgAIyDOwU8pBeRY0jefAPPXUfVb3BXn6gDHPXYQBOmmDiVAlE3PZDqxRxULiW0=; X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:51554) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:nmm1) id 1hrJ6x-001D6A-fd (Exim 4.92.1) (return-path ); Sat, 27 Jul 2019 10:35:31 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1hrJ6x-00068X-T2 (Exim 4.92) (return-path ); Sat, 27 Jul 2019 10:35:31 +0100 Received: from [51.9.71.185] by old-webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 27 Jul 2019 10:35:31 +0100 Date: 27 Jul 2019 10:35:31 +0100 From: "N.M. Maclaren" To: van.snyder@jpl.nasa.gov Cc: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.6116) [EXTERNAL] Re: Two things from IFIP WG 2.5 meeting Message-ID: In-Reply-To: <20190726172038.9A3DD358B76@www.open-std.org> References: <20190726015634.E052D35860C@www.open-std.org> <20190726172038.9A3DD358B76@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 Jul 26 2019, Van Snyder wrote: >>For binary128, 49,536 bits would be required, but it was not requested >for IEEE 1788. That's what I meant. Sorry about being confusing. Yes, I agree that it's affordable to implement under many circumstances, but a standard should NOT consider just the easy circumstances. And a specification that is feasible for 64 bits but not 128 bits is dubiously within the spirit of Fortran. As a slight aside, there are other approaches that give most of the benefit for much less cost. One is (true) probabilistic rounding during the accumulation, which may be heretical but has a lot of technical advantages. The relevance is the question of whether it is reasonable to exclude other approaches by mandating one particular one? >If you want papers that describe the problem, I can get them. Siegfried >Rump gave very nice demonstrations of the problem at the WG 2.5 meeting >in Sydney last year, and at ICIAM in Valencia last week (and many other >times when I was not in attendance). I should be interested if you have any that demonstrate it is a critical issue in realistic analyses. All of the ones I have seen were implausible, to put it mildly. Yes, some were of academic interest, but I never saw a case that this makes the difference between a complete, practical analysis being valid and not being. As I tried to say, being perfectionist in one respect rarely helps with complete problems, which are usual complex. >This is a red herring. We are discussing the Fortran standard, after >all, not the C or C++ or 754 standard. BTW, Kahan did discuss the >80-bit vs. 64-bit problem in the paper attached to the original message. Regrettably, it is not, as I can witness from way back when. Intel is neither the only nor the first system to have multiple arithmetics, and I first encountered this problem before using either it or C. I may have missed something, but I believe that Fortran still allows an expression to be calculated using any suitable method, subject to parentheses. And my point is that that is not enough! You must constrain a compiler to use exactly the same precision (and compatible arithmetic) in ALL places. You will remember when I raised the issue of what IEEE 754 said about the evaluation of expressions, and asked whether Fortran should honour that. The vast majority of the meeting was adamantly against it. To enable such code to be conforming, reliable and portable, Fortran would have at least to provide a mechanism for such an evaluation mode. C does, in theory. Regards, Nick Maclaren.