Author: Uri Blass
Date: 03:06:32 08/18/01
Go up one level in this thread
On August 18, 2001 at 03:58:56, Harald Faber wrote: >On August 17, 2001 at 12:16:57, Uri Blass wrote: > >>On August 17, 2001 at 11:49:55, Harald Faber wrote: >> >>>On August 17, 2001 at 08:04:42, Chris Taylor wrote: >>> >>>>Deep Shredder v Century 3.2 >>>>I restarted the computers after the first game and then played the second. >>>>The first game Century 3.2 was the master, second game Deep Shredder was master. >>>>Century had an Athlon 800, 200Mb hash own book, default peronality >>>>Deep had a PIII 733 256Mb hash, Shredder.bkt, 3,4,5 Nalimov endgame bases. >>>> >>>>Shredder provided the pgn..... >>>> >>>>Chris Taylor. >>>> >>>>[Event "180 Minutes/Game"] >>> >>> >>>That is another reason why testing with Century is not satisfying at all. There >>>is no chance to setup the time control to 40/120+60. And I have seen Shredder >>>perform much better on tournament time controls than on blitz level, even if >>>g/180. >> >>g/180 is slower time control than 40/120+60 >> >>if the time control is g/180 you can assume that the time control is 40/120+60 >>without losing on time. >> >>If the time control is 40/120+60 you may lose on time oif you assume time >>control of g/180 >> >>Shredder should perform better or at least the same at 40/120+60 and it is not >>the fault of the customers if stefan did not work on telling the computer to use >>time in a logical way. >> >>I know also that a lot of programs play better at 3 hours per game and not at 3 >>hours per 200 moves and it is again an illogical decision. >> >>I think that people have the right to play tournaments at the time control that >>they choose and if a program is suffering from it's illogical time management >>then it is only the fault of the programmers. >> >>I do not understand the reason that programmers do not think about the simple >>rule of using more time when the time control is slower. >>This is the first thing that I expect programmers to think about when they add a >>new time control option. >> >>If the programmers let their program to play at some time control they should >>expect people to use this time control. >> >>Uri > >The problem with g/180 is that the program does not know how many moves to make >until the games is decided. So it might move a lot faster in the first moves. >If you take 40/120 and play 20 moves out of the book, you have 120 min for 20 >moves which will be more than the engine will spend at g/180. Tiger e.g. is a >program which needs a lot of time between move #20 and #30-35, compared to the >opponent. I understand what happens. I think that the most logical decision when a programmer is develop a program is to start with simple time control of x minutes per game. When you add your program a new time control like 120 minutes for 40 moves+ 60 minutes for the rest of the game the most logical decision is to start to think on extreme cases that I give later in my examples. I know that a lot of programs simply divide the number of minutes to the time control by the number of moves to the time control but it is a wrong decision. It is going to lead to bad decisions examples: case 1:a program has 2 hours for the next 200 moves+1 minute for the rest of the game. It is going to play too fast. case 2:a program has 2 hours for the next 10 moves and 1 minute for the rest of the game. It is going to play too slow. In both of these cases the program should use at least the same time that it use when the time control is 120 minutes per game and at most the same time that the program use when the time control is 121 minutes per game. It is not hard to teach programs to do it and I find it surprising that almost no programmer does it. Uri
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.