Author: José Carlos
Date: 03:15:26 04/14/04
Go up one level in this thread
On April 14, 2004 at 06:02:23, Peter Fendrich wrote: >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. I think we do the same here. >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 Ok, then I think I misunderstood you. I though you wanted to compare pv move score with all the other moves score for n iterations, but if I understand you, you compare it in iteration 1 and make sure it continues to be the best move for n iterarions. Pretty much what I do. José C.
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.