Author: Peter Fendrich
Date: 03:02:23 04/14/04
Go up one level in this thread
On April 14, 2004 at 05:14:39, José Carlos wrote: >On April 14, 2004 at 03:32:17, Peter Fendrich wrote: > >>On April 14, 2004 at 02:21:41, Christophe Theron wrote: >> >>>On April 14, 2004 at 00:26:34, Eric Oldre wrote: >>> >>>>After you find the 1st "good" move don't you narrow the alpha beta window so >>>>that you don't know how much worse the 2nd move is, only that it is not as good >>>>as alpha? >>>> >>>>Or do you not narrow the window at the root node? that seems like it would >>>>greatly expand your search tree. >>>> >>>>or am i missing something else? >>>> >>>> >>>>On April 14, 2004 at 00:09:24, Robert Hyatt wrote: >>>> >>>>>Simple idea: >>>>> >>>>>a move is "easy" and can be made after using less than the planned time limit if >>>>>and only if >>>>> >>>>>1. estimated score for first root move is way higher than the second move. IE >>>>>say 2.00 better. >>>>> >>>>>2. This is a recapture. IE opponent just captured a piece of ours and we are >>>>>recapturing on the same square. >>>>> >>>>>Other types of "easy" moves have higher risk to stop the search early... >>>>> >>>>> >>>>>> >>>>>>Thanks, >>>>>>Eric Oldre (new chess programmer) >>> >>> >>> >>>I think that by "estimated score", Bob means the score returned by a SEE (Static >>>Exchange Evaluator), not by a real search. >> >>I shouldn't tell what Bob means but I doubt this is right... >>I wouldn't rely on a SEE for such decisions when the first few iterations will >>give you a much more reliable score quite fast and you could use the score for >>previous move in the game as a staring point. >>If the score fulfills the conditions mentioned by Bob from the first iteration >>and up to lets say 1/2 the total time alotted for that move then stop and make >>the move. (Given that the time allocated for a move is just a function of >>remaining time and number of moves left) >>/Peter > > Hi Peter. Remember that you need an open window to compare score. As most >programs use null windows for non pv nodes, you can't use the scores of the >first iterations, unles you want to avoid PVS until iteration n. > I use a QSearch with (-inf,+inf) window for all nodes at the root before >starting iterative deepening. If I find a "singular" move there (meaning clearly >better than all others) and this is the move stored in the hash table for the >root position, I flag it as "probably easy move". Then I start iterative >deepening. If, at some point, a non pv move fails high at the root, I remove the >flag. Otherwise, after 1/10 of the allocated time, when I finish searching the >current iteration at the root, I check if the PV move is equal to the "probably >easy move". If so, I make that move. > > José C. I'm not sure I understand. Maybe we mean the same thing. Here is my procedure: I wan't the first move, at least, in each iteration to give a reliable score within [alpha,beta]. That means a wider window for the first move in each iteration but in iteration 1 I use [-inf, +inf] for all moves. Each iteration (except iteration=1) starts with the best move searched with alpha=score-MARGIN and beta=score+MARGIN. Hopefully the search is within alpha/beta otherwise re-search with a wider window is required. So I have the best move and it's score from the first iteration up till now and can make decisions about "easy" moves. /Peter
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.