Author: Peter McKenzie
Date: 21:03:16 08/21/01
Go up one level in this thread
On August 21, 2001 at 21:01:56, Robert Hyatt wrote: >On August 21, 2001 at 16:58:30, Scott Gasch wrote: > >>Hi, >> >>I am thinking about time management these days. Currently I have rules that >>make the engine take extra time when it's just out of book or if it sees two >>fail lows during a search. It will also move faster if the root position is >>blocked and it's considering a move that won't help unblock it. >> >>Additionally it moves faster if it has a clear recapture (yes, I know this is >>dangerous but I have several safeguards in place and I have not been bitten by >>it yet). >> >>I have seen other engines that handle time differently, though. For example, I >>don't take extra time to resolve a fail high at the root. And with the "take >>extra time and resolve the fail low" rule, I only take a little extra time and >>will play without resolving if that time runs out. I have observed ferret >>seeming to take a bunch of extra time in these cases though. Should we always >>resolve root fail highs or fail lows? How important is this? >> >>Thanks, >>Scott > > >I don't resolve fail highs at the root either if I run out of time. I don't >see the point. > >But you did miss one important idea that has been around forever: don't time >out the search when partially thru analyzing a move at the root. And I mean >"any" move. IE once you start searching a move at the root (unless it is the >first move on a new iteration) and you run out of time, continue searching >until you finish this move. This is important. Because often on the last >iteration you will start a search on a non-first move, and if you have enough >time, you will change to that new best move. But only if you have enough >time. Make sure you do by not stopping until you search that move >completely. With null-move most of the time this happens instantly anyway, >so it costs you nothing. Occasionally you will discover that you can not >prune away things you could in previous iterations,b ecause this move is about >to become a new best move. Why stop until you know it is or it isn't??? > >easy to implement... Thanks for that Bob, it sounds like sound advice and it is something I don't do in my program. I plan on trying it ASAP though :-) cheers, Peter
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.