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

[Micki St. James]

IEEE 754 2008 has the format of a phone number, and my smartphone tried to make the call!

Micki St James

Sent from my iPhone

On Jul 3, 2014, at 12:43 PM, "N.M. Maclaren" <nmm1 at cam.ac.uk> 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) )
> 
> 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.
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3