🚀 go-pugleaf

In article <1991Jun7.204910.878@borland.com> sjc@borland.com (Steve Correll)
writes:

>...
>
>The missing rule is (ANSI X3.9-1978 sect 6.6):
>
>    "Any numeric operation whose result is not mathematically defined is
>    prohibited in the execution of an executable program. Examples are
>    dividing by zero and raising a zero-valued primary to a zero-valued or
>    negative-valued power."
>
>Who knows whether IEEE infinity is a "mathematically defined result"? If you

I would think it isn't: it doesn't correspond to a single mathematical real
number in the way that ordinary IEEE numbers do.

>claim that it is, then a compiler which collapses 0*x => x violates section
>6.6.4. If you claim that it is not, then a program which even generates IEEE
>infinity or NaN (not to mention a program which expects them to propagate
>through computations in a well-defined fashion) violates section 6.6. The IEEE
>fp committee chose not to deal with existing language standards.
>
>This hasn't prevented lots of people from trying to have their cake and eat
>it too, by saying that IEEE floating point should have no impact on compiler
>optimization, but the programmer should compute with infinity and NaN anyway,
>and it's the programmer's fault if s/he doesn't know that some
>IEEE-legal-but-Fortran-illegal features will burn you and others will not,
>depending on the implementation in question.
>
>In practice, of course, programmers will attempt to do exactly that, and lots
>of them will get burned. You can do useful work with a compiler which doesn't
>de-optimize its code to cater to the IEEE standard, but you do need to be
>careful about it.

I don't see any evidence here that the "IEEE fp committee chose not to deal
with existing language standards". The existence of a facility in IEEE
arithmetic does *not* mean that every language has to supply it.

For instance, in this case the quoted part of the Fortran standard
effectively means that non-numeric values like infinities and NaNs must not
occur when a Fortran program is run, and that a run-time error should occur
in cases where the result of an operation can only be non-numeric. Unless
the IEEE system's trap-handling is seriously deficient (e.g. by ignoring
most of the "should" parts of the IEEE standard), this can be arranged by
having the run-time system trap the IEEE invalid operation, divide-by-zero
and overflow exceptions and produce appropriate run-time error messages.

As long as data is not initialised to non-numeric values, these trap
handlers will ensure that a run-time error will occur as soon as any such
value is produced. (Ignoring such things as non-numeric values produced by
writing to integer variables which are aliased with floating point variables
- such tricks are highly system-dependent anyway.) This means that
non-numeric values are "quarantined", so that the compiler may safely use
such optimisations as 0.0*X = 0.0.

In short, the IEEE fp committee seem to have dealt with existing language
standards by providing a superset of their facilities, together with ways of
trapping attempts to make use of the extra facilities when (as in the case
of the quoted part of the Fortran standard) the language standard forbids
their use.

If you don't want to make use of infinities and NaNs, a Fortran system that
traps them as above will suit your purposes and will strictly conform to the
Fortran standard. If you do want to make use of them, the quoted part of the
Fortran standard means that a strictly-conforming Fortran system is not for
you. You can't have it both ways...

Of course, some IEEE systems may be "broken" from this point of view. E.g.
if trapping the invalid operation, divide-by-zero or overflow exceptions
slows down your IEEE system dramatically, you may be faced with the awkward
choice of having your programs run slowly and strictly in accordance with
the Fortran standard, or fast and in a non-conforming way. I suspect many
language implementors would choose the latter. Then lots of programmers may
get burned...

David Seal
Sorry about the bad "From" line. This is on a list of things to be fixed
here. Correct email address is "dseal@armltd.co.uk".

All opinions are mine only...