home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / compiler / 1917 < prev    next >
Encoding:
Text File  |  1992-11-19  |  2.1 KB  |  46 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!paladin.american.edu!darwin.sura.net!ukma!cs.widener.edu!eff!world!iecc!compilers-sender
  3. From: bart@cs.uoregon.edu (Barton Christopher Massey)
  4. Subject: Re: IEEE arithmetic handling
  5. Reply-To: bart@cs.uoregon.edu (Barton Christopher Massey)
  6. Organization: University of Oregon Computer and Information Sciences Dept.
  7. Date: Thu, 19 Nov 1992 07:55:41 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-11-108@comp.compilers>
  10. Keywords: Fortran, arithmetic
  11. References: <92-11-041@comp.compilers> <92-11-097@comp.compilers>
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 31
  14.  
  15. eggert@twinsun.com (Paul Eggert) writes:
  16. > But that conflicts with IEEE Std 754-1985, section 5.6, which requires
  17. > that converting a number from binary to decimal and back be the identity
  18. > if the proper precision and rounding is used.  The Fortran standard says
  19. > -0.0 must be output as 0.0; this loses information.
  20.  
  21. This and other recent similar comments about compilers and IEEE reminded
  22. me of this note from the back of a recent technical report here (How To
  23. Read Floating Point Numbers Accurately, William D. Clinger, University of
  24. Oregon CIS-TR-90-01, June 1990)
  25.  
  26.     The IEEE standard explicitly states that, in high level
  27.     languages, the destination of an arithmetic operation
  28.     may be determined by the compiler, and hence may be
  29.     beyond the control of programmers.  In other words, the
  30.     compiler -- not the programmer who uses the compiler --
  31.     is regarded as the client of the standard.  Thus the
  32.     error bounds guaranteed by the IEEE standard may not be
  33.     relied upon by programmers who work in high level
  34.     languages.
  35.     
  36. Modulo arguments about whether FORTRAN is a high-level language :-), it
  37. seems to me that this pretty much answers the question of whether FORTRAN
  38. arithmetic is IEEE compliant.  It's not, but it needn't be, and it may be
  39. unrealistic to expect it to be, given the goals of HLL design.
  40.  
  41.                 Bart Massey
  42.                 bart@cs.uoregon.edu
  43. -- 
  44. Send compilers articles to compilers@iecc.cambridge.ma.us or
  45. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  46.