Certainly I found it a difficult and unrewarding feature to implement.diep wrote:Futility pruning is highly risky. If you test it well it will for most programs not work at decent time controls of course as compared to other forward pruning methods which prune more and better.
First there's the speed hit (and consequent Elo loss) from deciding whether each move is prunable.
Next, there's a loss of Elo due to pruning moves that would have given a cutoff. Thanks to Don for pointing out this loss can be quantified by fixed-depth matches.
Those losses have to be more than compensated by the improvement in average time-to-depth.
Also, it's not easy to tune the futility margins, partly because of the shape of the curve, but chiefly because the peak is Not Very Many Elo High.
Code: Select all
Elo + + + + 0 - - + - - - + - - - - - - - - + + + + + + + + + + + + FUTILITY_MARGIN
Yes, indeed. Really intelligent pruning would allow the margins to be set lower, thus improving time-to-depth. There's a limit on what you can do; preventing, for instance, forks from being pruned would be nice but too complicated and time-consuming.diep wrote:For futility pruning basically you can easily prove that one needs really lots of chessknowledge in the futlity decision
I have two bitboards (myAttacksTo and oppAttacksTo) with which some pruning decisions can be made a little more intelligent. Even so, futility currently gives me no more than 20 Elo.