Possible VB6 Timer function bug?
in [Visual Basic]
|
From: tbone on 16 Mar 2010 14:08 I am using the VB6 Timer function and have found something that seems strange. My CheckExpiration function takes the prior timer value and a timespan, and returns whether the timespan has transpired. The top of the function looks like this: Private Function CheckExpiration(ByVal LastTime As Single, _ ByVal TimeSpan As Single) As Boolean Dim diff As Single, r As Boolean r = False ' assume timer has not expired yet diff = Timer - LastTime ' compute time difference What I've found is that fairly often, time seems to slip backwards; i.e. diff is negative. This is not the once-a-day case where just after midnight the value of Timer is expected to be less than the base time. What I see is a very small negative time span, like -1.84375E-03 seconds. What makes me think this is an anomaly is that if I slightly alter the code to that shown below, the problem disappears: Dim t as Single, diff As Single, r As Boolean r = False ' assume timer has not expired yet t = Timer diff = t - LastTime ' compute time difference Now, I never see time slip backwards except at midnight. Any ideas? BTW, can someone also explain what I might see when Windows (in this case XP) effects an adjustment in the system time when the PC's clock is corrected by contacting the time server? Thx tbone P.S. Thanks to Mike Williams for his post in comp.lang.basic.visual.misc for cluing me in to this group!
From: Saga on 16 Mar 2010 15:26 "tbone" <noneedto(a)email.me> wrote in message news:rfhvp5dsh8ta6eciio99emb3q59eh5nua9(a)4ax.com... > diff = Timer - LastTime ' compute time difference > > What makes me think this is an anomaly is that if I slightly alter the > code to that shown below, the problem disappears: > > Dim t as Single, diff As Single, r As Boolean > r = False ' assume timer has not expired yet > t = Timer > diff = t - LastTime ' compute time difference What I see is that in the second code snippet you take a "snapshot" of the time and base the calculation on that while in the first snippet you are basing your calculation on a dynamically changing item. Perhaps this is what is causing your glitch. Regards, Saga
From: Horst Heinrich Dittgens on 17 Mar 2010 09:32 > Now, I never see time slip backwards except at midnight. Any ideas? I'm not a compiler expert, but I could imagine that in "diff = Timer - LastTime" the value for timer is evaluated due to optimization by the compiler *before* the function is executed while in "diff = t - LastTime" the value for t "t = Timer" can be assigned only after the variable t is established, and assigning memory space for variables using DIM statement is done at run time/execution. If I'm right defining variable 't' as a global variable eventually migth allow the second version to evaluate timer also at compile time. > BTW, can someone also explain what I might see when Windows (in this > case XP) effects an adjustment in the system time when the PC's clock > is corrected by contacting the time server? Each time the 'time' function is called it returns the active system time, so if a time correction applies the difference between two subsequent time calls might even become negative. I'm pretty sure that time resettings can be caught by system interrupts just like interrupts indicating changed screen resolution.
From: Patrice on 17 Mar 2010 10:51 Also floating point values are known for being not always very accurate. So if you get the timer value twice very quickly, it could be perhaps caused by this approximation (i.e the value you get is slightly rounded up, the second one is slightly rounded down and if the elapsed time between them is not greater than those cumulated rounding errors, then the first value will be lower than the second one)... Just a guess. -- Patrice
From: Horst Heinrich Dittgens on 18 Mar 2010 05:33
> Also floating point values are known for being not always very accurate. > So if you get the timer value twice very quickly, it could be perhaps > caused by this approximation (i.e the value you get is slightly rounded > up, the second one is slightly rounded down and if the elapsed time > between them is not greater than those cumulated rounding errors, then the > first value will be lower than the second one)... Which kind of mathematics does teach that from two almost identical values the greater one can be rounded to a smaller number than the smaller one :-) ? The only thing where floating points are not 'accurate' is when converting numbers from integer, long, and so on into reals or doubles. Then the floating point number does not match exactly the value of the unconverted one. And of course, working on with rounded values therefore might end up in significant differences to working on with integer computations. |