Author: Pham Minh Tri
Date: 23:43:17 08/29/01
Go up one level in this thread
On August 29, 2001 at 22:09:20, Stuart Cracraft wrote: >So here is a pseudo-code fragment the attempts to implement >futility cutoff but fails. The result is 2.67% less time for the >same search and 4.35% fewer nodes, a far cry from what I heard >it would do. So what's wrong with it? > >for all moves (sorting, etc.) > make move (backup if move leaves king in check and proceed to next move) > # Futility code follows > if side that moved was not in check before move AND > depth == 1 (i.e. 1 move until quiescence search, the "frontier") AND > no extensions so far at this node AND > this is not a principal variation node AND > this move was not a capture AND > side now on move is not in check AND > ((material difference between side on move before move and side now on move > PLUS the maximum of (maximum positional score of side not now on move, > value of a knight) <= alpha) then > unmake the move just made > continue with next move (bypassing this move, i.e. the futility cutoff) > endif >: > search move normally as usual >end > >Stuart I did not see where your qsearch is after pruning. You seem to prune too much. You should prune the last depth, but not qsearch, IMO. BTW, I prefer use Eval function to use material only (learn from Crafty 1.5x). It is safer.
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.