Re: IEEE arithmetic handling

jim@meiko.co.uk (James Cownie) writes:


      Another area where IEEE seems never to be implemented correctly by
      compilers is in the handling of Not a Numbers (NaNs). [...]


(.NOT. (X .LT. 2.0)) does NOT imply (X .GE 2.0)


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


      should generate code which has a run time test.


You are making the assumption that the usual language primitives for FP
("=", "<", ".ne.", etc.) should map directly on IEEE operations. That is
certainly not mandated by most current language standards, and I have
serious doubts that it should be mandated.


An alternative approach, and one which I prefer, is that it is an error to
use the usual language primitives for arithmetic with NaN's (as usual, if
you compile for safety, this error should be detected at runtime, if you
compile for speed, you simply get undefined results). You should have to
use special IEEE primitives ("is_nan(x)", "ieee_less(x,y)") to get at the
IEEE meanings when available.


Why do I prefer this? IEEE operations are implementation specific and
unportable, in the sense that not all implementations of a programming
language support them. When you rely on implementation specific and
unportable features, you should have to express that reliance explicitly
so that when I have to port your code, I can figure out what I have to
change.


Note that even if every computer in the universe supported IEEE floating
point, you would still want to make a clear distinction between the usual
numerical operations and IEEE-specific behavior. The reason is that you
might want to use your numerical code with software implementations of
other kinds of floating point numbers, implementations that may not be
able to support IEEE features.


Thomas.
--

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