Passed Pawns (endgame)

[Ralph Stoesser]

Very interesting Ralph, good results! I don't know if it is significant but the draw percentage seems to diverge. At 5 seconds I would expect slightly more draws but this would already seem a significant difference, much more than one third are draws. Maybe it is hard to find out what that means if you don't know how many games there are where the Stormbonus did not affect the outcome; because for instance same side castling or just simply bad play, noise, in the shorter time control. That makes it hard to see if there is some real difference in timecontrol.

Regards, Eelco

I made the 5 sec test simultaneously with another, 20%-30% slower, computer. Therefore the both results are not be directly comparable.

[Ralph Stoesser]

The idea behind a bigger exchange bonus for Queen Storm Exchanges, Ralph's question, I think is mainly that the A-file, after castling long, is more vulnerable than the H-file after castling short. Because the castled white King does not cover the A-pawn unless he moves to the left (or to the right if Black). Also on that side the Queen might be slightly more active and there are four pawns storming forward really, on a, b, c and d-file at least that is what you might change, the d-pawn is at the moment not included in the pawn storm. If you exchange one pawn there are still three left to move forward.

That sounds correctly to me. Thanks.

@Marco
Going back to the thread topic, I would like to ask whether you (your team) have auto-tuned the passed pawn evaluation in the past? I'm asking particulary for the constants 3, 1, 6, 17 ... in the expressions

3 * tr, 1 * tr, 6 * tr, 17 * tr, ...

[zamar]

@Marco
Going back to the thread topic, I would like to ask whether you (your team) have auto-tuned the passed pawn evaluation in the past? I'm asking particulary for the constants 3, 1, 6, 17 ... in the expressions

3 * tr, 1 * tr, 6 * tr, 17 * tr, ...

No we haven't. All our autotunes attempts on passed pawn evaluation and king safety have failed so far. Unlike other evaluation parameters these seem to be quite sensitive to search depth / used time controls.

[lech]

I was looking through the function “evaluate_passed_pawns_of_color()” - evaluate.cpp .
Why is ?

Code: Select all

// 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)))
                    b3 = b2;

and not ?

Code: Select all

// 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) & pos.attacks_from<QUEEN>(s))
                    b3 = b2;

Shouldn’t be added?

Code: Select all

// If the pawn is free to advance,
// add a X-ray “friendly support” by the rook or queen behind
if  ( (pos.square_is_empty(blockSq)) && (squares_behind(Us, s) & pos.pieces(ROOK, QUEEN, Us) & pos.attacks_from<QUEEN>(s))  )
	{ ebonus += Value(tr * a);
		mbonus += Value(tr * b) }

Both the values (“a”, “b”) should stimulate a good behavior only. Sorry, I am not able to set and test it.

[Ralph Stoesser]

I was looking through the function “evaluate_passed_pawns_of_color()” - evaluate.cpp .
Why is ?

Code: Select all

// 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)))
                    b3 = b2;

and not ?

Code: Select all

    // 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) & pos.attacks_from<QUEEN>(s))
        b3 = b2;

Good question. Probably it is meant as performance tweak because of Lazy Evaluation.

Shouldn’t be added?

Code: Select all

// If the pawn is free to advance,
// add a X-ray “friendly support” by the rook or queen behind
if  ( (pos.square_is_empty(blockSq)) && (squares_behind(Us, s) & pos.pieces(ROOK, QUEEN, Us) & pos.attacks_from<QUEEN>(s))  )
	{ ebonus += Value(tr * a);
		mbonus += Value(tr * b) }

Both the values (“a”, “b”) should stimulate a good behavior only. Sorry, I am not able to set and test it.

This seems to be a logical idea. But from my several days lasting expierience with this stubborn piece of code, I would say it's very difficult to improve it.

Why are you not able to test your idea? It seems you understand the code. Compile it and use cutechess-cli to evaluate your idea against default SF.

[mcostalba]

The first condition is written like that because

Code: Select all

pos.attacks_from<QUEEN>(s)

is quite slow and it is also very rare that there are enemy rook or queen attacking the pawn from behind, so as you have written the code _always_ calculates pos.attacks_from<QUEEN>(s) instead as is written in the original version the code calls the slow pos.attacks_from<QUEEN>(s) _only_ when the first condition is true, i.e. in the rare case there are pieces behind. IOW it is an optimization trick to skip pos.attacks_from<QUEEN>(s) in the common case.


Regarding the friendly peices behind, this is an interesting idea and deserves to be tested. Thanks.

[lech]

Why are you not able to test your idea? It seems you understand the code. Compile it and use cutechess-cli to evaluate your idea against default SF.

I have an old PIII with Win98 SE. My son have a better PC, but he don’t like chess, and I respect it.

Thanks Marco for your explain. I hope my code can give a higher ELO.

[mcostalba]

Not related to the thread issue, but shouldn't that be the other way round?
pawns.cpp, line 96

Code: Select all

  // Pawn storm open file bonuses by file
  const int16_t KStormOpenFileBonus[8] = { 31, 31, 18, 0, 0, 0, 0, 0 };
  const int16_t QStormOpenFileBonus[8] = { 0, 0, 0, 0, 0, 26, 42, 26 };

If we want to attack enemy king on king side it would be good to have open files f, g and h, not open files a, b and c. The same vice versa for queen side.

Code: Select all

  // Pawn storm open file bonuses by file
  const int16_t QStormOpenFileBonus[8] = { 31, 31, 18, 0, 0, 0, 0, 0 };
  const int16_t KStormOpenFileBonus[8] = { 0, 0, 0, 0, 0, 26, 42, 26 };

(A quick test with 5000 self play games @1 sec resulted in slightly positive score in favor to the switched bonuses: +1692, -1641, =1667)

After 926 games ag 1'+0"

Mod vs Orig +159 =601 -166 -3 ELO

So the modified version faild to show an increment against the original one at one minute games. This is an hint that perhaps too fast time controls are not reliable (read do not give same results of longer ones) in this case.

Perhaps we could have an increment if we retune all with after your suggested fix...

[Ralph Stoesser]

Not related to the thread issue, but shouldn't that be the other way round?
pawns.cpp, line 96

Code: Select all

  // Pawn storm open file bonuses by file
  const int16_t KStormOpenFileBonus[8] = { 31, 31, 18, 0, 0, 0, 0, 0 };
  const int16_t QStormOpenFileBonus[8] = { 0, 0, 0, 0, 0, 26, 42, 26 };

If we want to attack enemy king on king side it would be good to have open files f, g and h, not open files a, b and c. The same vice versa for queen side.

Code: Select all

  // Pawn storm open file bonuses by file
  const int16_t QStormOpenFileBonus[8] = { 31, 31, 18, 0, 0, 0, 0, 0 };
  const int16_t KStormOpenFileBonus[8] = { 0, 0, 0, 0, 0, 26, 42, 26 };

(A quick test with 5000 self play games @1 sec resulted in slightly positive score in favor to the switched bonuses: +1692, -1641, =1667)

After 926 games ag 1'+0"

Mod vs Orig +159 =601 -166 -3 ELO

So the modified version faild to show an increment against the original one at one minute games. This is an hint that perhaps too fast time controls are not reliable (read do not give same results of longer ones) in this case.

Perhaps we could have an increment if we retune all with after your suggested fix...

It's also possible that 1000 games are not enough, because you could have not tested enough positions with opposide side castling. Maybe in this case it would make sense to only test positions from openings with opposite side castling.

What opening book and book depth did you test with?

[mcostalba]

It's also possible that 1000 games are not enough, because you could have not tested enough positions with opposide side castling. Maybe in this case it would make sense to only test positions from openings with opposite side castling.

What opening book and book depth did you test with?

I have used HS-Book.ctg with FritzGUI

Yes, it is possible that 1000 games are not enough, but I won't dedicate any more time-CPU resources to this patch.

This is my resource allocation policy: if a given patch fails to show good results after 1000 games at reasonable time control then it is discarded. If instead it shows good result it is committed.

Of course we all agree this rule is not 100% reliable, you could discard good patches or commit bad ones, but I think this is an efficent resource allocation policy that guarantees an ELO increase in the long term on a big number of patches.

I could opt to test less patches to a deeper extent, or I could opt to test more patches to a lighter extent: what I have choosen is the above rule and it proved to pay off.

So I won't change it