Author: Christophe Theron
Date: 10:46:15 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.
That's right, you'll see this happening more in blitz games.
It adds some random balanced noise to the result. I mean that it does not give
an advantage to only one of the opponents. You just need to play more games in
order to eliminate this noise.
Christophe
> 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.