An unstoppable passed pawn

[lech]

Sometimes, it is good, though, to watch engine matches (4’+2”).
SF (white !!!) very clever defended this worse endgame.
[d]8/8/6p1/2bN3p/1pPkb3/1P2p1P1/4B2P/3K4 b - -
But, after the move 1…Bf8 SF has already a problem (the future unstoppable passed pawn c4). 2. Ke1 (??) Bf5 3.Bf3 Bc2 4. Bd1 Bxd1 5. Kxd1 and now SF’s score is 0.00 (!).
[d] 5b2/8/6p1/3N3p/1pPk4/1P2p1P1/7P/3K4 b - -
Next moves 5… Kd3 6.Sf4 Kc3 7.Se6 Kxb3 8.Sxf8 (still 0.00 ! ) Ka2 -+
[d] 5N2/8/6p1/7p/1pP5/4p1P1/k6P/3K4 w - -
After 1…Bf8, in the search, SF “considered” only 8…Kxc4 (=) to capture the unstoppable passed pawn c4.

[zamar]

The problem seems to be that SF doesn't understand about "potentially unstopable passed pawns". It sees that white has a guaranteed unstopable passed and so gives white a big bonus, but black's pawn isn't unconditionally unstopable so black gets nothing.

One solution might be to not give bonus for unstopable passed pawn if opponent has more advanced "potential unstopable passed pawn

[lech]

One solution might be to not give bonus for unstopable passed pawn if opponent has more advanced "potential unstopable passed pawn

I think that unstoppable passed pawns appear seldom and it, in most cases, gives an immediate win.
Is it possible to make a short (depth seems to be easy to set) search in search (sub-tree) to avoid such surprises? I can’t see another way.

[Ralph Stoesser]

One solution might be to not give bonus for unstopable passed pawn if opponent has more advanced "potential unstopable passed pawn

Another possibility would be to check whether our potentially unstoppable passed pawn (black pawn on b4) is in fact unstoppable. If the enemy has only the king, then our potentially unstoppable passed pawn is also unstoppable, if we control all squares in front of our pawn. Imho this should be the better solution because it makes the detection of unstoppable passed pawns more accurate in general.

evaluate.ccp, line 966

Code: Select all

        // If the other side has only a king, check whether the pawn is
        // unstoppable
        if (pos.non_pawn_material(Them) == Value(0))
        {
            Square qsq;
            int d;

            qsq = relative_square(Us, make_square(square_file(s), RANK_8));
            d =  square_distance(s, qsq)
               - square_distance(theirKingSq, qsq)
               + (Us != pos.side_to_move());

            if (     d < 0
+                || (ei.attacked_by(Us) & squares_in_front_of(Us, s)) == squares_in_front_of(Us, s))
            {
               ...

[bob]

Sometimes, it is good, though, to watch engine matches (4’+2”).
SF (white !!!) very clever defended this worse endgame.
[d]8/8/6p1/2bN3p/1pPkb3/1P2p1P1/4B2P/3K4 b - -
But, after the move 1…Bf8 SF has already a problem (the future unstoppable passed pawn c4). 2. Ke1 (??) Bf5 3.Bf3 Bc2 4. Bd1 Bxd1 5. Kxd1 and now SF’s score is 0.00 (!).
[d] 5b2/8/6p1/3N3p/1pPk4/1P2p1P1/7P/3K4 b - -
Next moves 5… Kd3 6.Sf4 Kc3 7.Se6 Kxb3 8.Sxf8 (still 0.00 ! ) Ka2 -+
[d] 5N2/8/6p1/7p/1pP5/4p1P1/k6P/3K4 w - -
After 1…Bf8, in the search, SF “considered” only 8…Kxc4 (=) to capture the unstoppable passed pawn c4.

Your terminology leaves me dizzy. If a pawn is "unstoppable" it can't, by definition, be captured. Usually this term is only used in endings with no pieces, where a pawn can run without the king having time to catch it (square of the king concept).

[bob]

The problem seems to be that SF doesn't understand about "potentially unstopable passed pawns". It sees that white has a guaranteed unstopable passed and so gives white a big bonus, but black's pawn isn't unconditionally unstopable so black gets nothing.

One solution might be to not give bonus for unstopable passed pawn if opponent has more advanced "potential unstopable passed pawn

Do you mean "protected passed pawn" as opposed to "unstoppable"???

[bob]

One solution might be to not give bonus for unstopable passed pawn if opponent has more advanced "potential unstopable passed pawn

I think that unstoppable passed pawns appear seldom and it, in most cases, gives an immediate win.
Is it possible to make a short (depth seems to be easy to set) search in search (sub-tree) to avoid such surprises? I can’t see another way.

Evaluation can do this trivially. We were doing this in 1978 in fact.

[zamar]

Do you mean "protected passed pawn" as opposed to "unstoppable"???

No, this is the problematic position near the leaves.

[d] 5N2/8/6p1/7p/1pP5/4p1P1/k6P/3K4 w - -

Because of terrible static misevaluation (+7 or sth like that), stockfish never reaches a position where black promotes. Huge misevaluation makes possible that in search white can make even two null moves here and still thinking it's winning.

Even if black's pawn was in b2, Stockfish's dummy evaluation calculates that white is a piece up and white has an unstoppable passed pawn. Black's two passed pawns are not able to reduce the advantage enough.

Of course human easily spots that black's pawn in b4/b3/b2 is unstoppable and promotes with check but because white has a knight Stockfish's algorithm doesn't recognize this.

Do you have some code in crafty to recognize these kind of positions?

[zamar]

Is it possible to make a short (depth seems to be easy to set) search in search (sub-tree) to avoid such surprises? I can’t see another way.

Of course, they are called extensions However I believe that the true problem here is the null move. We could try to disable null move in chaotic positions like this. Unfortunately these kind of positions are so rear that meaning for strength must be zero and fixing this can only make program weaker... so we are not going to do it

[Uri Blass]

Do you mean "protected passed pawn" as opposed to "unstoppable"???

No, this is the problematic position near the leaves.

[d] 5N2/8/6p1/7p/1pP5/4p1P1/k6P/3K4 w - -

Because of terrible static misevaluation (+7 or sth like that), stockfish never reaches a position where black promotes. Huge misevaluation makes possible that in search white can make even two null moves here and still thinking it's winning.

Even if black's pawn was in b2, Stockfish's dummy evaluation calculates that white is a piece up and white has an unstoppable passed pawn. Black's two passed pawns are not able to reduce the advantage enough.

Of course human easily spots that black's pawn in b4/b3/b2 is unstoppable and promotes with check but because white has a knight Stockfish's algorithm doesn't recognize this.

Do you have some code in crafty to recognize these kind of positions?

I wonder if you tried to change the definition of unstoppable pawn to be more narrow.

unstoppable passed pawn should be defined as a pawn the following conditions happen:

1)you are sure that the opponent king cannot stop it
2)you are sure that the opponent cannot promote earlier(or at the same time).
3)you are sure that the opponent cannot mare earlier(I guess that 3 is less important but I composed a diagram to show that it can happen)

[d]k7/P7/K7/6p1/8/8/1P6/8 w - - 0 1

It seems that the second part is missing from the definition of stockfish(otherwise it could avoid giving a big bonus for the white pawn)

Even without the knight stockfish evaluates the position wrong and does not see that black is winning.

[d]8/8/6p1/7p/1pP5/4p1P1/k6P/3K4 w - - 0 8

I think that it may be better to avoid pruning in positions when
only condition 1 is true and condition 2 is false(and you also may want to have evaluation that is closer to draw because of uncertainty).

Uri