lech wrote:Why in pawns.cpp (evaluate_pawns() - function) pawns in endgames don’t get bonus for a chain ?
Example:
[d] 8/p2p4/8/PP2P1P1/8/8/3P4/8 w - - 0 1
bonuses:
Pg5 – 100 (only default "r"),
Pe5+d2 – 68,
Pa5+b5 – 68.
The order by the real strong: Pa5+b5 next Pg5, Pe5+d2
Maybe I can’t see something?
Yes, I could not figure that either. Maybe you saw that I changed it to a very small plus in Rainbow Serpent but if this term essentially is tuned to zero there must be some other term missing I think. Why should being part of a pawn chain be disadvantageous? Sometimes only the foremost pawn should run but that is more a concern for passed pawns. Passed pawns are not evaluated in pawns.cpp and connected passers are underevaluated anyway in Stockfish I think, the bonus for moving a passed pawn forward even if it means leaving a supporting pawn behind are always large enough that it should not influence this pawn chain term in pawns.cpp.
Eelco
Of course, it had to be an important reason to cut a bonus for “chain” pawns in endgames.
My suggestion applies to “candidate” pawns.
lech wrote:Why in pawns.cpp (evaluate_pawns() - function) pawns in endgames don’t get bonus for a chain ?
Example:
[d] 8/p2p4/8/PP2P1P1/8/8/3P4/8 w - - 0 1
bonuses:
Pg5 – 100 (only default "r"),
Pe5+d2 – 68,
Pa5+b5 – 68.
The order by the real strong: Pa5+b5 next Pg5, Pe5+d2
Maybe I can’t see something?
This is really interesting question. Originally there was a bonus. But when we used the automatic tuning system, bonus dropped to zero. I really don't know why...
if (candidate)
if (chain || !(relative_rank(Us, s) > RANK_4))
value += CandidateBonus[relative_rank(Us, s)];
lech wrote:Why in pawns.cpp (evaluate_pawns() - function) pawns in endgames don’t get bonus for a chain ?
Example:
[d] 8/p2p4/8/PP2P1P1/8/8/3P4/8 w - - 0 1
bonuses:
Pg5 – 100 (only default "r"),
Pe5+d2 – 68,
Pa5+b5 – 68.
The order by the real strong: Pa5+b5 next Pg5, Pe5+d2
Maybe I can’t see something?
This is really interesting question. Originally there was a bonus. But when we used the automatic tuning system, bonus dropped to zero. I really don't know why...
Anyone of the above can be more favorable or less favorable depending on circumstances.
Using the following "deliberately biased" set of observations:
Pa5+Pb5 is inflexible and Pa7 can actually create additional stalemating motifs.
Pg5 is inflexible.
Pe5+Pd2 is more flexible, since Pa2 can move 1 or 2 squares.
...I could reverse the order of preference. If you know a lot about pawn endings, you would realize the significance of the above observations. With a different set of observations, I can produce any order of preference desired. Which are significant when and which are not depends on "other factors." But it's kind of amusing that the tuning attempt to award bonuses for these produced zeros. I would not have predicted that, yet it is not totally implausible.
lech wrote:Why in pawns.cpp (evaluate_pawns() - function) pawns in endgames don’t get bonus for a chain ?
Example:
[d] 8/p2p4/8/PP2P1P1/8/8/3P4/8 w - - 0 1
bonuses:
Pg5 – 100 (only default "r"),
Pe5+d2 – 68,
Pa5+b5 – 68.
The order by the real strong: Pa5+b5 next Pg5, Pe5+d2
Maybe I can’t see something?
This is really interesting question. Originally there was a bonus. But when we used the automatic tuning system, bonus dropped to zero. I really don't know why...
The (auto) tuning can badly work if there are some logic bugs in the code.
See example.
[d] 8/8/pp2p2p/6p1/1P1PP1P1/1P6/8/8 w - -
Score by SF 171 (pawns.cpp; PawnInfoTable::evaluate_pawns()) for this position is White: S(-87,-124) and Black: S(-1,-45)
White:
isolated b3, b4, g4
doubled b3
candidate d4
chain d4, e4
Black:
isolated e6
chain a6, b6, g5
backward h6(/2)
The penalty for both white pawns b3, b4 is until S(-92,-118).
The score of both black pawns g5, h6 is S(-7,-17), and the score of white pawn g4 is S(-36,-35).