Using SEE to prune in main search

[silentshark]

For years, I have been using a SEE to prune losing captures in Q search. I seem to remember implementing this in the 1990's, following discussions with Bob and Bruce in rgcc.

Having a look at the latest stockfish, they are using SEE in a different way, to help prune non-captures in the main search.

This makes a lot of sense.. the idea I guess is that at low depths, moves which needlessly throw away a piece are pruned right out.

What do others think of this? Is it more widely used than stockfish and does it help?

I am going to have a look at whether this idea works for my program..

On a related note, how about this for an idea, prune losing captures in the main search (losing according to SEE, like we do in Qsearch) at low depths?

[Ferdy]

Instead of pruning I reduce capture moves with bad SEE in main search, similar to LMR - got around 4 to 8 rating points on this. There could be some potential in utilizing SEE for pruning and reduction.

[silentshark]

Instead of pruning I reduce capture moves with bad SEE in main search, similar to LMR - got around 4 to 8 rating points on this. There could be some potential in utilizing SEE for pruning and reduction.

Interesting.. sounds like there's some different ideas we could try here.

[bob]

Instead of pruning I reduce capture moves with bad SEE in main search, similar to LMR - got around 4 to 8 rating points on this. There could be some potential in utilizing SEE for pruning and reduction.

This is also what worked for me. At one point, I followed the dogma of "do not reduce checks, captures, etc." I now modify that to "do not reduce those moves if SEE >= 0, which lets me reduce spite checks and horrible captures like QxP when P is protected... I have not yet found any success with pruning except for in the last 4 plies as my "modified futility pruning" approach does currently. In the last few plies, if score is below alpha by some margin that increases as the remaining plies increases, I will prune the moves outright...

[silentshark]

Instead of pruning I reduce capture moves with bad SEE in main search, similar to LMR - got around 4 to 8 rating points on this. There could be some potential in utilizing SEE for pruning and reduction.

This is also what worked for me. At one point, I followed the dogma of "do not reduce checks, captures, etc." I now modify that to "do not reduce those moves if SEE >= 0, which lets me reduce spite checks and horrible captures like QxP when P is protected... I have not yet found any success with pruning except for in the last 4 plies as my "modified futility pruning" approach does currently. In the last few plies, if score is below alpha by some margin that increases as the remaining plies increases, I will prune the moves outright...

and what about "upping the ante"? i.e in addition to what you are doing, look at further reductions when SEE <0 at low depths.

[bob]

Instead of pruning I reduce capture moves with bad SEE in main search, similar to LMR - got around 4 to 8 rating points on this. There could be some potential in utilizing SEE for pruning and reduction.

This is also what worked for me. At one point, I followed the dogma of "do not reduce checks, captures, etc." I now modify that to "do not reduce those moves if SEE >= 0, which lets me reduce spite checks and horrible captures like QxP when P is protected... I have not yet found any success with pruning except for in the last 4 plies as my "modified futility pruning" approach does currently. In the last few plies, if score is below alpha by some margin that increases as the remaining plies increases, I will prune the moves outright...

and what about "upping the ante"? i.e in addition to what you are doing, look at further reductions when SEE <0 at low depths.

That is one of the areas I am experimenting with at the moment, in fact. I am studying the idea of variable reductions, particularly after adding history move ordering back in so that there is some sense of how good a move is by how early or late it is ordered...

When you say "low depths" I assume you mean well out into the tree, not near the root?

[hgm]

I would expect SEE to be a bit too inaccurate for this, and would prefer to do it on the QS score.

In fact I did a promising test once: reduce moves that fail low on a window artificially lowered by 2 Pawns by 4 ply. Implemented in LMR-like fashion: first do the reduced search, if it fails low, abandon the move, if it fails high (against the lowered window), search it at nominal depth (or with normal LMR, if it is a late move) against the normal window.

The promising aspect was that this did not seem to have a negative impact on the strength. While in fact the implementation was stupid: because the reduction of such moves was larger than my null move reduction (I used R=2), one could expect significant speedup by searching refutations that push the score low enough (like capturing the Q after Q x protected P) before null move.

[silentshark]

Instead of pruning I reduce capture moves with bad SEE in main search, similar to LMR - got around 4 to 8 rating points on this. There could be some potential in utilizing SEE for pruning and reduction.

This is also what worked for me. At one point, I followed the dogma of "do not reduce checks, captures, etc." I now modify that to "do not reduce those moves if SEE >= 0, which lets me reduce spite checks and horrible captures like QxP when P is protected... I have not yet found any success with pruning except for in the last 4 plies as my "modified futility pruning" approach does currently. In the last few plies, if score is below alpha by some margin that increases as the remaining plies increases, I will prune the moves outright...

and what about "upping the ante"? i.e in addition to what you are doing, look at further reductions when SEE <0 at low depths.

That is one of the areas I am experimenting with at the moment, in fact. I am studying the idea of variable reductions, particularly after adding history move ordering back in so that there is some sense of how good a move is by how early or late it is ordered...

When you say "low depths" I assume you mean well out into the tree, not near the root?

absolutely - nodes near the leaves of the tree, say when depth<3

[F. Bluemers]

Instead of pruning I reduce capture moves with bad SEE in main search, similar to LMR - got around 4 to 8 rating points on this. There could be some potential in utilizing SEE for pruning and reduction.

This is also what worked for me. At one point, I followed the dogma of "do not reduce checks, captures, etc." I now modify that to "do not reduce those moves if SEE >= 0, which lets me reduce spite checks and horrible captures like QxP when P is protected... I have not yet found any success with pruning except for in the last 4 plies as my "modified futility pruning" approach does currently. In the last few plies, if score is below alpha by some margin that increases as the remaining plies increases, I will prune the moves outright...

One of the first open source engines to ignore some of these dogmas must have been zct from Zach Wegner.
I ran tests for him and everytime tried to make a "sane" version.
Failed everytime

[Ralph Stoesser]

Having a look at the latest stockfish, they are using SEE in a different way, to help prune non-captures in the main search.

This makes a lot of sense.. the idea I guess is that at low depths, moves which needlessly throw away a piece are pruned right out.

It makes sense, but I wonder whether it would be a valid idea to prune even more aggressive. They prune if (depth < 2 && SEE < 0). A much more aggressive condition could look like

if (depth < 8 && SEE < Min(0, 1 - depth) * PAWN_VALUE) then prune

The assumption behind the formula is: Moves that throw away lots of material can be pruned earlier, compared to moves which throw away few material.

Given the depth SF reaches on today's computer hardware depth 7 is still rather near the leaf.