home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / compiler / 1896 < prev    next >
Encoding:
Text File  |  1992-11-17  |  4.9 KB  |  109 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!usc!sol.ctr.columbia.edu!eff!world!iecc!compilers-sender
  3. From: bill@amber.csd.harris.com (Bill Leonard)
  4. Subject: Re: IEEE arithmetic handling
  5. Reply-To: bill@amber.csd.harris.com (Bill Leonard)
  6. Organization: Harris CSD, Ft. Lauderdale, FL
  7. Date: Mon, 16 Nov 1992 21:56:18 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-11-087@comp.compilers>
  10. Keywords: arithmetic
  11. References: <92-11-041@comp.compilers>
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 94
  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. I have a couple of nits to pick with this.  First, Fortran does not
  22. *conflict* with the IEEE vis-a-vis negative zero.  It merely says that the
  23. processor must never *output* a negatively-signed zero.  That doesn't mean
  24. that variables in the program cannot contain such a value.
  25.  
  26. Second, not requiring conversion accuracy in Fortran could hardly be called
  27. a conflict.  Fortran doesn't require *any* accuracy, precisely so that it
  28. WON'T conflict with any arithmetic standard, and so that it will be
  29. possible to implement Fortran on a wide variety of machines, whether or not
  30. they are IEEE.
  31.  
  32. Were Fortran to require IEEE accuracy, then you would only see Fortran
  33. implemented on IEEE machines (or machines that exceeded the IEEE
  34. requirements).  That would make a lot of Fortran users unhappy.
  35.  
  36. jim@meiko.co.uk (James Cownie) writes:
  37. > This is a less significant difference than some of the others, in
  38. > particular Fortran definition of NINT and ANINT directly conflicts with
  39. > the IEEE definitions of the same functions. 
  40.  
  41. Since Fortran predates the IEEE standard by several decades, it would be
  42. more accurate to say that the IEEE standard conflicts with Fortran, not the
  43. other way round.  In particular, if the IEEE standard attempts to define
  44. the semantics of Fortran intrinsic functions, it is stepping outside its
  45. bounds.  But I don't think that's what the IEEE standard does.  It does not
  46. specify *anything* about how one accesses the features of the IEEE
  47. floating-point hardware from any particular language.
  48.  
  49. I think one must conclude, though, that the IEEE standards committee did a
  50. poor job if they defined functions that popular programming languages don't
  51. provide, or functions whose semantics don't match those of existing
  52. languages.  But one can hardly blame Fortran for not matching a standard
  53. that had not even been conceived when the original Fortran standard was
  54. developed.
  55.  
  56. > Another area where IEEE seems never to be implemented correctly by
  57. > compilers is in the handling of Not a Numbers (NaNs). 
  58. > 
  59. > In the IEEE standard NaNs are values which can be encoded into a floating
  60. > point variable, which represent the concept that it is not a reasonable
  61. > number.  (They are generated for operations such as sqrt(-ve), 0.0/0.0
  62. > etc.)  IEEE specifies that a NaN is unordered with respect to anything
  63. > else, EVEN ITSELF. Therefore ALL comparisons involving floating variables
  64. > MUST be generated by the compiler WITHOUT introducing logical negation,
  65. > since in the face of NaNs (and their unordered relationship with other
  66. > numbers)
  67. >     
  68. >     (.NOT. (X .LT. 2.0)) does NOT imply (X .GE 2.0)
  69.  
  70. I think this is just another area where the IEEE semantics don't match
  71. the semantics of most programming languages.  In this case, they don't
  72. even match the semantics users often expect.  Most people *would* expect
  73. that (.NOT. (X .LT. 2.0)) implies (X .GE 2.0).  There must be millions
  74. of IF-statements out there whose ELSE clauses rely on such things.  If
  75. a program is going to break because (X .GE 2.0) is transformed into
  76. (.NOT. (X .LT. 2.0)), then I strongly suspect the program is written
  77. incorrectly in the first place.
  78.  
  79. Before I get flamed, I will certainly acknowledge that there are lots of
  80. sophisticated programmers who want, and need, to take advantage of IEEE
  81. semantics.  The mistake, I think, is to try to overload long-established
  82. semantics of long-existing programming languages for situations that
  83. millions of users have no interest in.
  84.  
  85. > Similarly (and I've never seen this handled right in an optimising
  86. > compilation),
  87. > 
  88. >     IF (X .ne. X) THEN
  89. >             print *,'X is a NaN'
  90. >         ELSE
  91. >             print *,'X is a number'
  92. >         ENDIF
  93.  
  94. Our compilers DO handle this correctly, but the special case is only for
  95. equality and non-equality tests.  (Yes, our compilers do optimize --
  96. heavily.)  It doesn't seem reasonable to special-case other relationals,
  97. because one could hardly rely on a .FALSE. answer meaning you did, or did
  98. not, have a NaN.
  99.  
  100. -- 
  101. Bill Leonard
  102. Harris Computer Systems Division
  103. 2101 W. Cypress Creek Road
  104. Fort Lauderdale, FL  33309
  105. bill@ssd.csd.harris.com
  106. -- 
  107. Send compilers articles to compilers@iecc.cambridge.ma.us or
  108. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  109.