Author: Stuart Cracraft
Date: 07:10:47 10/16/04
Go up one level in this thread
On October 16, 2004 at 03:34:43, Alessandro Damiani wrote: >On October 14, 2004 at 10:28:16, Stuart Cracraft wrote: > >>I don't think I'm implementing it properly because my node >>reductions are not happening. >> >>My implementation is based on Ed Schroder's comments on >>page 8 of his comments (Search Techniques in Rebel (Futility >>Pruning) >> >> >> makemove >> if depth == 1 (i.e. one more ply for sarch) >> if side just moved king was in check before the move or >> if side on move king is in check after the move or >> if move is a capture or >> if (alpha < material[sideonmove]-material[sidejustmoved]+ >> pcsq[sideonmove]-pcsq[sidejustmoved] + 3 pawns) >> then do normal search with depth-1 >> but if all of the above are true then unmakemove and >> return material[sideonmove]-material[sidejustmoved]+ >> pcsq[sideonmove]-pcsq[sidejustmoved] >> >> as well as the above but with depth == 2 and 5 pawns instead of 3. >> >>The only thing I can think of doing is not doing the makemove at >>the top and doing it only if the futility is avoided due to one >>of the conditions being true. >> >>Stuart > >Right. You are making the move and then checking if you can return an >approximation of the static score. But then you already are at the horizon. What >you save then is only the full blown static evaluation plus quiescence search, >the cost of make and unmake is still there. You should do your check *before* >you make the move. > >Alessandro True but then I have to give up making the check on whether the move put the other king in check. Isn't that a requirement of futility pruning? Stuart
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.