From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Jul 3 21:43:24 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 1B4A5A4ADB2; Thu, 3 Jul 2014 21:43:24 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by www.open-std.org (Postfix) with ESMTP id C622235690D for ; Thu, 3 Jul 2014 21:43:21 +0200 (CEST) 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]:38805) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:nmm1) id 1X2mue-0004gv-Dt (Exim 4.82_3-c0e5623) (return-path ); Thu, 03 Jul 2014 20:43:20 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1X2mue-0002Jj-79 (Exim 4.72) (return-path ); Thu, 03 Jul 2014 20:43:20 +0100 Received: from [87.114.72.169] by old-webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 03 Jul 2014 20:43:20 +0100 Date: 03 Jul 2014 20:43:20 +0100 From: "N.M. Maclaren" To: Van.Snyder@jpl.nasa.gov Cc: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.5299) Did we intend to prohibit this? Message-ID: In-Reply-To: <20140703175703.0B23F3587E3@www.open-std.org> References: <20140702232501.1F2EE35877B@www.open-std.org> <20140703175703.0B23F3587E3@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 3 2014, Van Snyder wrote: >> >> >As far as I can tell from looking at 7.1.12, the only function from >> >IEEE_Arithmetic that's allowed in a constant expression is >> >IEEE_Selected_Real_Kind. >> > >> >Did we intend to prohibit all the others? >> > >> >Is there a problem with admitting the inquiry functions, and admitting >> >the others provided their arguments are constant expressions? >> >> One issue that would have to be considered is what requirements we would >> place on compile- and run-time options to control the modes. IEEE 754 >> remains a very assembler-level specification, does not map well even >> to C, and its arithmetic model is seriously incompatible with Fortran's. >> This is probably resolvable, but isn't just a matter of relaxing the >> restrictions. I, for one, lack the enthusiasm to tackle this. > >The reason this question arose was an attempt at the following: > > integer, parameter :: RK = kind(1.0e0) > real(rk), parameter :: SNaN = merge( > IEEE_Value(1.0_rk,IEEE_Signaling_NaN), & > & 0.0_rk, > IEEE_Support_DataType(1.0_rk) ) I am not denying there are use cases, without prejudice to my views on their numerical justifiability. >Are there at least a few functions from IEEE_Arithmetic, and the two >inquiry functions from IEEE_Exceptions, that we could admit into >constant expressions? The functions that don't depend upon modes, >especially the inquiry functions, ought not to be troublesome. Eh? Several of those more-or-less test either IEEE 754 or go-faster modes, and others are dependent on the run-time system. The only two that I would regard as almost always dependent solely on the actual representation are IEEE_SUPPORT_INF and IEEE_SUPPORT_NAN. In fact, the IEEE_IS_... ones are more likely to be usable at compile-time, but I wouldn't bet on them gving the same answer as at run-time. Indeed, IEEE 754 2008 allows modes to be associated with program blocks (see 4.1 and 8.2), and it is not uncommon to compile different parts of a program with different options. As I read it, Fortran allows that, but does not have the concept of constant functions that behave differently in different places. You may gather that I don't like the fancier features of IEEE 754, and think that IEEE 754 2008 is a major disimprovement over even IEEE 754 1984. Regards, Nick.