[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme

On Mon, Nov 29, 2010 at 2:15 PM, John Cowan <cowan@x> wrote:
Thomas Bushnell, BSG scripsit:

> 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.

Anything described as "number of seconds" is evidently an integer,
since we count things with integers.  And yet you say not to think
about integers.

I think that's a problem with English grammar and the mass/count noun distinction. :)

How about "seconds since the epoch", stripping "number of" off the beginning.  If I say "how many miles long is the equator", I am happy with an answer of "24860.2".
> 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.

In principle, no; in practice, it definitely does.  There are no Schemes
out there which use something other than floats for inexact rationals,
and the great bulk of them use 64-bit IEEE floats only.

But this is Scheme, not C. We need to make sure things can be implemented with reasonable efficiency, but we do not want to eliminate the possibility of yet more interestingly advanced implementations. The Scheme standard has the great bounty that it separates implementation from semantics for numbers. We don't want to reverse that wonderful boon! We must think meaning, not representation.
> 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.

It sounds like you are talking about precision, not accuracy.  If the
clock is off by a day because I botched setting it, do you expect the
system to know that and report it?

Yes. "Given NTP and the granularity of clock interrupts", I do expect it.


Scheme-reports mailing list