[TIP] Result protocol / problems being solved

[Scott David Daniels]

Jesse Noller wrote:
> On Apr 13, 2009, at 11:40 PM, Scott David Daniels  
> <Scott.Daniels at Acm.Org> wrote:
>
>   
>> laidler at stsci.edu wrote:
>>     
>>> 5. I want to be able to do statistics on my test results.
>>>
>>> Implications: include start&stop times along with host/execution  
>>> environment; allow a way to associate arbitrary quantities of  
>>> interest with a test result.
>>>
>>>
>>>       
>> The reason I like start & duration rather than start and stop is that
>> duration may be available with far more precision than something
>> capable of providing date and time.  I'm not saying it will always
>> be provided.
>>
>> --Scott David Daniels
>> Scott.Daniels at Acm.Org
>>
>>
>>     
>
> How is a time.time() call not precise for start and stop
>   
On Windows, time.clock() has higher precision than time.time()
It returns ime in seconds (so is in some sense compatible), but uses a 
counter
that doesn't get time adjustment the way the date & time-of-day do
(time.time() has better synchronization with the atomic clock, but at
the cost of local adjustments.  If your timing interval covers one of those
adjustments, the timing on that measurement will be mis-measured (and
may even be negative).  I imagine the first cut at all of this will not
care about this and similar details, but in instrumenting over time,
I think in the long run we'll be better off in a format that allows for
specialization to accommodate the difference in the two measures.

--Scott David Daniels
Scott.Daniels at Acm.Org