home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / compiler / 1888 < prev    next >
Encoding:
Text File  |  1992-11-16  |  2.5 KB  |  63 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!think.com!spdcc!iecc!compilers-sender
  3. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  4. Subject: Re: IEEE arithmetic handling
  5. Reply-To: tmb@arolla.idiap.ch (Thomas M. Breuel)
  6. Organization: IDIAP
  7. Date: Mon, 16 Nov 1992 01:19:25 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-11-079@comp.compilers>
  10. References: <92-11-041@comp.compilers>
  11. Keywords: arithmetic, design
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 48
  14.  
  15. jim@meiko.co.uk (James Cownie) writes:
  16.  
  17.    Another area where IEEE seems never to be implemented correctly by
  18.    compilers is in the handling of Not a Numbers (NaNs). [...]
  19.  
  20.        (.NOT. (X .LT. 2.0)) does NOT imply (X .GE 2.0)
  21.  
  22.    [...] Similarly (and I've never seen this handled right in an optimising
  23.    compilation),
  24.  
  25.        IF (X .ne. X) THEN
  26.            print *,'X is a NaN'
  27.        ELSE
  28.            print *,'X is a number'
  29.        ENDIF
  30.  
  31.    should generate code which has a run time test. 
  32.  
  33. You are making the assumption that the usual language primitives for FP
  34. ("=", "<", ".ne.", etc.) should map directly on IEEE operations.  That is
  35. certainly not mandated by most current language standards, and I have
  36. serious doubts that it should be mandated.
  37.  
  38. An alternative approach, and one which I prefer, is that it is an error to
  39. use the usual language primitives for arithmetic with NaN's (as usual, if
  40. you compile for safety, this error should be detected at runtime, if you
  41. compile for speed, you simply get undefined results).  You should have to
  42. use special IEEE primitives ("is_nan(x)", "ieee_less(x,y)") to get at the
  43. IEEE meanings when available.
  44.  
  45. Why do I prefer this? IEEE operations are implementation specific and
  46. unportable, in the sense that not all implementations of a programming
  47. language support them. When you rely on implementation specific and
  48. unportable features, you should have to express that reliance explicitly
  49. so that when I have to port your code, I can figure out what I have to
  50. change.
  51.  
  52. Note that even if every computer in the universe supported IEEE floating
  53. point, you would still want to make a clear distinction between the usual
  54. numerical operations and IEEE-specific behavior. The reason is that you
  55. might want to use your numerical code with software implementations of
  56. other kinds of floating point numbers, implementations that may not be
  57. able to support IEEE features.
  58.  
  59.                     Thomas.
  60. -- 
  61. Send compilers articles to compilers@iecc.cambridge.ma.us or
  62. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  63.