home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11265 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.8 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!mips!zaphod.mps.ohio-state.edu!uwm.edu!bionet!raven.alaska.edu!news.u.washington.edu!hardy.u.washington.edu!rons
  2. From: rons@hardy.u.washington.edu (Ronald Schoenberg)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Power Operator vs NANs
  5. Message-ID: <1992Jul21.204639.2327@u.washington.edu>
  6. Date: 21 Jul 92 20:46:39 GMT
  7. References: <1992Jul15.123527.3771@bnr.co.uk> <850@nazgul.UUCP> <TMB.92Jul21152204@arolla.idiap.ch>
  8. Sender: news@u.washington.edu (USENET News System)
  9. Organization: University of Washington, Seattle
  10. Lines: 48
  11.  
  12. In article <TMB.92Jul21152204@arolla.idiap.ch> tmb@idiap.ch writes:
  13. >In article <850@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:
  14. >
  15. >   C++ has abandoned ones-complement hardware and 6-char linkers, that C
  16. >   was unwilling to leave behind. Maybe it is time to leave behind non-IEEE
  17. >   floating point too.
  18. >
  19. >C++ does not specify how integer arithmetic is to be performed on the
  20. >machine. And, personally, I don't think it's time to leave behind
  21. >non-IEEE floating point.
  22. >
  23.   [elision]
  24. >
  25. >There is a nice middle road. You can use functional/macro syntax
  26. >(isnan(x), isinf(x), ...) to denote standardized IEEE floating point
  27. >operations. Such notation is straighforward, simple, and easy to
  28. >implement even in existing compilers. Via the usual "#define foo(x)
  29. >__foo(x)" trick, you can get macro semantics (i.e., you don't get the
  30. >feature unless you #include the header file) with the efficiency and
  31. >flexibility of a language extension.
  32. >
  33. >   For instance, only Zortech's compiler correctly (IEEE 754) implements
  34. >   == and != (others set the exception bits incorrectly if one operand
  35. >   is a NAN). Do you really want to do isequal(a,b) instead of a==b?
  36. >
  37. >I would want neither. The behavior of operator== on NaN's should be
  38. >left undefined. If you care to know whether operator== is operating on
  39. >a NaN, you should simply test beforehand:
  40. >
  41. >    if(isnan(x)||isnan(y)) { ... }
  42. >    else if(x==y) { ... }
  43. >
  44. >Sadly, this is a losing battle. NCEG seems to be determined to go down
  45. >this route of adding lots of IEEE specific, complicated, useless
  46. >operators, and the C++ language is likely to follow suite.
  47. >
  48. >                Thomas.
  49.  
  50. I'm not sure I understand - why is better to leave the effect of NaN's
  51. on operator == undefined?  Why do you see NCEG as losing battle? 
  52. What do you really have against adding features that would benefit
  53. people like me who are doing numerics programming?  Your note seems to
  54. assume that I would know why "it's not time to leave behind non-IEEE
  55. floating point.  What exactly do non-numerics programmers have to lose
  56. with IEEE floating point?  Maybe Walter Bright could tell us what the
  57. reaction is to Zortech C++.  Is there a deluge of criticism from
  58. non-numerics programmers?  Or maybe they aren't even aware of (and
  59. don't care about) the NCEG extensions.  And maybe the numerics
  60.