home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / coherent / 6378 < prev    next >
Encoding:
Text File  |  1992-12-22  |  3.4 KB  |  66 lines
  1. Newsgroups: comp.os.coherent
  2. Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
  3. From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
  4. Subject: Re: Floating point: printf "%g" bug?
  5. Message-ID: <1992Dec22.202424.14996@klaava.Helsinki.FI>
  6. Organization: University of Helsinki
  7. References: <1992Dec21.123913.2881@philips.oz.au> <1992Dec22.130028.27444@csx.cciw.ca>
  8. Date: Tue, 22 Dec 1992 20:24:24 GMT
  9. Lines: 55
  10.  
  11. In article <1992Dec22.130028.27444@csx.cciw.ca> hcp@csx.cciw.ca (H.C. Pulley) writes:
  12. >
  13. >I think the problem is just that double precision floating point IEEE format 
  14. >is not significant to the number of digits you are trying to display.  If you
  15. >try this with float instead of double you should see the same thing or worse
  16.  
  17. True in itself, although doubles (and even floats) certainly can hold
  18. the exact representations of integers in the range 38-60, which the
  19. example was about.  So the problem does seem to be the conversion
  20. routines to ascii: they could be coded to handle these kinds of cases
  21. better.  Perl seems to be very picky about these things in the tests,
  22. even though it normally isn't a problem. 
  23.  
  24. >(this used to happen a lot in FORTRAN with different machines having very 
  25. >different doubleprecision in the mainframe days - CDC Cybers have 128 bit 
  26. >doubles, and you wonder why your answer is not the same as the guy using the 
  27. >VAX).
  28.  
  29. More bits in fp certainly helps, but so does some careful coding.  The
  30. problem is that writing the conversion routines correctly is a major
  31. headache that very seldom is seen in practice: guaranteeing that exact
  32. values get converted correctly while giving reasonable conversions for
  33. things that cannot be expressed exactly in double format can be really
  34. ugly.  It's possible, but you must never use divide-by-ten etc things
  35. that are the "natural" way to do these things.  It gets worse if the
  36. soft-float routines in use aren't exact (don't know about the Coherent
  37. floating point calcs, but the original linux fpu emulator I wrote didn't
  38. care about last-bit-correctness, so people saw a lot of these kinds of
  39. things). 
  40.  
  41. The simplest (and naively obvious) way to do conversions from float ->
  42. ascii is to convert the mantissa as a integer value, and then do a
  43. suitable number of divide-by-two or multiply-by-two's on the resultant
  44. bcd representation depending on the exponent.  This also guarantees
  45. exact values - you're working on integers all the time (and *2 and /2
  46. are easy to do exactly on bcd, at least until you decide that you don't
  47. want more than about 20 digits..)
  48.  
  49. The problem with the above is that it doesn't work too well when the
  50. exponent is big (negative of positive).  But those cases are also the
  51. cases where the value is unlikely to actually be exact (it might be, but
  52. nobody generally cares any more), so you can use a faster routine for
  53. those cases, dividing/multiplying by powers of ten etc, and accept that
  54. you no longer get a exact ascii representation of the value stored in
  55. the floating point variable.
  56.  
  57. So it's certainly possible to make a routine that converts things that
  58. can be represented exactly (small integers, powers of two like 0.125
  59. etc) well, while doing reasonable work for other values.  It's just
  60. generally easier to cut a few corners, and accept rounding errors in the
  61. last digits in a few cases.  After all, you should never expect more
  62. than 10 digits of accuracy of doubles anyway, even if 48 bits of
  63. mantissa should theoretically give 14+ digits. 
  64.  
  65.         Linus
  66.