Author: Ulrich Tuerke
Date: 05:14:58 05/02/00
Go up one level in this thread
On May 02, 2000 at 07:39:03, Bertil Eklund wrote: >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 That's not a surprise, because Comet has a positional learning implemented, using a file on disk. I think, that I have heard that the same is true for Nimzo. These are file with the extension .lrn if I remember right. 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.