Passed Pawns (endgame)

[Ralph Stoesser]

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

I think your test is meaningless, because you haven't found any reliable difference at all in flipping the bonuses. But you should have found a difference.

After we have castled queen side and the opponent has castled king side, either it is good to open files on front of our king instead of opening files on enemy side, or it is the other way round (every chess player knows what's right here).

But for sure it is not meaningless how you would do it. Otherwise, if you trust your result, a good patch would be to remove the bonus completely.

I think this is a good example where a test with much more games at unreasonable fast time control is more reliable than test with few games at reasonable time control.

[zamar]

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.

Just one more demonstration how terrible our current pawn storm code is. Patch which fixes an obvious bug fails. In near future I plan to run a test to completely remove pawn storm code.

[mcostalba]

I think this is a good example where a test with much more games at unreasonable fast time control is more reliable than test with few games at reasonable time control.

Ralph, please no offence, but for me definition of reliable is not: reliable = What I would like to see out of the results

I consider the comment of Joona much more up to the point: probably that single piece of code has no effect at all, in any direction.

P.S: Regarding testing at unreasonable fast time control you have not proved they work. To prove if they work is necessary to verify them at longer time controls and check results are the same. So IMHO test at unreasonable time control are not validated and can be useful to quickly filter out some bad patches, but not to validate candidate good ones.

[lech]

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.

I think that "a" should be much smaller than "b". SF plays very light-hearted against passed pawns in middle-game. Maybe some day I will test it.

[lech]

Still about the function „evaluate_passed_pawns_of_color()” in evaluate.cpp
Why is ?

Code: Select all

// There are no enemy pawns in the pawn's path
                b2 = squares_in_front_of(Us, s);
                assert((b2 & pos.pieces(PAWN, Them)) == EmptyBoardBB);

Just earlier it was checked:

Code: Select all

assert(pos.pawn_is_passed(Us, s));

Shouldn’t remain only?

Code: Select all

                b2 = squares_in_front_of(Us, s);

I hope that an explain will be other than: it needs to make sure.

[mcostalba]

Shouldn’t remain only?

Code: Select all

                b2 = squares_in_front_of(Us, s);

yes, you are right !

Thanks for reporting this.

[lech]

Next logic doubts in the function „evaluate_passed_pawns_of_color()” of evaluate.cpp
Why is ?

Code: Select all

int r = int(relative_rank(Us, s) - RANK_2);

Shouldn’t be?

Code: Select all

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

Is there any difference between passed pawns on relative RANK_2 or RANK_3 ?

Why is?

Code: Select all

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

Shouldn’t be?

Code: Select all

d =  square_distance(s, qsq)-( relative_rank(Us, s)==RANK_2)
               - square_distance(theirKingSq, qsq)
               + (Us != pos.side_to_move());
 

Pawn on relative RANK_2 can play a double move.

Shouldn’t get some points a double rear pawn ?

Code: Select all

 
 assert ((b2 & pos.pieces(PAWN, Us)) == EmptyBoardBB);

[mcostalba]

Yes, you are right on first and second point

I will change the code but just for correctness because I really doubt to have even a single ELO of difference !

Regarding last point:

Code: Select all

 
 assert ((b2 & pos.pieces(PAWN, Us)) == EmptyBoardBB);

No, a double rear pawn is not passed, see pawns.cpp:

Code: Select all

      // In order to prevent doubled passed pawns from receiving a too big
      // bonus, only the frontmost passed pawn on each file is considered as
      // a true passed pawn.
      if (passed && (ourPawns & squares_in_front_of(Us, s)))
          passed = false;

[Ralph Stoesser]

Is there any difference between passed pawns on relative RANK_2 or RANK_3 ?

Yes, one pawn is on rank 2, the other is on rank 3.

For instance

A pawn on rank 2 could possibly become blocked by enemy piece on rank 3, 4, 5, 6, 7 and 8.
A pawn on rank 3 can become blocked on rank 4, 5, 6, 7 and 8 only.

So it's not exactly the same.

Since we are nitpicking here, I still wonder a little about that performance tweak.

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;

Is pos.attacks_from<QUEEN>(s) really that slow, that it would pay to mess up the code?
Sorry I'm too lazy to profile...

[mcostalba]

Is pos.attacks_from<QUEEN>(s) really that slow, that it would pay to mess up the code?
Sorry I'm too lazy to profile...

Yes it is....but I am not going to play 1000 games to prove it