home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / compiler / 1904 < prev    next >
Encoding:
Text File  |  1992-11-18  |  3.0 KB  |  67 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!think.com!spdcc!iecc!compilers-sender
  3. From: jlg@cochiti.lanl.gov (J. Giles)
  4. Subject: Re: IEEE arithmetic handling
  5. Reply-To: jlg@cochiti.lanl.gov (J. Giles)
  6. Organization: Los Alamos National Laboratory
  7. Date: Tue, 17 Nov 1992 19:42:06 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-11-095@comp.compilers>
  10. References: <92-11-041@comp.compilers> <92-11-087@comp.compilers>
  11. Keywords: arithmetic
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 52
  14.  
  15. jlg@cochiti.lanl.gov (J. Giles) writes:
  16. > Unfortunately, the Fortran standard does not conform to
  17. > IEEE (in fact, it conflicts with it in some places - like with regard
  18. > to negative zero).  And the Fortran standard does not require the same
  19. > conversion accuracy as the IEEE floating point standard.  
  20.  
  21. bill@amber.csd.harris.com (Bill Leonard) writes:
  22. |> I have a couple of nits to pick with this.  First, Fortran does not
  23. |> *conflict* with the IEEE vis-a-vis negative zero.  It merely says that the
  24. |> processor must never *output* a negatively-signed zero.  That doesn't mean
  25. |> that variables in the program cannot contain such a value.
  26.  
  27. Doesn't IEEE say that some form of output must be available for which
  28. output followed by input returns the same value?  If the external
  29. representation is not even *allowed* to have the minus sign, how do you
  30. preserve it?
  31.  
  32. |> [...]
  33. |> Were Fortran to require IEEE accuracy, then you would only see Fortran
  34. |> implemented on IEEE machines (or machines that exceeded the IEEE
  35. |> requirements).  That would make a lot of Fortran users unhappy.
  36.  
  37. Quite true.  But Fortran *could* make a more general requirement based on
  38. Fortran 90's "model numbers" which could place *some* constraints on
  39. conversion precision and other operations.  For example, it could state
  40. the requirement I gave earlier: provided the external representation
  41. carries enough digits, output followed by input of the same string should
  42. return the original number.
  43.  
  44. This is easily accomplished.  Let `b' be the base of your floating point
  45. representation and let `p' be the number of digits in your significand.
  46. Then, output followed by input is the identity if:
  47.  
  48.         (m-1)     p
  49.       10      >= b  - 1
  50.  
  51. Where `m' is the number of decimal digits output.  This is true whether
  52. you truncate or round to `m' digits.  The Fortran standard could easily
  53. have called for this precision - at a minimum - to be provided for
  54. floating-point format conversions.  It could easily have required this to
  55. be the precision used for list-directed output (with the allowance that
  56. trailing zeros could be omitted).  It could easily have allowed minus
  57. signs on numbers with only zero digits.  Etc..  The standard does none of
  58. those things - thus allowing a standard conforming Fortran which has none
  59. of these properties and which also is not required to conform to IEEE even
  60. if the hardware *does*.
  61.  
  62. -- 
  63. J. Giles
  64. -- 
  65. Send compilers articles to compilers@iecc.cambridge.ma.us or
  66. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  67.