On 13 April 2013 21:36, Levente Uzonyi <le...@elte.hu> wrote: > On Sat, 13 Apr 2013, Igor Stasenko wrote: > >> >> Both #timeToRun and secondsWhenClockTicks (via Delay) using same primitive >> - #millisecondClockValue. >> Sure thing, precision of this primitive should be it is 1 millisecond >> or smaller.. >> But it has nothing to do with precision of primSecondsClock and you >> cannot increase precision of >> it using #millisecondClockValue. > > > The only thing I wanted to point out is that the value of #primSecondsClock > changes when the actual second changes (the difference is less than 1ms). So > while its resolution is just 1 second, it's accuracy is better than 1ms. > Here's another example using the microsecond clock: > > > (1 to: 10) collect: [ :e | > | start | > Time secondsWhenClockTicks. > start := Time primUTCMicrosecondClock. > Time secondsWhenClockTicks. > Time primUTCMicrosecondClock - start ]. "==> #(1000136 999914 > 999961 999926 1000029 999988 999991 999985 998089 1000034)" >
My gut feeling that here you are rather measuring accuracy of 1ms Delay operation (in secondsWhenClockTicks method). by sampling it using system time function. Because for both primitives (primUTCMicrosecondClock and primSecondsClock) the source is system time. But Delay, inside also uses system time at some point... so, here we're trying to reason about how to measure accuracy of some function (which stays behind all of these) by using very same function.. I am not genius in rules of correct measurement, but doesn't it sounds silly to you? > >> >> Because this code: >> >> [ lastSecond = self primSecondsClock ] whileTrue: [ (Delay >> forMilliseconds: 1) wait ]. >> >> actually means: >> >> [ lastSecond = self primSecondsClock ] whileTrue: [ block not less than 1 >> ms ]. >> >> but not: >> >> [ lastSecond = self primSecondsClock ] whileTrue: [ block exactly 1 ms ]. >> >> the upper bound of "(Delay forMilliseconds: 1) wait" is undefined.. >> and you know it well. > > > Of course Delays are not ideal here, but there was nothing better to use > when the code was written. As you can see in the above example, in 1 out of > 10 cases the difference was less than 999 ms. > > > Levente > > >> >>> >>> About DateAndTime: having it nanosecond resolution is a future proof >>> idea. >>> It will take a while till software can create better accuracy timestamps. >>> Reducing the resolution to milliseconds is a very bad idea. The VM and >>> external software can give you a microsecond or smaller resolution >>> timestamp >>> which you want to represent as DateAndTime (or whatever class you use to >>> create a timestamp) in the image. >>> >>> >> Yes i know. My problem is the amount of code which does something >> "userful" with nanoseconds >> while everybody knows that we have no such resolution.. and won't have >> in 10 years or so. >> >>> Levente >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > -- Best regards, Igor Stasenko.
