[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