From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Jul 3 19:57:02 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 D1D913587E0; Thu, 3 Jul 2014 19:57:02 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by www.open-std.org (Postfix) with ESMTP id 3EECB3587C5 for ; Thu, 3 Jul 2014 19:56:56 +0200 (CEST) Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s63HurOp021521 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Thu, 3 Jul 2014 10:56:55 -0700 Subject: Re: [ukfortran] (SC22WG5.5294) Did we intend to prohibit this? From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: sc22wg5 In-Reply-To: References: <20140702232501.1F2EE35877B@www.open-std.org> Content-Type: text/plain; charset="ISO-8859-1" Organization: Yes Date: Thu, 03 Jul 2014 10:56:53 -0700 Message-ID: <1404410213.10299.161.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-30.el6) Content-Transfer-Encoding: 7bit X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk On Thu, 2014-07-03 at 11:14 +0100, N.M. Maclaren wrote: > 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) ) 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. While looking at this, I noticed that IEEE_Is_Finite appears twice in Table 14.1. Is there a reason for this, or is it just a typo? > Regards, > Nick. >