(j3.2006) (SC22WG5.5357) [ukfortran] From a colleague

[N.M. Maclaren]

On Oct 29 2014, Malcolm Cohen wrote:
>
>>> Anyway, if NaN's are not an issue (either because you've proved some
>>> difficult mathematical theorems about your code, you have some
>>> sophisticated error handling mechanism, you are running with the Invalid
>>> Exception trap enabled, or you don't care if the bridge falls down/plane
>>> falls out of the sky), it is trivial to replace arithmetic IF with newer
>>> alternatives.
>
>Nick Maclaren replies:
>>And, if you think that it is going to help you with IFs and NaNs, you are
>>living in cloud cuckoo land.
>
>That is not acceptable.

I apologise for causing offence, which was not intended.

Obviously, the following code fragments have equivalent problems with NaNs:

    IF (x) 123,456,789

    IF (x < 0.0) GOTO 123
    IF (x > 0.0) GOTO 789
    GOTO 456

I am getting increasing tired of the polemic in favour of IEEE 754's
handling of NaNs in conditionals.  As I said, I have investigated it
more than once, and found clear evidence was that it was little more than
a trap for the unwary (i.e. a harmful feature in software engineering
terms).  I have never seen any of its proponents offer any hard evidence
in favour of it, though they often quote each others' bare assertions.

Yes, I know that you can use it explicitly, and (again) I stand by my
assertions that it is not reliable, either in terms of the standard
or in terms of what compilers do.

> I'm not going to dignify the rest of this with any further reply, other 
> than to note that running with traps enabled rather obviously *DOES* 
> solve any IF/NaN problems by causing program termination.

While that is true, perhaps I should point that that conventional traps
are part of neither the Fortran nor IEEE standards.  There were many of
us who attempted to persuade IEEE 754R to at least include the reliable
LIA-1 trap-diagnose-and-terminate method as a recommended option, but
it was rejected.

While is it certainly possible to claim that (say) NAG Fortran's traps
are not in breach of IEEE 754, one has to twist the tail of the IEEE
standard in order to do so.  In particular, one has to:
    a) Abrogate most of the wording where IEEE 754 refers to language
standards to be allowed for implementations as well,
    b) Define a block to be a complete program and the handling to be
'break',
    c) Ignore all of the strong recommendations for user-controlled
handling association, and
    d) Either include the invokation as part of the program or ignore
the requirement for IEEE 754 default handling.


Regards,
Nick.