diep wrote:Edmund wrote:On the Chess Programming Wiki,
Futility+Pruning
there is written the following:
Futility pruning is not used when the side to move is in check, or when either alpha or beta are close to the mate value, since it would leave the program blind to certain checkmates.
From my understanding, Futility Pruning is used in likely fail low nodes. And being in check just increases the likelihood to fail low. So I don't think this should be a criterion.
Concerning the mate-scores, if beta is close to -Mate,
will never be true, unless you have mate detection in eval and margin is very small.
Anyway I do agree that in nodes where beta is close to +Mate, certain mates could be falsely pruned.
Very simple. Download crafty source code.
Compile it. Play 200 games with it at 30 30 level or something against other engines.
Add your pruning idea, so ONLY prune when in check using futility.
Play 200 games.
Conclude what is better.
p.s. diep cannot evaluate when it is in check (of course), so i'll skip this idea for Diep as i wouldn't be able to determine a futility margin small enough to prune any move at all.
The issue is not pruning only in check but additionally if already pruning elsewhere. Pruning legal moves in check implies no checkmate. It is not that hard to determine legal quite king moves if in check, so this is not really a legal versus pseudo legal movegen issue, for instance to miss a mate after pruning an illegal move, while there were no legal.
For a in check eval score take either -eval from parent, delta move and some margin
alpha = -50, beta = -49
[d] 8/8/6k1/7p/1P5p/P7/8/4bK1r w - -
Pruning Kg2 at depth one (or in qsearch?) is prohibited, if your eval can recognize the inevitable loss of the rook and draw after Kg2. But if your eval is not that sophisticated, what is wrong with Edmund's argument to prune all legal (king) moves here ( > 0) and to finally return alpha assuming standing pat fail highs at the sons by a big margin anyway?
By the way, slightly related, what about Mark Winands' et al. PVS modifications in his 2003 paper
Enhanced forward pruning, which covers fail high pruning f.i. multi-cut, returning beta at expected all-nodes also?
If we erroneously forward prune at some ALL node and the resulting score is backed up all the way to a PV node, we obtain a fail high and a re-search will be performed. The algorithm is then searching for a new principal variation and regards the subsequent nodes as PV nodes. Because no forward pruning is done at PV nodes, it is possible to find out whether there exists a new PV or not. In this case the result of the mistake will be that an extra amount of nodes has been searched. In principle, forward pruning at an expected ALL node is not dangerous but can trigger unnecessary re-searches.
To ensure that a re-search is performed which is able to correct the value, some small changes in the PVS algorithm have to be made. The following four additions are performed.
1) To prevent that a backed-up value of a forward-pruned ALL node causes a beta-cutoff at the PV node lying above, the forward-pruning mechanism should return a value equal to beta in case of a cut-off (which is equal to alpha + 1 at an ALL node).
2) If the window of the PV node was already closed and the NWS should return a value equal to beta (alpha + 1), we still have to do a re-search.
3) If we do a re-search and the returned value of the NWS equals alpha + 1, we should do a re-search with alpha as lower bound.
4) CUT nodes where a fail-low has occurred with a value equal to alpha are not stored in the transposition table because their values are uncertain.