Author: Uri Blass
Date: 07:04:54 12/27/05
Go up one level in this thread
On December 27, 2005 at 08:41:53, Ernst Walet wrote:
>[Event "Blitz:110'"]
>[Site "?"]
>[Date "2005.12.27"]
>[Round "?"]
>[White "Spike"]
>[Black "Rybka 1.0 Beta"]
>[Result "*"]
>[ECO "E39"]
>[PlyCount "11"]
>[TimeControl "6600"]
>
>{1024MB, Rybka_Paderborn.ctg, PC} 1. d4 {[%emt 0:00:00]} Nf6 {[%emt 0:00:00]}
>2. c4 {[%emt 0:00:13]} e6 {[%emt 0:00:00]} 3. Nc3 {[%emt 0:00:08]} Bb4 {
>[%emt 0:00:00]} 4. Qc2 {(f3) [%emt 0:00:09]} c5 {[%emt 0:00:00]} 5. dxc5 {
>[%emt 0:00:10]} O-O {[%emt 0:00:00]} 6. a3 {[%emt 0:00:11]} *
>
>and Rybka out of book.
I see this mistake again and again
Why time control 6600 and not 6000?
It assumes only 10 minutes of operator time and it cause problems in long games
See fruit-isichess when fruit had good chances to win the game but drew(maybe
because of time trouble but even in that case I think that it is a mistake of
the operator because I think that the difference between 100 minutes per game
and 110 minutes per game is probably 7 elo rating points without pondering and
with pondering even less than it and long games happen enough to justify it.
It seems to me that near 2% of the comp-comp games have more than 150 moves and
winning them on time instead of drawing including winning on time some games
with 100-150 moves may give clear compensation for the 10 minutes.
Note that I think that no draw should be agreed and even if a program lose on
time in tablebase draw then it should be the fault of the operator that did not
give it enough time in the beginning of the game.
alternatively game with small increasment should be used to prevent losing on
time.
Uri
This page took 0.01 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.