From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Oct 28 11:25:57 2014 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 3D129357257; Tue, 28 Oct 2014 11:25:57 +0100 (CET) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1893 seconds by postgrey-1.34 at www5.open-std.org; Tue, 28 Oct 2014 11:25:56 CET Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by www.open-std.org (Postfix) with ESMTP id 8B4A83566B5 for ; Tue, 28 Oct 2014 11:25:55 +0100 (CET) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:55429) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:nmm1) id 1Xj3Tn-00034p-qb (Exim 4.82_3-c0e5623) (return-path ); Tue, 28 Oct 2014 09:54:19 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1Xj3Tn-00085G-7g (Exim 4.72) (return-path ); Tue, 28 Oct 2014 09:54:19 +0000 Received: from [87.115.158.100] by old-webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 28 Oct 2014 09:54:19 +0000 Date: 28 Oct 2014 09:54:19 +0000 From: "N.M. Maclaren" To: Malcolm Cohen Cc: WG5 Subject: Re: [ukfortran] (SC22WG5.5351) From a colleague Message-ID: In-Reply-To: <20141028005636.2C7383587BC@www.open-std.org> References: <20141027201943.09E1A3582F9@www.open-std.org> <20141028005636.2C7383587BC@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 Oct 28 2014, Malcolm Cohen wrote: > >>My colleague wrote: >> >> I've just learned that at least some compilers will no longer >> support the arithmetic IF statement. > > Since that is currently standard-conforming, such a compiler is also not > standard-conforming. Compilers that ignore the standard are (rather > obviously) not going to be affected by whatever *we* decide! Well, yes, and I am NOT arguing in favour of retaining the arithmetic IF, because it is a piece of nasty historical syntax. There is nothing wrong with a 3-branch IF, when done right (as in Algol 68), but the arithmetic IF is really a sort of computed GOTO. > There is, indeed, no good answer as to what this statement should do if > the value in question is a NaN. Which is why you should remove it from > your program. And why it should be removed from the standard. And the only good answer to what a logical IF should do if the operand involves a NaN is to throw an exception. The rule that comparisons on NaNs always deliver False is every bit as horrible as (say) defining an arithmetic IF to take the zero branch on a NaN. Which would even have precedent (Java real=>integer conversion)! > Anyway, if NaN's are not an issue (either because you've proved some > difficult mathematical theorems about your code, you have some > sophisticated error handling mechanism, you are running with the Invalid > Exception trap enabled, or you don't care if the bridge falls down/plane > falls out of the sky), it is trivial to replace arithmetic IF with newer > alternatives. And, if you think that it is going to help you with IFs and NaNs, you are living in cloud cuckoo land. As I have said before, I have investigated this more than once, and the IEEE 754 assumptions don't match either human or compiler behaviour. > After all, if you continue to use arithmetic IF, that's what the compiler > is effectively going to do "under the covers". There are no single > machine instructions that branch to three different labels depending on a > floating-point value. Of course this means that NaN will do different > (and maybe impossible) things on different machines or with different > compiler options. Now THAT would be a problem! At least if you replace it > with 1-3 logical IF+GOTO yourself it will do the same thing. No, it won't. For a start, NaN is normally the result of an undefined calculation (so all bets are off), so you can get 'impossible' results for ANY code. Secondly, even when they aren't, Fortran has steadfastly refused to adopt the ghastly IEEE 754 viewpoint that compilers are simply macro generators. And Fortran 2008 makes it VERY clear (in 13.7.1p2 and elsewhere) that, under most circumstances, compilers are allowed to optimise on the basis of there being no NaNs. Yes, there is an ambiguity if IEEE_ARITHMETIC is accessible, in that it might override wording like (say) Fortran 2008 7.1.5.2.4 and 13.4. Regards, Nick.