On Sun, Nov 28, 2010 at 6:59 PM, John Cowan <[email protected]> wrote:
> Thomas Bushnell, BSG scripsit: > > > So what I heard was that you wanted to represent an instant of time as > > an integer, with some determinate resolution, and then the predictable > > fight about whether the integer should be denominated in milliseconds, > > microseconds, or nanoseconds. > > Not at all. My proposal allows instants to be either exact or inexact > rationals. The question is, if you add 1 to a instant, do you get an > instant one second later (modulo leap seconds), or 1 ms later, or what? > This is neither accuracy, precision, nor resolution, but a fourth notion > which I will call scaling. When instants are integers, scaling and > resolution are the same thing, but not so when instants are allowed to > be non-integers. > Scaling is good: it says how much "1" is. But it has nothing to do with "resolution". Stop thinking about "integers". Integers are irrelevant; these are *real numbers *and the fact that some of them are integers is irrelevant. If the interface says "number of seconds since the epoch, not counting leap seconds" (which is what Posix's gettimeofday is), then let it be that. "Add 1" to the value means "add one second". The precision is about the precision of the particular numeric representation. The accuracy is a question of the system clock underneath, which is interesting to know but not determinable with Posix. So the interface should return seconds (naturally, since that's what Posix thinks in), and should promise to return a real number. Marc Feeley's arguments persuaded me to require inexact rationals as > the representation of instants. However, in practice these are 64-bit > floats, which means since the resolution varies with the distance of > the instant from the epoch, we currently (41 years after the epoch) can > get approximately 10^-5 resolution at best if an instant is a 64-bit > float, and it will get worse as time goes on. So I have removed the > recommendation to use inexact numbers. > Remember to separate the exactness of a numeric representation from the accuracy of the underlying clock. If the accuracy is 10ms (typical for lots of systems), then that does not mean it's pointless for the numeric representation to be exact. So I agree that there should be no recommendation about what sort of numeric format to use. Keep in mind that "inexact rational" does not mean "floating point" in Scheme. > Most clocks don't know their accuracy at all, never mind knowing their > accuracy accurately. > I think we should have a interface for it, but alas, Linux and Posix don't provide a way to get it. Given NTP and the granularity of clock interrupts, the accuracy is known in some sense to the system as a whole, but in practice difficult to determine. Thomas
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
