harrison@necssd.NEC.COM (Mark Harrison) (07/29/90)
In article <152@srchtec.UUCP>, johnb@srchtec.UUCP (John Baldwin) writes: > In article <1990Jul21.191009.14229@newcastle.ac.uk> > Chris.Holt@newcastle.ac.uk (Chris Holt) [in response to me] writes: > > ... many people still think if you have digits of precision, that > >those digits are necessarily meaningful. A garbage number is worse than > >a very imprecise one *because* it is misleading. > > Very well-said. --john b.--- An interesting example of this appeared in Byte several years ago. The reviewer was reviewing a statistics package for the Mac, which had a feature that as significant digits were lost, they were "grayed out." The reviewer was quite surprised when some statistical models he had been using for some time returned results that were entirely "grayed out." A similar story concerns Boeing, when they moved from an IBM to a VAX. Their programs started aborting in the VAX trig functions with a "Total loss of precision" error, which the IBM system had not reported. -- Mark Harrison harrison@necssd.NEC.COM (214)518-5050 {necntc, cs.utexas.edu}!necssd!harrison standard disclaimers apply...
mcgregor@hemlock.Atherton.COM (Scott McGregor) (07/31/90)
In article <399@necssd.NEC.COM>, harrison@necssd.NEC.COM (Mark Harrison) writes: > In article <152@srchtec.UUCP>, johnb@srchtec.UUCP (John Baldwin) writes: > > In article <1990Jul21.191009.14229@newcastle.ac.uk> > > Chris.Holt@newcastle.ac.uk (Chris Holt) [in response to me] writes: > > > ... many people still think if you have digits of precision, that > > >those digits are necessarily meaningful. A garbage number is worse than > > >a very imprecise one *because* it is misleading. > > > > Very well-said. --john b.--- > > An interesting example of this appeared in Byte several years ago. The > reviewer was reviewing a statistics package for the Mac, which had a > feature that as significant digits were lost, they were "grayed out." > The reviewer was quite surprised when some statistical models he had > been using for some time returned results that were entirely "grayed out." This brings up a very good point. If the only level of precision you have is an order of magnitude, give it that way. Don't say "the mean estimate for completion time is 516.33333 engineer hours" when what you mean is that expected completion time will fall somewhere in the hundreds of hours. Say instead "the project will take somewhere between one hundred and one thousand hours, I can't be more precise than that at this time with current information." Or if you are even more uncertain, say "somewhere between one hundred and TEN thousand hours...". When people see the extra digits, it contributes to their misunderstanding of of level of accuracy available. Even most statistically savvy people are tempted to expect more when nonsignificant digits are given, the average less statistically inclined person is even more vulnerable. One of the ways that people have dealt with this sort of uncertainty in the past was to choose units that forced the nonsignificance out of the picture. An estimate of "7530 feet plus or minus 2525 feet" (2 sigma variance) might be described as "about a mile or two". When the unit was miles, no one made much thought about the precision at the level of feet and that lead to more *accurate* expectations about the imprecision of the underlying estimate. Maybe we should start using deca-engineer-weeks, etc. Scott McGregor mcgregor@atherton.com