(j3.2006) (SC22WG5.5300) [ukfortran] Did we intend to prohibit this?

[N.M. Maclaren]

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.