Passed Pawns (endgame)

[lech]

[d] 8/P7/4k3/8/5P2/4Bq2/5P2/5K2 b - - 0 1
1…Kf5 2.Ke1(g1) Qd5 3.Kf1 (3.Ke2 Kg4) Ke4 4.Kg2 (4.Ke2 Qa2+) Qg8+ 5.Kf1 Kf3 6.Ke1 Qa2 7.Kd1 Ke4 8.Ke1 Kd3 9.Kf1 Qd5 10.Kg1 Ke2 win
Probably all engines would play 1…Kd7 ??

Monte Carlo Analysis in Rybka 4: yields precise evaluations by playing thousands of ultra-fast games in a few minutes in a given position. This is very much like using game result statistics, something human players do when choosing their opening variations. Monte Carlo Analysis can be used in any position, but generally it's most useful in two types of positions:
1) Endgames. Many engines often give high scores to drawn endgames (and sometimes low scores to winning ones). Monte Carlo recognizes fortresses and other no-progress situations. It's also good in Rook endgames, which are another computer problem.
2) Positions. There are games where one side has made a big material sacrifice for slow compensation (i.e. not just tactics). For instance you can find lots of piece sacrifices in famous Grandmaster chess games which no computer will correctly appreciate - but which Monte Carlo gets right.[/b]

[mcostalba]

Not that I would claim that the passed pawn code is somehow optimal, but such a patch most likely wouldn't make the code significant more messy as it already is. The code to evaluate enemy control over squares in front of our passed pawn is already there.

In this case the priority is to _first_ try to make the code less messy

BTW it didn't seem so messy to me the last time I looked at it....maybe you can come up with a clean-up patch (theese are greatly appreciated by me).

[Ralph Stoesser]

Not that I would claim that the passed pawn code is somehow optimal, but such a patch most likely wouldn't make the code significant more messy as it already is. The code to evaluate enemy control over squares in front of our passed pawn is already there.

In this case the priority is to _first_ try to make the code less messy

Thank you. I was waiting for this comment.
I agree. In the real world, where time and money matters, I would do both, clean up + bug fixing, at the same time frame.

BTW it didn't seem so messy to me the last time I looked at it....maybe you can come up with a clean-up patch (theese are greatly appreciated by me).

I just want to remind you that the term "messy" originate from Joona. I also cannot spot major messy parts in the passed pawn code. The local bitboard variable names b, b2, b3, b4 are not exactly telling, but they are short instead, which also is a good thing. Personally I would not label variables like this, but that's a minor issue. Also that would be easy to "cleen up". So to me at first it's questionable whether it would pay to invest much work here. But maybe Joona can come up with a clean-up patch. These are greatly appreciated, also by me as a SF fan

[Sven]

Not that I would claim that the passed pawn code is somehow optimal, but such a patch most likely wouldn't make the code significant more messy as it already is. The code to evaluate enemy control over squares in front of our passed pawn is already there.

In this case the priority is to _first_ try to make the code less messy

Thank you. I was waiting for this comment.
I agree. In the real world, where time and money matters, I would do both, clean up + bug fixing, at the same time frame.

BTW it didn't seem so messy to me the last time I looked at it....maybe you can come up with a clean-up patch (theese are greatly appreciated by me).

I just want to remind you that the term "messy" originate from Joona. I also cannot spot major messy parts in the passed pawn code. The local bitboard variable names b, b2, b3, b4 are not exactly telling, but they are short instead, which also is a good thing. Personally I would not label variables like this, but that's a minor issue. Also that would be easy to "cleen up". So to me at first it's questionable whether it would pay to invest much work here. But maybe Joona can come up with a clean-up patch. These are greatly appreciated, also by me as a SF fan

As a first step, here is my "cleanup proposal" for the evaluate_passed_pawns_of_color() function. No functional change or "fix" at all yet, only an attempt of restructuring the same code into smaller functions, most of them getting inlined.

Old size of evaluate_passed_pawns_of_color() function: 127 lines, starting at line 873 in evaluate.cpp (SF 1.7.1)
New size (6 functions): 163 lines replacing the old 127 lines

Second step, if the SF team would agree to a local and non-functional change like this, would be that we come up with a proposal addressing the "king proximity" issue I brought up. But the first step could also persist without the second, I think.

Comments are welcome!

Sven

Code: Select all

  // evaluate_king_proximity_to_passed_pawn() evaluates the proximity of both kings to the given passed pawn

  template<Color Us>
  inline void evaluate_king_proximity_to_passed_pawn(
          Square s, Square blockSq, Square ourKingSq, Square theirKingSq, int tr, Value & ebonus) {

      ebonus -= Value(square_distance(ourKingSq, blockSq) * 3 * tr);
      ebonus -= Value(square_distance(ourKingSq, blockSq + pawn_push(Us)) * 1 * tr);
      ebonus += Value(square_distance(theirKingSq, blockSq) * 6 * tr);
  }

  // evaluate_promotion_path_of_passed_pawn() evaluates properties of the promotion path of the
  // given passed pawn

  template<Color Us>
  inline void evaluate_promotion_path_of_passed_pawn(
          const Position& pos, Square s, Square blockSq, int tr, const EvalInfo& ei, Value & ebonus) {

      // If the pawn is free to advance, increase bonus
      if (pos.square_is_empty(blockSq))
      {
          // There are no enemy pawns in the pawn's path
          Bitboard pathBB = squares_in_front_of(Us, s);

          assert((pathBB & pos.pieces(PAWN, Them)) == EmptyBoardBB);

          // Squares attacked by us
          Bitboard pathProtectedBB = pathBB & ei.attacked_by(Us);

          // Squares attacked or occupied by enemy pieces
          Bitboard pathImpactedBB = pathBB & (ei.attacked_by(Them) | pos.pieces_of_color(Them));

          // If there is an enemy rook or queen attacking the pawn from behind,
          // add all X-ray attacks by the rook or queen.
          if (   (squares_behind(Us, s) & pos.pieces(ROOK, QUEEN, Them))
              && (squares_behind(Us, s) & pos.pieces(ROOK, QUEEN, Them) & pos.attacks_from<QUEEN>(s)))
              pathImpactedBB = pathBB;

          // Are any of the squares in the pawn's path attacked or occupied by the enemy?
          if (pathImpactedBB == EmptyBoardBB)
              // No enemy attacks or pieces, huge bonus!
              // Even bigger if we protect the pawn's path
              ebonus += Value(tr * (pathBB == pathProtectedBB ? 17 : 15));
          else
              // OK, there are enemy attacks or pieces (but not pawns). Are those
              // squares which are attacked by the enemy also attacked by us ?
              // If yes, big bonus (but smaller than when there are no enemy attacks),
              // if no, somewhat smaller bonus.
              ebonus += Value(tr * ((pathImpactedBB & pathProtectedBB) == pathImpactedBB ? 13 : 8));

          // At last, add a small bonus when there are no *friendly* pieces
          // in the pawn's path.
          if ((pathBB & pos.pieces_of_color(Us)) == EmptyBoardBB)
              ebonus += Value(tr);
      }
  }

  // evaluate_supported_passed_pawn() evaluates a passed pawn which is supported by a friendly pawn

  template<Color Us>
  inline void evaluate_supported_passed_pawn(const Position& pos, Square s, int r, Value & ebonus) {

      // If the pawn is supported by a friendly pawn, increase bonus
      Bitboard neighboursOfPassedPawnBB = pos.pieces(PAWN, Us) & neighboring_files_bb(s);
      if (neighboursOfPassedPawnBB & rank_bb(s))
          ebonus += Value(r * 20);
      else if (pos.attacks_from<PAWN>(s, Them) & neighboursOfPassedPawnBB)
          ebonus += Value(r * 12);
  }

  // evaluate_unstoppable_passed_pawn() checks whether the given passed pawn is unstoppable,
  // and if it is, sets the movesToGo[] and pawnToGo[] values for the given color

  template<Color Us>
  inline void evaluate_unstoppable_passed_pawn(
           const Position& pos, Square s, Square theirKingSq, Color Them, int movesToGo[], Square pawnToGo[]) {

      // If the other side has only a king, check whether the pawn is unstoppable
      if (pos.non_pawn_material(Them) == Value(0))
      {
          Square qsq = relative_square(Us, make_square(square_file(s), RANK_8));
          int d =  square_distance(s, qsq)
                 - square_distance(theirKingSq, qsq)
                 + int(Us != pos.side_to_move());

          if (d < 0)
          {
              int mtg = RANK_8 - relative_rank(Us, s);
              int blockerCount = count_1s_max_15(squares_in_front_of(Us,s) & pos.occupied_squares());
              mtg += blockerCount;
              d += blockerCount;
              if (d < 0 && (!movesToGo[Us] || movesToGo[Us] > mtg))
              {
                  movesToGo[Us] = mtg;
                  pawnToGo[Us] = s;
              }
          }
      }
  }

  // evaluate_rook_passed_pawns() evaluates the passed pawns of the given color that are on rook files

  template<Color Us>
  inline void evaluate_rook_passed_pawns(const Position& pos, Square s, Color Them, Value & ebonus) {

      // Rook pawns are a special case: They are sometimes worse, and
      // sometimes better than other passed pawns. It is difficult to find
      // good rules for determining whether they are good or bad. For now,
      // we try the following: Increase the value for rook pawns if the
      // other side has no pieces apart from a knight, and decrease the
      // value if the other side has a rook or queen.
      if (square_file(s) == FILE_A || square_file(s) == FILE_H)
      {
          if (   pos.non_pawn_material(Them) <= KnightValueMidgame
              && pos.piece_count(Them, KNIGHT) <= 1)
              ebonus += ebonus / 4;
          else if (pos.pieces(ROOK, QUEEN, Them))
              ebonus -= ebonus / 4;
      }
  }

  // evaluate_passed_pawns_of_color() evaluates the passed pawns of the given color

  template<Color Us>
  void evaluate_passed_pawns_of_color(const Position& pos, int movesToGo[], Square pawnToGo[], EvalInfo& ei) {

    const Color Them = (Us == WHITE ? BLACK : WHITE);

    Square ourKingSq = pos.king_square(Us);
    Square theirKingSq = pos.king_square(Them);
    Bitboard ourPassedPawnsBB = ei.pi->passed_pawns() & pos.pieces(PAWN, Us);

    while (ourPassedPawnsBB)
    {
        Square s = pop_1st_bit(&ourPassedPawnsBB);

        assert(pos.piece_on(s) == piece_of_color_and_type(Us, PAWN));
        assert(pos.pawn_is_passed(Us, s));

        int r = int(relative_rank(Us, s) - RANK_2);
        int tr = Max(0, r * (r - 1));

        // Base bonus based on rank
        Value mbonus = Value(20 * tr);
        Value ebonus = Value(10 + r * r * 10);

        // Adjust bonus based on king proximity
        if (tr)
        {
            Square blockSq = s + pawn_push(Us);
            evaluate_king_proximity_to_passed_pawn(     s, blockSq, ourKingSq, theirKingSq, tr,     ebonus);
            evaluate_promotion_path_of_passed_pawn(pos, s, blockSq,                         tr, ei, ebonus);
        }

        evaluate_supported_passed_pawn  (pos, s, r,                 ebonus);
        evaluate_unstoppable_passed_pawn(pos, s, theirKingSq, Them, movesToGo, pawnToGo);
        evaluate_rook_passed_pawns      (pos, s,              Them, ebonus);

        // Add the scores for this pawn to the middle game and endgame eval.
        ei.value += Sign[Us] * apply_weight(make_score(mbonus, ebonus), WeightPassedPawns);
    }
  }

[mcostalba]

Comments are welcome!

Thanks Sven, but I prefer to keep the whole function in one chunk, it is easier (for me) to understand what's going on.

This is my attempt. This is a "no functional change" but I have added 3 FIXME that corresponds to 3 tests to be done one after the other and NOT togheter, that could yield or to an ELO increase or to a code simplification....there is material for one week of tests here

Code: Select all

   template<Color Us>
  void evaluate_passed_pawns(const Position& pos, EvalInfo& ei) {

    const Color Them = (Us == WHITE ? BLACK : WHITE);

    Bitboard squaresToQueen, defendedSquares, unsafeSquares, supportingPawns;
    Bitboard b = ei.pi->passed_pawns() & pos.pieces_of_color(Us);

    while (b)
    {
        Square s = pop_1st_bit(&b);

        assert(pos.piece_on(s) == piece_of_color_and_type(Us, PAWN));
        assert(pos.pawn_is_passed(Us, s));

        int r = int(relative_rank(Us, s) - RANK_2);
        int tr = Max(0, r * (r - 1));

        // Base bonus based on rank
        Value mbonus = Value(20 * tr);
        Value ebonus = Value(10 + r * r * 10);

        if (tr)
        {
            Square blockSq = s + pawn_push(Us);

            // Adjust bonus based on kings proximity to the blocking square
            ebonus -= Value(square_distance(pos.king_square(Us), blockSq) * 3 * tr);
            ebonus -= Value(square_distance(pos.king_square(Us), blockSq + pawn_push(Us)) * 1 * tr);
            ebonus += Value(square_distance(pos.king_square(Them), blockSq) * 6 * tr);

            // If the pawn is free to advance, increase bonus
            if (pos.square_is_empty(blockSq))
            {
                squaresToQueen = squares_in_front_of(Us, s);
                defendedSquares = squaresToQueen & ei.attacked_by(Us);

                // There are no enemy pawns in the pawn's path
                assert(!(squaresToQueen & pos.pieces(PAWN, Them)));

                // If there is an enemy rook or queen attacking the pawn from behind,
                // add all X-ray attacks by the rook or queen. Otherwise consider only
                // the squares in the pawn's path attacked or occupied by the enemy.
                if (   (squares_behind(Us, s) & pos.pieces(ROOK, QUEEN, Them))
                    && (squares_behind(Us, s) & pos.pieces(ROOK, QUEEN, Them) & pos.attacks_from<QUEEN>(s)))
                    unsafeSquares = squaresToQueen;
                else
                    unsafeSquares = squaresToQueen & (ei.attacked_by(Them) | pos.pieces_of_color(Them));

                // If there aren't enemy attacks or pieces along the path to queen give
                // huge bonus. Even bigger if we protect the pawn's path.
                if (!unsafeSquares)
                    ebonus += Value(tr * (squaresToQueen == defendedSquares ? 17 : 15));

                /* FIXME skip bonus when blockSq is unsafe and undefended

                   else if (!bit_is_set(unsafeSquares & ~defendedSquares), blockSq)
                */
                else 
                    // OK, there are enemy attacks or pieces (but not pawns). Are those
                    // squares which are attacked by the enemy also attacked by us ?
                    // If yes, big bonus (but smaller than when there are no enemy attacks),
                    // if no, somewhat smaller bonus.
                    ebonus += Value(tr * ((unsafeSquares & defendedSquares) == unsafeSquares ? 13 : 8));

                // At last, add a small bonus when there are no *friendly* pieces
                // in the pawn's path.
                if (!(squaresToQueen & pos.pieces_of_color(Us)))
                    ebonus += Value(tr);
            }
        } // tr != 0

        // Increase the bonus if the passed pawn is supported by a friendly pawn.
        // Give a good bonus if the friendly pawn is on the same rank and a bit
        // smaller bonus if it's on the previous rank.
        supportingPawns = pos.pieces(PAWN, Us) & neighboring_files_bb(s);
        if (supportingPawns & rank_bb(s))
            ebonus += Value(r * 20);
        else if (supportingPawns & rank_bb(s - pawn_push(Us))) // FIXME remove 'else'
            ebonus += Value(r * 12);

        // Rook pawns are a special case: They are sometimes worse, and
        // sometimes better than other passed pawns. It is difficult to find
        // good rules for determining whether they are good or bad. For now,
        // we try the following: Increase the value for rook pawns if the
        // other side has no pieces apart from a knight, and decrease the
        // value if the other side has a rook or queen.
        if (square_file(s) == FILE_A || square_file(s) == FILE_H) // FIXME remove this ugly special case
        {
            if (   pos.non_pawn_material(Them) <= KnightValueMidgame
                && pos.piece_count(Them, KNIGHT) <= 1)
                ebonus += ebonus / 4;
            else if (pos.pieces(ROOK, QUEEN, Them))
                ebonus -= ebonus / 4;
        }

        // Add the scores for this pawn to the middle game and endgame eval
        ei.value += Sign[Us] * apply_weight(make_score(mbonus, ebonus), Weights[PassedPawns]);

    } // while
  }

[lech]

One should almost never consider changing code because of one test position

100 point bonus [passed pawns (endgame)] makes correct play more difficult (time-consuming) or impossible, if opposite Pawn reached 7(2) line, and King should be active.

Example (one of many tested by me):
[d] 8/6kP/1p4B1/8/2Pp4/8/3K4/r7 b - - 0 1
correct play: 1...Rh1 and next Kg7->f6->e5 e.g. 2.Be4 Rh3 3.Bf5 Rh2+ 4.Kd3 Kf6 5.Be4 Ke5 6.Bg6 Rh3+ 7.Kd2 Kf4 8.Ke2 Rh2+ 9.Kd3 Ke5 -+

Analysis by Stockfish 1.7.1 JA [passed pawns (endgame) =100]:
1...Kh8
-+ (-3.07) Depth: 1 00:00:01
1...Ra3 2.Bf5 Kh8 3.Be4 Rh3 4.Bf5
-+ (-3.07) Depth: 6 00:00:01
1...Ra3 2.Bf5 Kh8 3.Be4 Rh3 4.Bf5
-+ (-3.07) Depth: 6 00:00:01
1...Ra3 2.Bf5 Kh8 3.Be4 Rh3 4.Bf5
-+ (-3.07) Depth: 6 00:00:01
1...Ra3 2.Bf5 Kh8 3.Be4 Rh3 4.Bf5
-+ (-3.07) Depth: 6 00:00:01
1...Ra3 2.Bf5 Kh8 3.Be4 Rh3 4.Bf5
-+ (-3.07) Depth: 6 00:00:01
1...Ra3 2.Bf5 Kh8 3.Be4 Rh3 4.Bf5
-+ (-3.07) Depth: 6 00:00:01
1...Ra3 2.Bf5 Kh8 3.Be4 Rh3 4.Bf5
-+ (-3.07) Depth: 6 00:00:01
1...Ra3 2.Bf5 Kh8 3.Be4 Rh3 4.Bf5
-+ (-3.07) Depth: 6 00:00:01
1...Ra3 2.Bf5 Kh8 3.Be4 Rh3 4.Bf5
-+ (-3.07) Depth: 6 00:00:01 3kN
1...Ra3 2.Be4 Kh8 3.Bf5 Ra7 4.Kd3
-+ (-2.98) Depth: 7 00:00:01 3kN
1...Ra3 2.Be4 Kh8 3.Bf5 Ra5 4.Be4 Re5
-+ (-2.98) Depth: 7 00:00:01 5kN
1...Ra3 2.Bf5 Kh8 3.Be4 Rh3 4.Bf5 Rf3 5.Be4
-+ (-3.07) Depth: 8 00:00:01 6kN
1...Ra3 2.Be4 Kh8 3.Bf5 Re3 4.Bg6 Rh3 5.Be4
-+ (-3.07) Depth: 8 00:00:01 6kN
1...Ra3 2.Be4 Kh8 3.Bf5 Re3 4.Bg6 Rh3 5.Bf5 Rh5
-+ (-3.03) Depth: 9 00:00:01 9kN
1...Ra3 2.Be4 Kh8 3.Bf5 Re3 4.Bg6 Rh3 5.Bf5 Rh5 6.Be4
-+ (-3.03) Depth: 10 00:00:01 13kN
1...Ra3 2.Be4 Kh8 3.Bf5 Re3 4.Bg6 Rh3 5.Bf5 Rh5 6.Be4
-+ (-2.94) Depth: 11 00:00:01 19kN
1...Ra3 2.Be4 Kh8 3.Bf5 Re3 4.Bg6 Rh3 5.Bf5 Rh5 6.Be4
-+ (-2.86) Depth: 11 00:00:01 25kN
1...Ra3 2.Be4 Kh8 3.Bf5 Rc3 4.Bd3 Kg7 5.Be4 Rxc4 6.Kd3 b5
-+ (-2.82) Depth: 11 00:00:01 32kN
1...Ra3 2.Be4 Kh8 3.Bf5 Rc3 4.Bd3 Kg7 5.Be4 Rxc4 6.Kd3 b5 7.Bd5 Rc8
-+ (-2.74) Depth: 12 00:00:01 40kN
1...Ra3 2.Bf5 Rc3 3.Be4 Kh8 4.Bd3 Kg7 5.Be4
-+ (-2.94) Depth: 13 00:00:01 59kN
1...Ra3 2.Be4 Kh8 3.Bf5 Rc3 4.Bd3 Kg7 5.Be4 Rxc4 6.Kd3 Ra4 7.Bc6 Ra3+ 8.Kxd4 Kxh7 9.Bd5 Kg7
-+ (-2.82) Depth: 13 00:00:02 75kN
1...Rg1 2.Bf5 Rg3 3.Be4 Kh8 4.Bf5 Rc3 5.Bd3 Kg7 6.Ke2 Ra3 7.Bf5 Kh8 8.Bd3 Kg7
-+ (-2.86) Depth: 13 00:00:02 105kN
1...Rg1 2.Bf5 Rg3 3.Be4 Kh8 4.Bf5 Rc3 5.Bd3 Kg7 6.Ke2 Ra3 7.Bg6 Re3+ 8.Kd2 Rc3 9.Bf5 Rxc4 10.Kd3 b5 11.Be6 Ra4
-+ (-2.86) Depth: 14 00:00:02 134kN
1...Rg1 2.Bf5 Rg3 3.Be4 Kh8 4.Bf5 Rc3 5.Bd3 Kg7 6.Ke2 Ra3 7.Bg6 Re3+ 8.Kd2 Rc3 9.Bf5 Rxc4 10.Kd3 b5 11.Be6 Ra4
-+ (-2.86) Depth: 15 00:00:02 158kN
1...Rg1 2.Be4 Rg3 3.Bc2 Kh8 4.Bf5 Rc3 5.Bd3 Kg7 6.Ke2 Ra3 7.Bg6 Re3+ 8.Kd2 Rc3 9.Bf5 Rxc4 10.Kd3 b5 11.Be6 Ra4
-+ (-2.94) Depth: 16 00:00:02 206kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bc2 Kh8 5.Bf5 Rc3 6.Bd3 Kg7 7.Ke2 Ra3 8.Bg6 Re3+ 9.Kd2 Rc3 10.Bd3 Kh8 11.Ke2 Rb3 12.Bg6 Rg3 13.Bf5 Ra3 14.Bd3 Rb3
-+ (-2.90) Depth: 16 00:00:02 240kN
1...Rg1 2.Be4 Rg3 3.Bc2 Kh8 4.Bf5 Rc3 5.Bd3 Kg7 6.Ke2 Ra3 7.Bg6 Re3+ 8.Kd2 Kh8 9.Bf5 Rc3
-+ (-2.98) Depth: 17 00:00:03 316kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bc2 Kh8 5.Bf5 Rc3 6.Bd3 Kg7 7.Ke2 Ra3 8.Bg6 Re3+ 9.Kd2 Kh8 10.Bf5 Rg3 11.Be4 Rc3 12.Bd3
-+ (-2.98) Depth: 17 00:00:03 328kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bc2 Kh8 5.Bf5 Rc3 6.Bd3 Kg7 7.Ke2 Ra3 8.Bg6 Re3+ 9.Kd2 Rc3 10.Bd3 Kh8 11.Ke2 Ra3 12.Bf5 Re3+ 13.Kd2 Rc3
-+ (-2.98) Depth: 18 00:00:03 408kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bc2 Kh8 5.Bf5 Rc3 6.Bd3 Kg7 7.Ke2 Ra3 8.Bg6 Re3+ 9.Kd2 Rc3 10.Bd3 Kh8 11.Ke2 Ra3 12.Bf5 Re3+ 13.Kd2 Rc3
-+ (-2.98) Depth: 19 00:00:03 521kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bc2 Kh8 5.Bf5 Rc3 6.Bd3 Kg7 7.Ke2 Ra3 8.Bg6 Re3+ 9.Kd2 Rc3 10.Bd3 Kh8 11.Ke2 Ra3 12.Bf5 Re3+ 13.Kd2 Rc3
-+ (-2.98) Depth: 20 00:00:04 660kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bc2 Kh8 5.Bf5 Rc3 6.Bd3 Kg7 7.Ke2 Ra3 8.Bg6 Re3+ 9.Kd2 Rc3 10.Bd3 Kh8 11.Ke2 Ra3 12.Bf5 Re3+ 13.Kd2 Rf3 14.Be4 Rg3 15.Bf5
-+ (-2.98) Depth: 21 00:00:05 920kN
1...Rg1 2.Bf5 Rg3 3.Be4 Kh8 4.Bf5 Rc3 5.Bd3 Kg7 6.Ke2 Ra3 7.Bg6 Re3+ 8.Kd2 Kh8 9.Bf5 Rb3 10.Bg6 Re3
-+ (-2.90) Depth: 22 00:00:05 1135kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bc2 Kh8 5.Bf5 Rc3 6.Bd3 Kg7 7.Ke2 Ra3 8.Bg6 Re3+ 9.Kd2 Kh8 10.Bf5 Rb3 11.Bg6 Rh3 12.Be4 Ra3 13.Bf5 Re3 14.Bd3 Kg7 15.Bf5 Kh8
-+ (-2.98) Depth: 22 00:00:06 1457kN
1...Rg1 2.Bf5 Rg3 3.Be4 Re3 4.Bf5 Kh8 5.Bd3 Kg7 6.Bf5
-+ (-2.90) Depth: 23 00:00:07 1686kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bf5 Rf3 5.Bg6 Rh3 6.Be4 Kf6 7.Ke2 Ke5 8.Bg6 Kf4 9.Kd2 Rh2+ 10.Kd3 Ke5
-+ (-3.07) Depth: 23 00:00:09 2338kN
1...Rg1 2.Bf5 Rg3 3.Ke2 Ra3 4.Bd3 Rb3 5.Bf5 Rg3 6.Kd2 Rg5 7.Be4 Rg3 8.Bf5
-+ (-2.82) Depth: 23 00:00:10 2457kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bf5 Re3 5.Bc2 Rh3 6.Be4 Rc3 7.Bd3 Kh8 8.Ke2 Ra3 9.Bf5 Re3+ 10.Kd2 Rg3 11.Be4 Rh3 12.Bf5 Re3 13.Bc2 Rf3 14.Be4 Rh3
-+ (-2.98) Depth: 23 00:00:11 2811kN
1...Rg1 2.Bf5 Rg3 3.Ke2 Re3+ 4.Kd2 Kh8 5.Bd3 Rf3 6.Be4 Rh3 7.Bf5 Re3
-+ (-2.90) Depth: 24 00:00:11 2954kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bf5 Re3 5.Bc2 Rh3 6.Be4 Rc3 7.Bf5 Kh8 8.Bd3 Ra3 9.Bg6 Rf3 10.Be4 Rh3 11.Bf5 Re3 12.Bd3 Rf3 13.Be4
-+ (-2.82) Depth: 24 00:00:12 3293kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bf5 Re3 5.Bc2 Rh3 6.Be4 Rc3 7.Bf5 Kh8 8.Bd3 Ra3 9.Bg6 Rf3 10.Be4 Rh3 11.Bf5 Re3 12.Bd3 Re8 13.Bf5 Re5 14.Bc2
-+ (-2.98) Depth: 24 00:00:13 3627kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bf5 Re3 5.Bc2 Rh3 6.Be4 Rc3 7.Bf5 Kh8 8.Bd3 Ra3 9.Bg6 Kg7 10.Bf5 Rg3 11.Ke2 Re3+ 12.Kd2 Rf3 13.Bg6 Kh8 14.Be4 Rh3 15.Bc2 Ra3 16.Be4 Kg7 17.Bg6
-+ (-2.94) Depth: 25 00:00:16 4529kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bf5 Re3 5.Bc2 Rf3 6.Bg6 Kh8 7.Be4 Rh3 8.Bc2 Ra3 9.Be4 Kg7 10.Bg6 Rf3 11.Bc2 Re3 12.Bf5 Kh8 13.Bd3 Rg3 14.Be4 Rc3 15.Bd3 Ra3 16.Bf5 Rc3 17.Bd3
-+ (-2.90) Depth: 26 00:00:21 6267kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bf5 Re3 5.Bc2 Rf3 6.Bg6 Kh8 7.Be4 Rh3 8.Bf5 Ra3 9.Be4 Kg7 10.Bg6 Rf3 11.Bc2 Re3 12.Bf5 Kh8 13.Bd3 Rg3 14.Be4 Rc3 15.Bd3 Ra3 16.Be4
-+ (-2.90) Depth: 27 00:00:32 9878kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bf5 Re3 5.Bc2 Rf3 6.Bg6 Kh8 7.Be4 Rh3 8.Bf5 Ra3 9.Be4 Kg7 10.Bg6 Rh3 11.Be4 Rb3 12.Bf5 Rg3 13.Be4 Kh8 14.Bf5 Re3 15.Bd3 Rg3 16.Bf5
-+ (-2.90) Depth: 28 00:00:39 12208kN
1...Rg1 2.Bf5 Rg3 3.Ke2 Re3+ 4.Kd2 Rf3 5.Bb1 Re3 6.Bf5
-+ (-2.82) Depth: 29 00:00:47 15032kN
1...Rh1 2.Be4 Rh3 3.Bf5 Rh2+ 4.Kd3 Kf6 5.Be4 Ke5 6.Bg6 Rh3+ 7.Kd2 Rh4 8.Ke2 Rh3 9.Kf2 Kf4 10.Bd3 Rh4 11.Bg6 Rh2+ 12.Kg1 Rh6 13.Kf2 Rh3
-+ (-2.98) Depth: 29 00:00:58 19314kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bf5 Rc3 5.Bd3 Kh8 6.Ke2 Rb3 7.Kd2 Rb2+ 8.Bc2 Ra2 9.Kd3 Kxh7 10.Bb1 Rb2 11.Bc2 Kg6 12.Ba4 Kf5 13.Kxd4 Rd2+ 14.Ke3 Ra2 15.Bc6 Ke5 16.Bd5 Ra3+ 17.Kf2
-+ (-2.90) Depth: 29 00:01:03 20822kN
1...Rg1 2.Bf5 Rg3 3.Be4 Kh8 4.Bf5 Kg7
-+ (-2.82) Depth: 30 00:01:07 22382kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bf5 Rf3 5.Bg6 Rh3 6.Be4 Rb3 7.Bd3 Rb2+ 8.Bc2 Ra2 9.Kd1 Ra3 10.Ke2 Kh8 11.Bd3 Rb3 12.Kd2 Rb2+ 13.Bc2 Ra2 14.Kc1 Ra5 15.Kd2 Ra2
-+ (-2.74) Depth: 30 00:01:17 26122kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bf5 Rf3 5.Bg6 Rh3 6.Be4 Rc3 7.Bd3 Kh8 8.Ke2 Ra3 9.Bf5 Rg3 10.Kd2 Re3 11.Bd3 Rh3 12.Bf5 Rg3 13.Be4 Rc3 14.Bd3 Ra3 15.Be4 Rb3 16.Bc2 Rb2 17.Kd3
-+ (-2.82) Depth: 30 00:01:26 29192kN
1...Rg1 2.Bf5 Rg3 3.Be4 Rc3 4.Bd3 Kh8 5.Ke2 Ra3 6.Bf5 Rg3 7.Kd2 Re3 8.Bc2 Ra3 9.Be4 Rc3 10.Bd3 Ra3 11.Be4
-+ (-2.74) Depth: 31 00:01:31 31311kN
1...Rg1 2.Bf5 Rg5 3.Be4 Rg3 4.Bf5 Rf3 5.Bg6 Re3 6.Bc2 Kh8 7.Bf5 Rf3 8.Be4 Rh3 9.Bf5 Re3 10.Bd3 Rh3 11.Bf5
-+ (-2.66) Depth: 31 00:01:45 36152kN
1...Rh1 2.Be4 Rh3 3.Bb1 Rh2+ 4.Kd3 Rh1 5.Bc2 Rh4 6.h8N Kxh8
-+ (-2.90) Depth: 31 00:02:03 42735kN
1...Rh1 2.Bc2 Rh2+ 3.Kd3 Kxh7 4.Ba4 Rh4 5.Bc6 Kg7 6.Be4 Kf6 7.Kxd4 Ke6 8.Kd3 Ke5 9.Bd5 Rh3+ 10.Kd2 Rg3 11.Ke2 b5
-+ (-2.98) Depth: 31 00:02:08 44576kN
1...Rh1 2.Bc2 Rh2+ 3.Kd3 Kxh7 4.Ba4 Rh4 5.Bc6 Kg7 6.Be4 Kf6 7.Kxd4 Ke6 8.Kd3 Ke5 9.Bc6 Rh3+ 10.Kd2 Rg3 11.Ke2 Rc3 12.Bd5 Kd4
-+ (-3.15) Depth: 31 00:02:13 46211kN
1...Rh1 2.Be4 Rh3 3.Bf5 Rh2+ 4.Kd3 Kf6 5.Be4 Ke5 6.Bg6 Rh3+ 7.Ke2 Kf4 8.Kd2 Rh2+ 9.Kd3 Ke5 10.Bf5 Kxf5

Analysis by Stockfish 1.7.1 JA [passed pawns (endgame) =0; Hash=clear]:
1...Rg1
-+ (-2.58) Depth: 1 00:00:00
1...Rg1 2.Be4
-+ (-2.34) Depth: 2 00:00:00
1...Ra4 2.Kd3
-+ (-2.62) Depth: 2 00:00:00
1...Ra4 2.Kd3 Ra8
-+ (-2.38) Depth: 3 00:00:00
1...Ra4 2.Kd3 Ra8 3.Be4
-+ (-2.22) Depth: 4 00:00:00
1...Rg1 2.Be4 Rg3 3.Bf5
-+ (-2.34) Depth: 4 00:00:00
1...Ra3 2.Be4 Rc3 3.Bd3
-+ (-2.42) Depth: 4 00:00:00
1...Ra3 2.Be4 Rc3 3.Bd3 Ra3
-+ (-2.50) Depth: 5 00:00:00
1...Ra3 2.Be4 Re3 3.Bf5 Re5 4.Bd3
-+ (-2.46) Depth: 6 00:00:01 3kN
1...Ra3 2.Be4 Re3 3.Bf5 Re5 4.Bc2 Rh5
-+ (-2.46) Depth: 7 00:00:01 4kN
1...Ra3 2.Be4 Re3 3.Bf5 Re5 4.Bc2 Rh5 5.Kd3
-+ (-2.38) Depth: 8 00:00:01 6kN
1...Ra3 2.Be4 Re3 3.Bc2 Rc3 4.Bd3 Ra3 5.Be4
-+ (-2.30) Depth: 8 00:00:01 8kN
1...Ra3 2.Be4 Rh3 3.Bf5 Rh5
-+ (-2.54) Depth: 8 00:00:01 11kN
1...Ra3 2.Be4 Rh3 3.Bf5 Rh5
-+ (-2.62) Depth: 8 00:00:01 12kN
1...Ra3 2.Be4 Rh3 3.Bf5 Rh2+ 4.Kd3 Kf6
-+ (-2.78) Depth: 8 00:00:01 14kN
1...Ra3 2.Bd3 Ra2+ 3.Bc2 d3 4.Kxd3 Kxh7 5.Bb3 Ra3
-+ (-2.30) Depth: 8 00:00:01 18kN
1...Ra3 2.Bd3 Ra2+ 3.Bc2 d3 4.Kxd3 Kxh7 5.Bb3 Ra3
-+ (-2.46) Depth: 9 00:00:01 21kN
1...Ra3 2.Bd3 Ra2+ 3.Bc2 d3 4.Kxd3 Kxh7 5.Bd1 Kg6 6.Bg4 Kf6
-+ (-2.54) Depth: 9 00:00:01 23kN
1...Rh1 2.Be4 Rh3 3.Bf5 Rh2+ 4.Kd3 Kf6
-+ (-2.62) Depth: 9 00:00:01 25kN
1...Rh1 2.Be4 Rh3 3.Bf5 Rh2+ 4.Kd3 Kf6
-+ (-2.94) Depth: 9 00:00:01 26kN
1...Rh1 2.Be4 Rh3 3.Bc2 Kf6 4.Ke2 Ke5 5.Bd3 Re3+ 6.Kd2 Rh3
-+ (-3.15) Depth: 9 00:00:01 35kN
1...Rh1 2.Be4 Rh3 3.Bc2 Kf6 4.Ke2 Ke5 5.Bd3 Rh2+ 6.Kf3 Rh6 7.Be4 Rh4 8.Bd3 Rf4+ 9.Kg3
-+ (-3.03) Depth: 10 00:00:01 44kN
1...Rh1 2.Be4 Rh3 3.Bc2 Kf6 4.Ke2 Ke5 5.Bd3 Rh2+ 6.Kf3 Rh6 7.Be4 Rh4 8.Bd3 Rf4+ 9.Kg3
-+ (-3.03) Depth: 11 00:00:01 53kN
1...Rh1 2.Bc2 Rh3 3.Be4 Kf6 4.Ke2 Ke5 5.Bd3 Kf4 6.Bg6 Rh2+ 7.Kd3 Ke5
-+ (-3.11) Depth: 12 00:00:01 69kN
1...Rh1 2.Be4 Rh3 3.Bc2 Kf6 4.Ke2 Ke5 5.Bd3 Kf4 6.Bg6 Rh2+ 7.Kd3 Ke5
-+ (-3.19) Depth: 12 00:00:01 74kN

[Sven]

One should almost never consider changing code because of one test position

100 point bonus [passed pawns (endgame)] makes correct play more difficult (time-consuming) or impossible, if opposite Pawn reached 7(2) line, and King should be active.

Example (one of many tested by me):
[d] 8/6kP/1p4B1/8/2Pp4/8/3K4/r7 b - - 0 1
correct play: 1...Rh1 and next Kg7->f6->e5 e.g. 2.Be4 Rh3 3.Bf5 Rh2+ 4.Kd3 Kf6 5.Be4 Ke5 6.Bg6 Rh3+ 7.Kd2 Kf4 8.Ke2 Rh2+ 9.Kd3 Ke5 -+

Analysis by Stockfish 1.7.1 JA [passed pawns (endgame) =100]:
[...]
1...Rh1 2.Bc2 Rh2+ 3.Kd3 Kxh7 4.Ba4 Rh4 5.Bc6 Kg7 6.Be4 Kf6 7.Kxd4 Ke6 8.Kd3 Ke5 9.Bc6 Rh3+ 10.Kd2 Rg3 11.Ke2 Rc3 12.Bd5 Kd4
-+ (-3.15) Depth: 31 00:02:13 46211kN
1...Rh1 2.Be4 Rh3 3.Bf5 Rh2+ 4.Kd3 Kf6 5.Be4 Ke5 6.Bg6 Rh3+ 7.Ke2 Kf4 8.Kd2 Rh2+ 9.Kd3 Ke5 10.Bf5 Kxf5

Analysis by Stockfish 1.7.1 JA [passed pawns (endgame) =0; Hash=clear]:
[...]
1...Rh1 2.Bc2 Rh3 3.Be4 Kf6 4.Ke2 Ke5 5.Bd3 Kf4 6.Bg6 Rh2+ 7.Kd3 Ke5
-+ (-3.11) Depth: 12 00:00:01 69kN
1...Rh1 2.Be4 Rh3 3.Bc2 Kf6 4.Ke2 Ke5 5.Bd3 Kf4 6.Bg6 Rh2+ 7.Kd3 Ke5
-+ (-3.19) Depth: 12 00:00:01 74kN

Your first test position from the beginning of this thread was better since there Stockfish does not even find a winning line with search in case of default settings - assuming the analysis of the winning plan you have shown is correct, which I did not check in detail. In the new position above, SF needs roughly 2 seconds on your system to find Rh1 followed by king activation. So in this new case, as you mentioned, a possible improvement that helps to evaluate the position with active king correctly would "only" affect the search time but not the result.

I agree to your opinion that there may be some room for improvement of the passed pawns evaluation of SF, and I had already described in detail what I believe is the root cause of that behaviour. Currently we'll have to accept that the SF team considers this as a case too special for adding more code, which I can fully understand although I have a different opinion.

Please note again, however, that you are probably still misinterpreting the meaning of the UCI parameter "Passed pawns (endgame)" that you have been playing with. It is not an absolute bonus but a weight, which can make a huge difference. See my first reply in this thread. Setting that weight to 0 is of course *not* a valid option for the general case, since that would nearly disable all passed pawn evaluations in all endgames.

Sven

[lech]

One should almost never consider changing code because of one test position

100 point bonus [passed pawns (endgame)] makes correct play more difficult (time-consuming) or impossible, if opposite Pawn reached 7(2) line, and King should be active.

Example (one of many tested by me):
[d] 8/6kP/1p4B1/8/2Pp4/8/3K4/r7 b - - 0 1
correct play: 1...Rh1 and next Kg7->f6->e5 e.g. 2.Be4 Rh3 3.Bf5 Rh2+ 4.Kd3 Kf6 5.Be4 Ke5 6.Bg6 Rh3+ 7.Kd2 Kf4 8.Ke2 Rh2+ 9.Kd3 Ke5 -+

Analysis by Stockfish 1.7.1 JA [passed pawns (endgame) =100]:
[...]
1...Rh1 2.Bc2 Rh2+ 3.Kd3 Kxh7 4.Ba4 Rh4 5.Bc6 Kg7 6.Be4 Kf6 7.Kxd4 Ke6 8.Kd3 Ke5 9.Bc6 Rh3+ 10.Kd2 Rg3 11.Ke2 Rc3 12.Bd5 Kd4
-+ (-3.15) Depth: 31 00:02:13 46211kN
1...Rh1 2.Be4 Rh3 3.Bf5 Rh2+ 4.Kd3 Kf6 5.Be4 Ke5 6.Bg6 Rh3+ 7.Ke2 Kf4 8.Kd2 Rh2+ 9.Kd3 Ke5 10.Bf5 Kxf5

Analysis by Stockfish 1.7.1 JA [passed pawns (endgame) =0; Hash=clear]:
[...]
1...Rh1 2.Bc2 Rh3 3.Be4 Kf6 4.Ke2 Ke5 5.Bd3 Kf4 6.Bg6 Rh2+ 7.Kd3 Ke5
-+ (-3.11) Depth: 12 00:00:01 69kN
1...Rh1 2.Be4 Rh3 3.Bc2 Kf6 4.Ke2 Ke5 5.Bd3 Kf4 6.Bg6 Rh2+ 7.Kd3 Ke5
-+ (-3.19) Depth: 12 00:00:01 74kN

Your first test position from the beginning of this thread was better since there Stockfish does not even find a winning line with search in case of default settings - assuming the analysis of the winning plan you have shown is correct, which I did not check in detail. In the new position above, SF needs roughly 2 seconds on your system to find Rh1 followed by king activation. So in this new case, as you mentioned, a possible improvement that helps to evaluate the position with active king correctly would "only" affect the search time but not the result.

I agree to your opinion that there may be some room for improvement of the passed pawns evaluation of SF, and I had already described in detail what I believe is the root cause of that behaviour. Currently we'll have to accept that the SF team considers this as a case too special for adding more code, which I can fully understand although I have a different opinion.

Please note again, however, that you are probably still misinterpreting the meaning of the UCI parameter "Passed pawns (endgame)" that you have been playing with. It is not an absolute bonus but a weight, which can make a huge difference. See my first reply in this thread. Setting that weight to 0 is of course *not* a valid option for the general case, since that would nearly disable all passed pawn evaluations in all endgames.

Sven

It regards mainly (only ?) Pawns on 7 (2) rank.
The difference is 2 minutes !!! (not seconds ). I hope your code can improve it. I will check it!

[Sven]

It regards mainly (only ?) Pawns on 7 (2) rank.

That could be explained by the way SF calculates the bonus for king proximity which seems to be about doubled for 7th compared to 6th rank.

The difference is 2 minutes !!! (not seconds ).

Oops ... that is indeed a lot more than my eyes wanted me to see ...

I hope your code can improve it. I will check it!

The code that I posted does *not* address this problem (so testing it should not result in *any* difference), it was only an attempt of restructuring the current passed pawn eval code into smaller functions. But Marco does not like it this way, and I have no problem to accept that for now. I have not investigated yet into any modification based on the original code structure since I'm waiting for Marco to possibly come up with his own final cleanup proposal, until now there were some open points. No need to hurry here, of course.

Sven

[Sven]

I hope your code can improve it. I will check it!

The code that I posted does *not* address this problem (so testing it should not result in *any* difference), it was only an attempt of restructuring the current passed pawn eval code into smaller functions. But Marco does not like it this way, and I have no problem to accept that for now. I have not investigated yet into any modification based on the original code structure since I'm waiting for Marco to possibly come up with his own final cleanup proposal, until now there were some open points. No need to hurry here, of course.

The following is addressed not only to you, Marek, but also to the SF team and maybe also Ralph.

A possible test that can be done right now could be to completely remove (comment out) the "king proximity" evaluation for the defending king from the original SF 1.7.1 version, which is in line 906 of evaluate.cpp.

Code: Select all

ebonus += Value(square_distance(theirKingSq, blockSq) * 6 * tr);

(Btw, the comment in line 899 should be moved right above current line 904.) This would indicate whether my assumption is correct that defending king proximity calculation affects behaviour in your test position(s). Of course: without zeroing the UCI weight.

Then, as a second step (possibly independent from the first), it could be tested whether removing this defending king proximity makes SF play stronger or weaker in general, not related to your special positions.

Sven