home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / next / programm / 7055 < prev    next >
Encoding:
Internet Message Format  |  1992-11-06  |  1.4 KB

  1. Path: sparky!uunet!rosie!NeXT.COM
  2. From: Mark_Wagner@NeXT.COM (Mark Wagner)
  3. Newsgroups: comp.sys.next.programmer
  4. Subject: Re: cc problem and cure: comparison among doubles can produce wrong results
  5. Message-ID: <5774@rosie.NeXT.COM>
  6. Date: 6 Nov 92 00:57:13 GMT
  7. References: <1ccm61INNhoq@agate.berkeley.edu>
  8. Sender: news@NeXT.COM
  9. Lines: 28
  10.  
  11. > >      However, given that the conversion
  12. > >      algorithm from external to internal format is the same, I would  
  13. > argue that
  14. > >      ALL instances of the SAME decimal value will result in the SAME  
  15. > binary
  16. > >      floating point value internally and can therefore be compared for  
  17. > equality
  18. > >      with impunity.
  19. > Actually, it's worse than this.  Sometimes floating point values can be  
  20. > different depending on whether or not they've been in and out of  
  21. > registers, etc.  Moral:  Use something like this:
  22. One can use the -ffloat-store option to "cure" this problem but at some
  23. cost in terms of performance (depending, of course, on the application).
  24.  
  25.      -ffloat-store
  26.           Don't store floating-point variables in registers.
  27.           This prevents undesirable excess precision due to the
  28.           floating registers keeping more precision than a double
  29.           is supposed to have.
  30.  
  31.           For most programs, the excess precision does no harm,
  32.           but a few programs rely on the precise definition of
  33.           IEEE floating point.  Use -ffloat-store for such pro-
  34.           grams.
  35.  
  36. mwagner@next.com
  37.