(j3.2006) (SC22WG5.4800) [ukfortran] Fourth WG5 ballot on interpretations

[Malcolm Cohen]

Nick Maclaren writes:
>Upon checking on what this meant, I believe that the lists in tables
>14.1 and 14.2 contain some errors.  Specifically, I can see no reason
>for IEEE_GET_ROUNDING MODE and IEEE_GET_UNDERFLOW MODE not to be pure
>(but they aren't),

It's possible that these were made non-pure to make them, or elemental 
procedures, easier to implement.  That's not a very compelling reason, but it is 
not quite no reason.

> but I can see good reasons for IEEE_SET_FLAG and
>IEEE_SET_HALTING_MODE not to be (and they are).

All of the functionality of IEEE_SET_FLAG that is visible outside the calling 
routine (the set flags in the called routine are merged into the flags of the 
calling routine) is already present in ordinary floating-point arithmetic. 
Therefore unless you wish to forbid X+Y inside an elemental procedure, there is 
absolutely no point in forbidding IEEE_SET_FLAG.

Similarly, the effects of IEEE_SET_HALTING_MODE are not visible to the caller. 
Reasonable minds may differ on this one, since it runs counter to the possible 
rationale mentioned above for IEEE_GET_ROUNDING_MODE et al.

But anyway, according to the Fortran standard, IEEE_SET_HALTING_MODE has no 
side-effect, because the model is that the halting mode is restored on return 
from the procedure.

>  However, even if true,
>that is a matter for a separate interpretation.

Please no.  If you think it is a wart, it is a matter for a future revision. 
These are not a recent addition - far from it, they are a widely implemented 
part of F2003 and the original TR describing them was last century!  I certainly 
see no actual error.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.