Concerning Time.TimeDiff

Ketil Z. Malde ketil@ii.uib.no
19 Jun 2003 15:11:36 +0200


Graham Klyne <GK@ninebynine.org> writes:

> On any hardware than I'm familiar with, processing rationals, or
> unlimited precision numbers, is significantly more expensive than
> using the native machine capabilities.

This was, sort of, a concern I tried to raise: using Integer with
ps, makes for some large quite numbers (and Integer is of course
slower with large numbers than with small ones)

> If the view is that Haskell is primarily for writing programs that are
> provably correct in all conceivable circumstances, then the case for
> using rational time values is clear.

I don't think we should sacrifice correctness, it is a far greater
problem for much more code, than speed is.

> My point is that seconds and picoseconds, represented using 64 bit
> binary values, 

Well, my main problem with representing time as a pair, is that a
point in time isn't uniquely defined (e.g. should it be 3s + 5e-11ps,
or 2s + 5e-11ps), and that, in most suggested formats, they overlap
(e.g. 3s or 2s + 1e12 ps).  So you need to normalize -- possibly after
each operation.  Are you sure this is more efficient than using
bignums? 

Further, I'm not sure Haskell has a standard 64 bit Int.  I'm fairly
sure it's in GHC, and probably in the other compilers, but it'd be
nice if it were in the standard.  On the other hand, Integer can be
implemented any way that's efficient on each architecture.

> I find it hard to lose sleep over missing leap-seconds and dates beyond

Leap seconds are a completely orthogonal issue.  From the discussion
here, it seems plain that UTC is a kluge, and TAI is the way to go.
In any case, we already agree to counting seconds, the question is how
to count them :-)

> And the cost of supporting all this may be trivial in practical
> terms -- I don't have a good handle on that, but I'll comment that
> time calculations might be a significant computational burden for a
> real-time system dealing with high event rates (and I think we'll
> see lots of these applications).

Could you be more concrete?  I don't think I know any system that
spends a significant amount of time calculating dates.  Some systems
that deal with time (GPS, NTP), mostly care about differences, and are
happy to have the clock roll over relatively frequently.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants