[J3] defining a parameter to be signaling NaN?

[Malcolm Cohen]

The standard does note that the types and procedures in the intrinsic IEEE modules are not themselves intrinsic, and thus the expression is not suitable for defining a PARAMETER.





First, is this explanation correct?

 

Yes.

 

Second, presuming that the explanation is correct, was this our intent?

 

Yes.

 

                Is there a reasonably way to set a parameter to a signaling nan value?

 

No.

 

I do not see a technical reason to prohibit using IEEE_VALUE in a constant expression.

 

We did not want to require operations on IEEE exceptional values at compile time, for a number of reasons.

 

1.	These normally indicate an error or a violation of the standard; requiring the processor to handle NaN/INF as a result of IEEE_VALUE would be inconsistent with treating NaN/INF as a compile-time error when it is a result of an invalid operation or overflow in a constant expression.
2.	It precludes, or at least makes significantly harder, various implementation techniques.  (Like using C as a portable assembler, or using a processor on an operating system that supports “stopping” IEEE arithmetic but not non-stop [IIRC early MacOSX was like that].)  Compiler options to initialise variables to NaN do not suffer from this problem.
3.	Manually setting all variables to NaN actually makes it harder for the processor to detect uninitialised variables, not easier.  (Like, because they are no longer uninitialised!)
4.	Manual setting to NaN is far more tiresome than using a processor’s options, and is likely to miss automatic variables and dynamically-allocated variables.  (Maybe some processors’ options also miss those, but not all.)
5.	With many processors the default execution environment is “non-trapping i.e. non-stop arithmetic with no exception report on termination”; manually setting variables to NaN in such an environment is self-defeating unless your program logic is IEEE-exception-safe with regards to IF conditions (a vanishingly small number of programs are safe in this respect).
6.	On processors that do not fully conform to IEEE, programs that use the IEEE modules can frequently work correctly.  Even on machines with no IEEE support, they can often work.  But this is not the case if you are performing operations on IEEE exceptional values in constant expressions, so such programs would not be portable anyway.

 

Depending on where you’re sitting/standing, for many people the above considerations made the benefit/cost ratio either too small for serious consideration, or even negative.

 

The world has certainly moved on since this decision was taken, but IMO the above points do still have some validity.

 

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20180523/9f9d113e/attachment.html>