home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / bit / listserv / statl / 2328 < prev    next >
Encoding:
Text File  |  1993-01-07  |  4.2 KB  |  82 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!paladin.american.edu!auvm!CCDOSH1.EM.CDC.GOV!DXA6
  3. Encoding: 71 TEXT
  4. X-Mailer: Microsoft Mail V3.0
  5. Message-ID: <2B4C2012@router.em.cdc.gov>
  6. Newsgroups: bit.listserv.stat-l
  7. Date:         Thu, 7 Jan 1993 16:09:00 EST
  8. Sender:       STATISTICAL CONSULTING <STAT-L@MCGILL1.BITNET>
  9. From:         dxa6@CCDOSH1.EM.CDC.GOV
  10. Subject:      Spreadsheets and calculators, again
  11. Lines: 69
  12.  
  13. *Forgive me if this is a duplicate posting, but I have reason to believe my
  14. earlier effort failed to transmit.*
  15.  
  16. Here I go again, sticking my neck out.  Let me begin with a disclaimer: I
  17. agree with most of what has been said about the perils of using
  18. spreadsheets for statistical calculations.  There are certainly many
  19. pitfalls.
  20.  
  21. When I confessed that I had used spreadsheets successfully under some
  22. circumstances, I had no doubt that my data was "well-behaved," and with
  23. small sample sizes, it was easy to check.  I used a spreadsheet because it
  24. was the best tool I had available at the moment, and I needed a quick
  25. answer.  I was also careful to set up the calculations to include all the
  26. intermediate values, just as if I was doing it by hand, in order to have at
  27. least some check for overflows and other errors.  The purists on the list
  28. think that what I did was "wrong," or at least too risky to tolerate.
  29.  
  30. A number of people provided me with private responses containing examples
  31. where spreadsheets are likely to break down doing statstical computations.
  32. One ofthe most frequently cited was the formula for variance. A couple of
  33. people pointed out that the usual computational formula,
  34.      1/n * (sum(x^2) - sum(x)^2)/n
  35. required the accumulation of the sum of the squares term, which could easily
  36. overflow or lose precision, and that a better (though not perfect) formula
  37. would be the general,
  38.       sum((x-mean(x))^2/n
  39. which by subtracting the mean before taking the square, was less likely to
  40. overflow.  This in turn lead me to wonder about the differences between how
  41. my old pocket calculator handled such calculations vs. a more modern PC,
  42. since the calculator used the usual computational formula.
  43.  
  44. As several people pointed out, calculators overflow with factorials greater
  45. than 69!  (Phil Miller claimed the same limit for an IBM PC, model
  46. unspecified.) I clearly recall that the same was true of my old HP 67, but it
  47. has long since gone to the hardware graveyard.  (My current HP 11C also
  48. overflows at 70!.)  I did save my old HP 67 and even older HP 55 manuals,
  49. because they contained a number of algorithms for statistical computing
  50. on pocket calculators, designed to circumvent some of the pitfalls that we
  51. are all worried about.
  52.  
  53. On my Macintosh IIci at home (Motorola 68030 with MC68883 floating-point math
  54. coprocessor) using a Microsoft Excel 3.0 spreadheet, I tried factorials up to
  55. 100! with no apparent problems:
  56.      100! = 9.332622E+157 and 99!=9.332622E+155, while 100!/99! = 100.000000
  57. (yes, I divided the output from the previous individual calculations), so it
  58. appears to be correctly handling much larger numbers than a pocket
  59. calculator, or an older IBM PC can.  (Duncan Murdoch today said that some PCs
  60. may be able to handle numbers up to 170! or 1754!.)
  61.  
  62. The built in algorithm for variance (of a population sample) in Excel 3.0 is:
  63.   (n (sum(x^2)) - (sum(x))^2) / (n(n-1))
  64. (There is also a VARP function which calculates variance for an entire
  65. population, but the formula is not explicitly given, so one can only assume
  66. it uses n and not n-1 in the denomonator.)  As a couple of people noted, this
  67. formula is not the best.  But the overflow problem may be mitigated somewhat
  68. by the capabilities of the CPU and coprocessor.
  69.  
  70. None of this changes the rule of thumb that spreadsheets for statistics are
  71. risky.  My only point is that for every rule, there are exceptions. ;-)
  72. What I, and probably many others in the world, would like to know are some
  73. more explicit guidelines on the matter; and as I said, I intend to explore
  74. this area some more on my own.
  75.  
  76. --Dave
  77. _____________________________________________________________________________
  78. David Arday, M.D., M.P.H
  79. Office on Smoking and Heath
  80. Centers for Disease Control and Prevention
  81. dxa6@ccdosh1.em.cdc.gov
  82.