Author: Jeremiah Penery
Date: 18:11:47 10/19/04
Go up one level in this thread
On October 19, 2004 at 19:51:17, Stuart Cracraft wrote: >On October 19, 2004 at 16:34:32, GeoffW wrote: > >>Hi Stuart >> >>Can you clarify what margin thresholds you used and was the distance to the leaf >>before or after you made a move ? >> >> Geoff > >Sure. Margins were 3 pawns for futility pruning at depth == 1 (before >the makemove), 5 pawns for extended futility pruning at depth == 2 >(before the makemove), and 9 pawns for limited razoring at depth == 3 >(before the makemove). > >In the first two cases, if found to prune, the node simply isn't searched >and skipped to the next move. In the last case, if found true, then the >depth is decremented for that move only by one additional ply. Do you know if the conditions are ever being properly triggered? In a depth 11 search on WAC 175 (a position I picked at random), I have these statistics in a modified Crafty with the pruning described below: Elapsed Time: 28.77, CPU Time: 27.62, CPU Use: 96% Root Material Balance: -200, Predicted Moves: 0 Nodes: 12146603, Evaluations: 9251784, FH%: 97%, NPS: 422k EXTENSIONS-> Threat: 174, Check: 679610, One Move: 21736 Passed Pawn: 920, Recapture: 24192 PRUNING-> Futility: 4329693, Razors: 405194 I implemented a variation of the Heinz/DT futility in Crafty (instead of returning a static score where pruning happens, I had it drop into qsearch for much more accuracy). I don't know how the node count compares to a regular version, or how much the savings for futility is. I'm sure someone else can run a default Crafty with futility on and off and report the exact differences.
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.