Re: 2.2.0pre4 detects a "166193960 Hz processor"

Kurt Garloff (K.Garloff@ping.de)
Fri, 8 Jan 1999 12:07:40 +0100

On Wed, Jan 06, 1999 at 04:30:48PM -0800, Russell Senior wrote:
> >>>>> "Chris" == Chris Wedgwood <cw@ix.net.nz> writes:
>
> >> Detected 166193960 Hz processor.
>
> Chris> I _seriously_ doubt it's that accurate -- we perhaps should
> Chris> only stick to 4 or 5 significant figures, beyond that I'm very
> Chris> skeptical... 166.2MHz in this case seems like a more logical
> Chris> claim.
>
> The number of digits doesn't have to imply the accuracy. I have
> listened to numerous physical scientists from the slide-rule era decry
> the excessive digits found in computer land. Usually it is a
> knee-jerk reaction. Sometimes those extra digits can be useful, and
> since throwing them away is an non-reversible process, sometimes
> keeping them is a good thing. I am not saying that this is one of
> those cases, just suggesting a thoughtful approach.
>
> IMO, the use of significant digits to imply the accuracy of a value is
> a kludge, loaded with the artifacts of arbitrary decisions. If an
> indication of accuracy is needed, there are better alternatives.

And still: Even if you specify the error, it may make sense to save one or
two digits more than your current accuracy, but not more. I'm talking about
statistical errors, here.
Another question is, when you have a systematic error and you want to calc
differences from several of these values, these might be much more accurate
as systematical errors affect all the values, and then you need the extra
digits.

Unless you specify the error by giving the std.dev. or whatever, the number
of digits is commonly considered to be an indicator fot the accuracy.
Somebody in a practical, reporting that the gravitational constant to be
6.6721058736e-11 Nm^2/kg^2, would have to correct this. If he could prove,
that the (abs.) error is 1e-16 or better, he would be a candidate for the
next nobel price, but I'd still tell him to only write 6.6721059 or (better)
6.672106 in his publication ...

For the kernel displaying the speed, I guess we have both a systematic error
(which remains constant when booting the kernel several times) and a
statistical one (temperature ...). But: Do you really want to compare the
speed reported between several boot processes?

I'd vote for XXX.YYY MHz
(without knowing what the error in this measurement really is. TSC is exact,
but what's with the timing base?)

Regards,

-- 
Kurt Garloff <kurt@garloff.de>                           [Dortmund, FRG]  
Plasma physics, high perf. computing              [Linux-ix86,-axp, DUX]
PGP key on http://www.garloff.de/kurt/        [Linux SCSI driver: DC390]


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/