Date: Fri, 26 Oct 2001 14:25:00 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG, Peter Wemm <peter@wemm.org>, Bakul Shah <bakul@bitblocks.com> Subject: Re: 64 bit times revisited.. Message-ID: <200110262125.f9QLP0u38719@apollo.backplane.com> References: <8186.1004131036@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
:> For example, the representation of a nanosecond is 2^64/1E9 =
:> 18,446,744,073.7. If you add two 1 nanosecond values together, you don't
:> get 2 ns.
:
:I think I see your anti-phk reflex kick in here, but let me answer anyway:
:
:Any physicist or engineer knows something about "significant digits"
:and that applies here as well. You don't add two nanoseconds
:together. If your numbers are in that range, you add some multiple
:of 1/2^64 s together, and the rounding errors will be totally
:insignificant.
This isn't how it works, Poul. FP implementations which use base-2
representations actually calculate an extra digit (at a minimum),
and quite often much more then that, and then round the result that you
see. Even base-10 representations do that, though they don't need to
for a certain subset of operations such as addition and subtraction
(which are the most common).
Unless you intend to do the same manually for EVERY SINGLE OPERATION
you do with your fixed point representation, you've just screwed us.
This is not physics we are talking about, it is basic math.
The computer may be base-2, but humans are base-10. If you are
going to introduce a numerical system that is either (1) always generates
errors for both human manipulation and machine representations or
(2) only generates errors for machine representations, then (2) is the
better choice.
The only completely correct machine representation is 'clock cycles' or
'ticks'. Great... but not portable, so we can't use it unless we
introduce a whole new way of thinking. And even then we are screwed
because now the user cannot depend on a minimum level of precision (even
if it winds up only being statistically aggregated precision).
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110262125.f9QLP0u38719>