Reducing/Pruning Bad Captures (SEE < 0)

[zamar]

If losing capture:
reduce search using normal schedule, set scout to alpha-MARGIN

It's possible that we have already tried this. I have probably only tried about a million things in the last 3 years and don't remember all of them

Don

SF got something like +5 elo using this idea. The problem is that although engine is a bit stronger, it's much weaker in tactical puzzles (which often involve a bad capture or even two of them!).

[zamar]

One could really expect that pruning/reducing bad captures is a great idea, but surprisingly we were never able to make this work for Stockfish.

Same here. I think captures are just too volatile to take any chances with.

Here's a simple question to answer...

"Why is QxPa6 bad if the a6 P is defended by a P at b7, but Qa6 is reducible if there is a pawn at b7 but there was NO pawn on a6?"

Both are losing moves, both lose almost the same material. I see nothing that says one is different from the other, unless there is some idea of exposing the king at b8 or something. But that's independent of the SEE value...

I reduce losing captures. It isn't much of a gain, but it is a gain for me...

It's just statistics.

Every chess player every now and then sees a position where Rxh6!! is a winning move (when black pawn is on g7). However it's very rear to see position where Rh6!! is a winning move (when black pawn is on g7)

I guess that when a player captures opponent's piece, opponent must capture and this can radically weaken his position and open up more tactical possibilities. However when a player just places his piece on square where opponent can capture it, it's often possible for the opponent to ignore it or play some other defensive move.

[hgm]

So basically you are saying that it should depend on the eval-window distance. If the capture was 'futile' it can be treated like a non-capture, as there is no compelling need to recapture. It is when the capture puts him above alpha that you have to take the move seriously (even if on the surface it seems bad).

[bob]

One could really expect that pruning/reducing bad captures is a great idea, but surprisingly we were never able to make this work for Stockfish.

Same here. I think captures are just too volatile to take any chances with.

Here's a simple question to answer...

"Why is QxPa6 bad if the a6 P is defended by a P at b7, but Qa6 is reducible if there is a pawn at b7 but there was NO pawn on a6?"

Both are losing moves, both lose almost the same material. I see nothing that says one is different from the other, unless there is some idea of exposing the king at b8 or something. But that's independent of the SEE value...

I reduce losing captures. It isn't much of a gain, but it is a gain for me...

It's just statistics.

Every chess player every now and then sees a position where Rxh6!! is a winning move (when black pawn is on g7). However it's very rear to see position where Rh6!! is a winning move (when black pawn is on g7)

I guess that when a player captures opponent's piece, opponent must capture and this can radically weaken his position and open up more tactical possibilities. However when a player just places his piece on square where opponent can capture it, it's often possible for the opponent to ignore it or play some other defensive move.

However, in the case I gave, the last move could have been Rh6 or Rxh6. You can't tell the difference unless you see the position prior to that move. Given that, what would say "reduce the non-capture, but not the capture, since the resulting position is identical in all other aspects.."

[Don]

If losing capture:
reduce search using normal schedule, set scout to alpha-MARGIN

It's possible that we have already tried this. I have probably only tried about a million things in the last 3 years and don't remember all of them

Don

SF got something like +5 elo using this idea. The problem is that although engine is a bit stronger, it's much weaker in tactical puzzles (which often involve a bad capture or even two of them!).

But Joona claimed earlier that it didn't work! I would kill for 5 ELO! Are you saying that would give up 5 ELO for better tactics but a weaker program?

[Mincho Georgiev]

Test 2:
---------
Pawny - Rotor 0.4; 500 Games, +162 =118 -220 44.20%, TP=-40
Pawny+ - Rotor 0.4; 500 Games, +215 =130 -156 55.89%, TP=+41
Pawny- - Rotor 0.4; 500 Games, +106 =127 -178 51.80%, TP=+12

I've decided to use cutechess-cli for this one. Highly controversial results. I will run it again as I usually do - with Chessbase.

[Mincho Georgiev]

Unfortunately, I have to agree with Don in some sense. I'm saying "unfortunately" because I would really love this to work. The see is a good guess as Don said, and good estimate at best. But...
For example the following simple position:

[d]6k1/8/8/1K6/4P3/3B4/4r3/5q2 b - - 0 1

The "bad capture" here is Rxe4. If the SEE takes into account that the bishop is pinned, re-capturing on the evaluated square is impossible and the result is +100. However, the real value is -850, because re-capturing will take place on f1 instead. Just one simple example how perfect the SEE needs to be in order for this to work flawlessly. Still, not my case for sure.
I'm pretty certain Bob and others who are using these reductions and gets benefits have resolved issues like this one (and tones of others), but I need to continue improving my see() to be sure that the reductions will work properly.
With my current program structure this is very difficult to achieve and probably will get it done with my upcoming bitboard one.
Still, my tests shows slight improvement, but I need to be sure that i'm reducing the right moves.

[Don]

Unfortunately, I have to agree with Don in some sense. I'm saying "unfortunately" because I would really love this to work. The see is a good guess as Don said, and good estimate at best. But...
For example the following simple position:

[d]6k1/8/8/1K6/4P3/3B4/4r3/5q2 b - - 0 1

The "bad capture" here is Rxe4. If the SEE takes into account that the bishop is pinned, re-capturing on the evaluated square is impossible and the result is +100. However, the real value is -850, because re-capturing will take place on f1 instead. Just one simple example how perfect the SEE needs to be in order for this to work flawlessly. Still, not my case for sure.
I'm pretty certain Bob and others who are using these reductions and gets benefits have resolved issues like this one (and tones of others), but I need to continue improving my see() to be sure that the reductions will work properly.
With my current program structure this is very difficult to achieve and probably will get it done with my upcoming bitboard one.
Still, my tests shows slight improvement, but I need to be sure that i'm reducing the right moves.

The idea seems to be working if you use a margin like we discussed. Here is a head to head result at a fixed node level of 65,536 using a margin of 30:

Code: Select all

Rank Name               Elo      +      -    games   score   oppo.   draws 
   1 kse-4286.08-m30  3004.8    2.7    2.7   60092   50.8%  3000.0   40.7% 
   2 kse-4286.00      3000.0    2.7    2.7   60092   49.2%  3004.8   40.7% 



      TIME    RATIO    log(r)     NODES    log(r)  ave DEPTH    GAMES   PLAYER
 ---------  -------  --------  --------  --------  ---------  -------   ---------------
    0.0720    0.999    -0.001     0.066     0.000    10.9326    60093   kse-4286.08-m30
    0.0721    1.000     0.000     0.066     0.000    10.8830    60093   kse-4286.00

You can also see that the depth increases slightly (since this is fixed nodes) which indicates that it is having a good effect on the speed.

We would have to test this at time controls in the gauntlet test, but it appears to be worth at least a couple of ELO. Without the margin it appears to be a bad idea but even a modest margin seems to make this workable.

[Don]

Unfortunately, I have to agree with Don in some sense. I'm saying "unfortunately" because I would really love this to work. The see is a good guess as Don said, and good estimate at best. But...
For example the following simple position:

[d]6k1/8/8/1K6/4P3/3B4/4r3/5q2 b - - 0 1

The "bad capture" here is Rxe4. If the SEE takes into account that the bishop is pinned, re-capturing on the evaluated square is impossible and the result is +100. However, the real value is -850, because re-capturing will take place on f1 instead. Just one simple example how perfect the SEE needs to be in order for this to work flawlessly. Still, not my case for sure.
I'm pretty certain Bob and others who are using these reductions and gets benefits have resolved issues like this one (and tones of others), but I need to continue improving my see() to be sure that the reductions will work properly.

But don't forget that the reduction itself is far more powerful than SEE() and LMR in general tries to hide errors, so it's not exactly the same as being completely blind to simple tactics like this. But still, I think captures (even bad ones) should be viewed properly as "threat moves" and a threat move (as a general rule) takes 2 ply off of what a program would normally see in that line.

So another related idea is to reduce bad captures LESS than you would reduce a quiet move.

With my current program structure this is very difficult to achieve and probably will get it done with my upcoming bitboard one.
Still, my tests shows slight improvement, but I need to be sure that i'm reducing the right moves.

[bob]

Unfortunately, I have to agree with Don in some sense. I'm saying "unfortunately" because I would really love this to work. The see is a good guess as Don said, and good estimate at best. But...
For example the following simple position:

[d]6k1/8/8/1K6/4P3/3B4/4r3/5q2 b - - 0 1

The "bad capture" here is Rxe4. If the SEE takes into account that the bishop is pinned, re-capturing on the evaluated square is impossible and the result is +100. However, the real value is -850, because re-capturing will take place on f1 instead. Just one simple example how perfect the SEE needs to be in order for this to work flawlessly. Still, not my case for sure.
I'm pretty certain Bob and others who are using these reductions and gets benefits have resolved issues like this one (and tones of others), but I need to continue improving my see() to be sure that the reductions will work properly.
With my current program structure this is very difficult to achieve and probably will get it done with my upcoming bitboard one.
Still, my tests shows slight improvement, but I need to be sure that i'm reducing the right moves.

The idea seems to be working if you use a margin like we discussed. Here is a head to head result at a fixed node level of 65,536 using a margin of 30:

Code: Select all

Rank Name               Elo      +      -    games   score   oppo.   draws 
   1 kse-4286.08-m30  3004.8    2.7    2.7   60092   50.8%  3000.0   40.7% 
   2 kse-4286.00      3000.0    2.7    2.7   60092   49.2%  3004.8   40.7% 



      TIME    RATIO    log(r)     NODES    log(r)  ave DEPTH    GAMES   PLAYER
 ---------  -------  --------  --------  --------  ---------  -------   ---------------
    0.0720    0.999    -0.001     0.066     0.000    10.9326    60093   kse-4286.08-m30
    0.0721    1.000     0.000     0.066     0.000    10.8830    60093   kse-4286.00

You can also see that the depth increases slightly (since this is fixed nodes) which indicates that it is having a good effect on the speed.

We would have to test this at time controls in the gauntlet test, but it appears to be worth at least a couple of ELO. Without the margin it appears to be a bad idea but even a modest margin seems to make this workable.

My approach has been pretty simple. My moves are searched in the following order. Obviously I don't generate and sort, but by the time the search has finished all the moves at a ply, the moves were sorted as follows, noting that any particular group might not exist (no hash move or legal killer move for example):

Hash move
Captures with see >= 0;
killer moves
rest of moves with captures with SEE < 0 first in the list since they were generated first.

If I am in the "rest of moves" phase of searching, any move can be reduced by 2 plies unless it is the first move searched, when it is only reduced by 1. This exception handles the case where there is no hash move, no good captures, and no legal killers, which is very rare. In such a case, I only reduce the first move searched by 1, the rest by 2. Since captures in the "rest of the moves" phase are there because SEE < 0, they get reduced. Ditto for checks with SEE < 0. If the check is "safe" I extend and do not reduce, else I reduce and do not extend.

All of that was a net gain to me. I would have to dig through a lot of info to find out exactly how much each helped, to the point it would likely be easier to re-run the test...

I like the idea of extending some, leaving some alone, and reducing others by 1 or 2 plies. Sort of categorizes moves into "great, good, bad and ugly". Still work to be done however, as the better the categorization is, the better the program plays, particularly tactically.