Author: Christophe Theron
Date: 00:41:22 05/02/00
Go up one level in this thread
On May 02, 2000 at 03:22:36, Ulrich Tuerke wrote:
>On May 02, 2000 at 01:10:58, Jouni Uski wrote:
>
>>About one week ago I posted "sensational" blitz Nunn test result Crafty17.10 -
>>Fritz6a 12-8. And I wasn't lying! Now I have more time to re-check and second
>>match ended 9 - 11 for Fritz. I also repeated two other matches with interesting
>>results:
>> 1. 2.
>>Crafty 17.10 - Lg2000 13 - 7 9,5 - 10,5
>>Fritz6a - Lg2000 13,5 - 6,5 11 - 9
>>
>>Exact enviroment: AMD 450Mhz, ponder of, 16+16MB hash, 4m+1s level, 3+4+some
>>5 piece TBs, Fritz6 interface, early resign.
>>
>>Conclusion: after 20 games You don't know much yet...
>>
>>Jouni
>
>With learn off, the games should be exactly reproducable (IMHO). Why should the
>search algo of either prog under the same pre-conditions produce another best
>move for any of the positions some time later?
>If you are right, then IMO either (or both) progs are kind of buggy, accessing
>some non-initialized data or similar ?
>Or does any body have anothe explanation ?
>
>Uli
The main problem is the way time is measured.
On the PC, the time functions only return multiples of 1/18.2 seconds. Even
functions that are supposed to return the current time in 1/1000 of s are not
accurate to the millisecond. They are accurate to approximately 5 hundreds of s
(1/18.2=0.054945...).
So depending exactly when you started a search inside a 1/18.2 seconds time
slice, searching exactly the same number of nodes could fall randomly just
before or just after another given 1/18.2 time slice.
So when you measure the time taken by a given search, always the same, you end
up with pseudo random results. A search that takes exactly 1 second can be
measured at 0.989s, or at 1.044s, and it depends if it started just before of
just after a clock tick.
The time allocation algorithm of a program could decide that if a search takes
less than 1 second, it will allow it to complete the next iteration. If it takes
more than one second, it will stop the search immediately and play.
In the case of our 1 second search, it will sometimes stop the search and play
after 1 second, and sometimes let the search continue for longer.
There is no way to avoid this problem. Even with a millisecond-accurate timer.
Even if you can measure the time up to the microsecond.
Random events such as mouse moves, hard disk saving mode and autoplayer random
lags only make this problem worse.
This is not a bug. You can call this a "quantic" problem. :)
Christophe
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.