Author: Ulrich Tuerke
Date: 00:48:48 05/02/00
Go up one level in this thread
On May 02, 2000 at 03:41:22, Christophe Theron wrote: >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 Thanks, sounds reasonable to me. So, in particular at very short time controls, I would expect that these effects could have some influence in blitz games where the uncertainty is relatively large compared to the time which is needed to search a root move, and Jouni played at rather short controls. I do not think, that these "quantum uncertainties" would be that drastic at tournament controls. Well, if Heisenberg knew ? Uli
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.