home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11312 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  5.7 KB

  1. Path: sparky!uunet!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!tmb
  2. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Power Operator vs NANs
  5. Message-ID: <TMB.92Jul22122639@arolla.idiap.ch>
  6. Date: 22 Jul 92 16:26:39 GMT
  7. References: <1992Jul15.123527.3771@bnr.co.uk> <850@nazgul.UUCP>
  8.     <TMB.92Jul21152204@arolla.idiap.ch>
  9.     <1992Jul21.204639.2327@u.washington.edu>
  10. Sender: news@ai.mit.edu
  11. Reply-To: tmb@idiap.ch
  12. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  13.     Perceptive)
  14. Lines: 109
  15. In-reply-to: rons@hardy.u.washington.edu's message of 21 Jul 92 20:46:39 GMT
  16.  
  17. In article <1992Jul21.204639.2327@u.washington.edu> rons@hardy.u.washington.edu (Ronald Schoenberg) writes:
  18.  
  19.    >I would want neither. The behavior of operator== on NaN's should be
  20.    >left undefined. If you care to know whether operator== is operating on
  21.    >a NaN, you should simply test beforehand:
  22.    >
  23.    >    if(isnan(x)||isnan(y)) { ... }
  24.    >    else if(x==y) { ... }
  25.    >
  26.    >Sadly, this is a losing battle. NCEG seems to be determined to go down
  27.    >this route of adding lots of IEEE specific, complicated, useless
  28.    >operators, and the C++ language is likely to follow suite.
  29.  
  30.    I'm not sure I understand - why is better to leave the effect of NaN's
  31.    on operator == undefined?
  32.  
  33. Programs that assume special behavior of NaN's when given as arguments
  34. to operator== are unportable, since they rely on a machine-specific
  35. feature (a particular implementation of IEEE floating point).  So far,
  36. the C standard has been designed such that most (all?) unportable
  37. programs have been "in error", and conforming implementations could
  38. legally detect and report such errors. Writing a machine-specific
  39. feature into the language standard would prohibit implementations from
  40. detecting some unportable programs.
  41.  
  42. More concretely, defining the behavior of operator== on NaN's would
  43. lead to people quietly relying on it and would be even another source
  44. of undectable unportable assumptions in the C language. On the other
  45. hand, if the behavior isn't defined, programmers will at least be
  46. compelled by the language standard to test for NaN's explicitly.
  47.  
  48.    Why do you see NCEG as losing battle?
  49.  
  50. Please read carefully what I said. It is a "losing battle" trying to
  51. stem the tide of IEEE-specific floating point operators. My statement
  52. said nothing about NCEG as a whole.
  53.  
  54.    What do you really have against adding features that would benefit
  55.    people like me who are doing numerics programming?
  56.  
  57. I do lots of numerical programming myself; otherwise, I wouldn't care
  58. what happens to numerical extensions of C/C++.
  59.  
  60.    Your note seems to assume that I would know why "it's not time to
  61.    leave behind non-IEEE floating point.  What exactly do non-numerics
  62.    programmers have to lose with IEEE floating point?
  63.  
  64. There are lots of machines that do not support IEEE floating point.
  65. I have to use such machines. Furthermore, I don't mind using such
  66. machines: they tend to give me more crunch for less money, and they
  67. solve most of my numerical problems efficiently and correctly.
  68.  
  69. In addition to hardware diversity, another reason not to come to rely
  70. on IEEE-specific features is that most of the IEEE floating point
  71. features are likely to be difficult or impossible to provide for
  72. software-defined real number types.
  73.  
  74.    Maybe Walter Bright could tell us what the reaction is to Zortech
  75.    C++.  Is there a deluge of criticism from non-numerics programmers?
  76.    Or maybe they aren't even aware of (and don't care about) the NCEG
  77.    extensions.
  78.  
  79. As I was saying, I have nothing against standardizing IEEE-specific
  80. operations in header files. Since I write lots of numerical programs
  81. myself, I consider such standards very useful.
  82.  
  83. What I dislike is assigning a special status to IEEE floating point in
  84. C/C++ by providing special syntax and semantics for its features.
  85. There are three main problems with that:
  86.  
  87.  * it will disadvantage non-IEEE implementations
  88.  
  89.  * it will likely lead to undetectable IEEE dependencies in programs
  90.    (if you only rely on the special properties of NaN's with the C
  91.    comparison operators, I have no way to determine whether you wrote
  92.    your program with IEEE floating point in mind or not)
  93.  
  94.  * it cannot be implemented as a library or as macros, meaning
  95.    that users of old compilers are out in the cold
  96.  
  97. The specific proposal that NCEG is considering (and, sadly, likely to
  98. adopt) has the additional disadvantage that the meaning of something
  99. like "x !<> y" is much less clear to the casual user of IEEE features
  100. than an equivalent, explicit expression in terms of "isnan(x)".
  101.  
  102. IEEE-specific features can be provided through standardized header
  103. files. This has no cost in terms of performance (the IEEE primitives
  104. can still be inlined and optimized by the compiler), it requires the
  105. user to declare that his program is dependent on IEEE floating point
  106. if he wants to use IEEE features, and it can be implemented as a
  107. library or header file for old compilers using nothing more than
  108. macros and functions. Furthermore, for porting IEEE code to non-IEEE
  109. machines, it allows me to redefine easily the meaning of the IEEE
  110. primitives used by some algorithm.
  111.  
  112. C/C++ has made very few concessions to hardware-specific properties.
  113. Word sizes are not fixed. The properties of "operator%" are not
  114. defined. The character set is not defined. Machine specific properties
  115. have always been defined through include files, for all of the reasons
  116. that I have outlined above. I see no good reason to break with this
  117. tradition to accomodate IEEE floating point.
  118.  
  119.                     Thomas.
  120.  
  121. PS: In fact, even FORTRAN-77 and FORTRAN-90 do not seem to have any
  122. IEEE-specific features. From what I understand, even FORTRAN-90 is
  123. rather conservative with its numerical inquiry functions, and likely
  124. so for good reasons.
  125.  
  126.