home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / c / 3336 < prev    next >
Encoding:
Text File  |  1993-01-07  |  1.2 KB  |  35 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!dptg!rjf
  3. From: rjf@lincroftnj.ncr.com (51351[efw]-Robert Feddeler(MT4799)T343)
  4. Subject: Re: understanding FLT_DIG
  5. Message-ID: <1993Jan7.215114.12680@lincroftnj.ncr.com>
  6. Organization: AT&T/NCR, Lincroft, NJ, USA
  7. References: <steve.726275211@unidata.ucar.edu>
  8. Distribution: na
  9. Date: Thu, 7 Jan 1993 21:51:14 GMT
  10. Lines: 23
  11.  
  12. In article <steve.726275211@unidata.ucar.edu> steve@unidata.ucar.edu (Steve Emmerson) writes:
  13. >Hi,
  14. >
  15. >I'm having trouble understanding FLT_DIG, which is defined in <float.h>,
  16. >According to section 2.2.4.2.2 of the ANSI standard, FLT_DIG is given by
  17. >the following on base-2 machines:
  18. >
  19. >    FLT_DIG = (int)((p-1)*log10(2))
  20. >
  21. >where `p' is the precision (the number of base-2 digits in the
  22. >significand).
  23. >
  24. >On a hypothetical base-2 machine with 4 bits of precision, the above yields
  25. >0 for FLT_DIG.  Yet, those 4 bits can represent the integral values 1
  26. >through 9 exactly.  Thus, shouldn't FLT_DIG be 1?
  27. >
  28.  
  29. Note the 'p-1'.  The '-1' leaves room for a sign bit.
  30. You're left with only 3 bits or 0-7.
  31.  
  32.  
  33. bob.                | Heap bit trouble in the land of plenty.
  34. Were these more than just my opinions, they would have cost a bit more.
  35.