home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / database / 8949 < prev    next >
Encoding:
Text File  |  1993-01-08  |  1.3 KB  |  41 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!dog.ee.lbl.gov!news!humu!pegasus!tleylan
  3. From: tleylan@pegasus.com (Tom Leylan)
  4. Subject: Re: HELP - HELP : CLIPPER BUG ???!!
  5. Message-ID: <1993Jan8.210306.8950@pegasus.com>
  6. Organization: Pegasus,  Honolulu
  7. References: <1993Jan5.160516.1@urc.tue.nl>
  8. Date: Fri, 8 Jan 93 21:03:06 GMT
  9. Lines: 30
  10.  
  11. In article <1993Jan5.160516.1@urc.tue.nl> rcrolf@urc.tue.nl writes:
  12.  
  13. >I stumbled across a most horrible Clipper bug (at least I
  14. >think it's a bug .....).
  15.  
  16. <floating point example deleted for space>
  17.  
  18. Page 93 of The Elements of Programming Style by Kernighan and Plauger
  19.  
  20. "Don't compare floating point numbers solely for equality"
  21.  
  22. Clipper like BASIC, C and many other languages approximates floating
  23. point values.  It can be easily seen in the following example:
  24.  
  25.  nVar := 1/3
  26.  ? nVar + nVar + nVar
  27.  
  28. One doesn't get 1.00 again.
  29.  
  30. As K&P continue to write:
  31.  
  32. "We do not have space to go more deeply into the mysteries of floating
  33. point computation; that is the province of numerical analysts.  We
  34. intend only to emphasize that floating point computations should be used
  35. cautiously when controlling an algorithm.  They should seldom be used
  36. for counting, nor should two computed floating point values be compared
  37. only for equality".
  38.  
  39. tom
  40.  
  41.