Author: KarinsDad
Date: 21:51:31 01/16/04
Go up one level in this thread
On January 16, 2004 at 15:17:32, Bob Durrett wrote: >On January 16, 2004 at 14:38:33, KarinsDad wrote: > >>I think a good time management function would take into account the amount of >>time remaining, the evaluation of the current position, the amount of material >>(especially non-pawns) remaining on the board, and the average number of moves >>per half ply. >> >>Being up a knight in the opening (once out of book) might equate to the same >>overall evaluation as in the endgame (pre getting into egtbs), but a program >>might be able to use less time to search in the endgame, the programmer knowing >>that even second or third best moves will probably end up in the same overall >>result (i.e. winning or losing the game). For example, KNPKP is hard for the >>advantaged side to draw or lose the majority of the time even without an egtb. >> >>The converse is also partially true. The fewer pawns on the board, the more >>legal moves (as long as there are multiple major pieces on the board) and hence, >>the more nodes to search per half ply. >> >>It would seem that the best use of time is to search more when there are more >>possibilities and to decrease those number of possibilities whenever possible as >>long as the program is still making very good moves (especially when winning), >>just as insurance. > > >It seems to me that the above is some good thinking on this topic. Thanks. >Two details: > >(1) How to take into account non-engine time usage? Example: tablebases EGTBs result in (effectively) perfect evaluation at a given node without need for further searching. Hence, they speed up the evaluation (assuming hard disk access if necessary is faster than searching further at that node), allowing the program to either search further with the extra time it has (e.g. if you search until a set pre-calculated time runs out), or to finish its searching quicker (e.g. if you pre-calculate a number of nodes to search before quitting or quit on a significant increase in evaluation) which in turn gives it more time for future moves. >(2) If behind on the clock, how to get caught up before it's too late? [or does >it really matter if behind?] It depends on if you are winning or losing I would think. If losing, it doesn't matter. The game is lost, so searching deeper on a given move will probably not change that outcome. It might be difficult to determine within the program which positions are worth searching deeper and which are not anyway. So, speeding up the pace could be used regardless of whether there is a perfect move at one given position which turns the tide of battle. Either the program will find it (accidentally or not), or it will not. In either case, the game was lost, so extending the game as long as possible in order to possibly stumble into a draw seems preferable to eating up all of the time and dive bombing at the end. If you are winning, then what matters is whether you have a quick win (few moves remaining) or a slow one (many moves remaining). With a quick one (i.e. one where you get into EGTBs quickly or where even mediocre moves will still quickly win the game, e.g. up a queen), the program can easily play at the original pace or possibly a slightly sped up pace and still win. With a slow win (e.g. up a pawn with a better position and few major pieces on the board), there could be good delaying tactics that the opponent could play to eat up the time. The game could be drawn out an additional 60 moves or something. If you can detect this situation, the time management may have to speed up significantly in order to have enough time later on in the game (assuming a game with no addition time per move). The problem here is that you do not want to speed up the program so much that it starts making significantly inferior moves and ends up giving up its win. A drawn game is probably like a slow win. So, I guess my advice here it so adjust the time management to speed up (i.e. search fewer nodes) unless the win looks quick (in which case normal time management should often suffice).
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.