Neil Davies wrote:
I've found the pico second accuracy useful in working with 'rate
equivalent' real time systems. Systems where the individual timings
(their jitter) is not critical but the long term rate should be accurate
- the extra precision helps with keeping the error accumulation under
control.
When you are selling something (like data bandwidth) and you are pacing
the data stream on a per packet basis you definitely want any error to
accumulate slowly - you are in the 10^10 events per day range here.
Neil
Now I am posting just because I like to look at the time scales.
A rate of 10^10 per Day is a period of 8.64 microseconds.
If you want to slip only 1 period per year then you need a fractional accuracy
of 2.74 * 10^-13. In one day this is a slip of 23.7 nanoseconds.
So atomic time radio synchronization is too inaccurate. I have seen GPS
receivers that claim to keep the absolute time to within 100 nanoseconds.
Lennart is right that 1 picosecond accuracy is absurd compared to all the
jitters and drifts in anything but an actual atomic clock in your room. But
since CPUs tick faster than nanosecond the CPUTime needs better than 1
nanosecond granularity. I agree with Lennart — I also want an Integral type; it
keeps the granularity constant and avoids all the pitfalls of doing math with a
Double. Out of simplicity I can see why the granularity was set to 1 picosecond
as it is slightly easier to specify than 100 picosecond or 10 picosecond or 1/60
nanosecond (hmmm... arcnanosecond?).
Maybe Haskell should name the "1/60 nanosecond" unit something clever and create
a new Time submodule using it for April 1st. [ Base 60 is the real standard:
http://en.wikipedia.org/wiki/Babylonian_mathematics has an 1800 B.C. tablet with
the (sqrt 2) in base 60 as (1).(24)(51)(10) ]
--
Chris
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe