Ray Dillinger scripsit: > If we're talking standards here we should just say "inexact real" and > not worry about how particular implementations represent those.
I don't want to say "inexact", precisely because 64-bit floats are losing precision all the time. I'll leave exact or inexact up to the implementor. > It is reasonable IMO to require a time library to report the > available precision. Fair enough. On Posix systems the precision is 1 microsecond. > In some circumstances a system clock can have a known inaccuracy, > but I don't think it's reasonable to anticipate and report all the > different forms that could take; one that I remember from a real > system was days/hours/minutes/seconds driven by a low-granularity > but accurate timer, with "fake microseconds" driven by a counter > on the machine's instruction dispatch. All you could say about > microseconds on that system was that a greater number meant a > later time, and that the machine would "usually" count up to > some "randomish" number between 600K and 700K microseconds > before dropping back to zero at the start of the next second > but "occasionally" the count might be as low as 400K or as high > as 950K depending on what the machine was doing, because some > instructions take fewer cycles than others. Right. Some years ago, I was running Linux under VMware with a Windows host, and at that time VMware and Linux interacted badly to make the software clock run much too fast. In order to keep time-of-day reasonably accurate, I set up a cron job to run once per minute that would grab the time (to 1 second precision) from the Windows host using RFC 858 protocol (port 37), with rdate(1) on the Linux side and some RFC 858 server, I forget exactly what, on the Windows side. The result was that the time was forcibly resynced 30-40 secondswards about 5-10 seconds after the start of each minute, thus sacrificing monotonicity in favor of long-term timekeeping. This had the potential to screw up make(1), but I don't think it ever actually did. -- There are three kinds of people in the world: John Cowan those who can count, [email protected] and those who can't. _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
