Re: IEEE arithmetic handling

jlg@cochiti.lanl.gov (J. Giles) writes:
|> Unfortunately, the Fortran standard does not conform to
|> IEEE (in fact, it conflicts with it in some places - like with regard
|> to negative zero). And the Fortran standard does not require the same
|> conversion accuracy as the IEEE floating point standard.


I have a couple of nits to pick with this. First, Fortran does not
*conflict* with the IEEE vis-a-vis negative zero. It merely says that the
processor must never *output* a negatively-signed zero. That doesn't mean
that variables in the program cannot contain such a value.


Second, not requiring conversion accuracy in Fortran could hardly be called
a conflict. Fortran doesn't require *any* accuracy, precisely so that it
WON'T conflict with any arithmetic standard, and so that it will be
possible to implement Fortran on a wide variety of machines, whether or not
they are IEEE.


Were Fortran to require IEEE accuracy, then you would only see Fortran
implemented on IEEE machines (or machines that exceeded the IEEE
requirements). That would make a lot of Fortran users unhappy.


jim@meiko.co.uk (James Cownie) writes:
> This is a less significant difference than some of the others, in
> particular Fortran definition of NINT and ANINT directly conflicts with
> the IEEE definitions of the same functions.


Since Fortran predates the IEEE standard by several decades, it would be
more accurate to say that the IEEE standard conflicts with Fortran, not the
other way round. In particular, if the IEEE standard attempts to define
the semantics of Fortran intrinsic functions, it is stepping outside its
bounds. But I don't think that's what the IEEE standard does. It does not
specify *anything* about how one accesses the features of the IEEE
floating-point hardware from any particular language.


I think one must conclude, though, that the IEEE standards committee did a
poor job if they defined functions that popular programming languages don't
provide, or functions whose semantics don't match those of existing
languages. But one can hardly blame Fortran for not matching a standard
that had not even been conceived when the original Fortran standard was
developed.


> Another area where IEEE seems never to be implemented correctly by
> compilers is in the handling of Not a Numbers (NaNs).
>
> In the IEEE standard NaNs are values which can be encoded into a floating
> point variable, which represent the concept that it is not a reasonable
> number. (They are generated for operations such as sqrt(-ve), 0.0/0.0
> etc.) IEEE specifies that a NaN is unordered with respect to anything
> else, EVEN ITSELF. Therefore ALL comparisons involving floating variables
> MUST be generated by the compiler WITHOUT introducing logical negation,
> since in the face of NaNs (and their unordered relationship with other
> numbers)
>
> (.NOT. (X .LT. 2.0)) does NOT imply (X .GE 2.0)


I think this is just another area where the IEEE semantics don't match
the semantics of most programming languages. In this case, they don't
even match the semantics users often expect. Most people *would* expect
that (.NOT. (X .LT. 2.0)) implies (X .GE 2.0). There must be millions
of IF-statements out there whose ELSE clauses rely on such things. If
a program is going to break because (X .GE 2.0) is transformed into
(.NOT. (X .LT. 2.0)), then I strongly suspect the program is written
incorrectly in the first place.


Before I get flamed, I will certainly acknowledge that there are lots of
sophisticated programmers who want, and need, to take advantage of IEEE
semantics. The mistake, I think, is to try to overload long-established
semantics of long-existing programming languages for situations that
millions of users have no interest in.


> Similarly (and I've never seen this handled right in an optimising
> compilation),
>
> IF (X .ne. X) THEN
> print *,'X is a NaN'
> ELSE
> print *,'X is a number'
> ENDIF


Our compilers DO handle this correctly, but the special case is only for
equality and non-equality tests. (Yes, our compilers do optimize --
heavily.) It doesn't seem reasonable to special-case other relationals,
because one could hardly rely on a .FALSE. answer meaning you did, or did
not, have a NaN.


--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
bill@ssd.csd.harris.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.