Author: Bertil Eklund
Date: 04:39:03 05/02/00
Go up one level in this thread
On May 02, 2000 at 03:48:48, Ulrich Tuerke wrote: >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 Hi! I have played a few 1000 games with Comet (most in DOS). There is two programs that never seems to repeat a lost or won game and it is Comet and Nimzo. I thought it had something to do with the hash-tables. Or do you you use some random element to choose moves? Rebel always plays the same if the conditions are equal but never Comet or Nimzo. Bertil
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.