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

[N.M. Maclaren]

On Oct 28 2014, Malcolm Cohen wrote:
>
>>My colleague wrote:
>>
>>        I've just learned that at least some compilers will no longer
>>        support the arithmetic IF statement.
>
> Since that is currently standard-conforming, such a compiler is also not 
> standard-conforming. Compilers that ignore the standard are (rather 
> obviously) not going to be affected by whatever *we* decide!

Well, yes, and I am NOT arguing in favour of retaining the arithmetic
IF, because it is a piece of nasty historical syntax.  There is nothing
wrong with a 3-branch IF, when done right (as in Algol 68), but the
arithmetic IF is really a sort of computed GOTO.

> There is, indeed, no good answer as to what this statement should do if 
> the value in question is a NaN. Which is why you should remove it from 
> your program. And why it should be removed from the standard.

And the only good answer to what a logical IF should do if the operand
involves a NaN is to throw an exception.  The rule that comparisons on
NaNs always deliver False is every bit as horrible as (say) defining
an arithmetic IF to take the zero branch on a NaN.  Which would even
have precedent (Java real=>integer conversion)!

> 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.

And, if you think that it is going to help you with IFs and NaNs, you are
living in cloud cuckoo land.  As I have said before, I have investigated
this more than once, and the IEEE 754 assumptions don't match either
human or compiler behaviour.

> After all, if you continue to use arithmetic IF, that's what the compiler 
> is effectively going to do "under the covers". There are no single 
> machine instructions that branch to three different labels depending on a 
> floating-point value. Of course this means that NaN will do different 
> (and maybe impossible) things on different machines or with different 
> compiler options. Now THAT would be a problem! At least if you replace it 
> with 1-3 logical IF+GOTO yourself it will do the same thing.

No, it won't.  For a start, NaN is normally the result of an undefined
calculation (so all bets are off), so you can get 'impossible' results
for ANY code.

Secondly, even when they aren't, Fortran has steadfastly refused to
adopt the ghastly IEEE 754 viewpoint that compilers are simply macro
generators.  And Fortran 2008 makes it VERY clear (in 13.7.1p2 and
elsewhere) that, under most circumstances, compilers are allowed to
optimise on the basis of there being no NaNs.

Yes, there is an ambiguity if IEEE_ARITHMETIC is accessible, in that it
might override wording like (say) Fortran 2008 7.1.5.2.4 and 13.4.


Regards,
Nick.