[Haskell-cafe] Re: System.CPUTime and picoseconds

Mauricio briqueabraque at yahoo.com
Mon Jan 12 05:46:58 EST 2009

Aren't Doubles evil? Integer is a nice type, Haskell
filosofy compliant. Doubles are not CDoubles, IEEE, infinite
precision or anything long term meaninfull. (Warning:
non-expert opinion.)

> 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
> On 12 Jan 2009, at 00:00, Lennart Augustsson wrote:
>> On Sun, Jan 11, 2009 at 8:28 PM, ChrisK 
>> <haskell at list.mightyreason.com> wrote:
>>> An Double or Int64 are both 8 bytes and counts with picoseconds 
>>> precision
>>> for 2.5 hours to 106 days.  Going to 12 byte integer lets you count 
>>> to 3.9
>>> billion years (signed).  Going to 16 byte integer is over 10^38 years.
>>> Lennart Augustsson wrote:
>>>> A double has 53 bits in the mantissa which means that for a running
>>>> time of about 24 hours you'd still have picoseconds.  I doubt anyone
>>>> cares about picoseconds when the running time is a day.
>>> The above is an unfounded claim about the rest of humanity.
>> It's not really about humanity, but about physics.  The best known
>> clocks have a long term error of about 1e-14.
>> If anyone claims to have made a time measurement where the accuracy
>> exceeds the precision of a double I will just assume that this person
>> is a liar.
>> For counting discrete events, like clock cycles, I want something like
>> Integer or Int64.  For measuring physical quantities, like CPU time,
>> I'll settle for Double, because we can't measure any better than this
>> (this can of course become obsolete, but I'll accept that error).
>>  -- Lennart
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list