The value of a pawn

[Evert]

We all know (I guess) that the exact value of a pawn is variable during a game (despite nominally having pawn=100). In Jazz, pawns have always been scored as "material_value = number_of_pawns*100 + few_pawn_penalty[number_of_pawns]", the idea being that you get a penalty for having too few pawns (making it harder to win the end game, but clearly the term only does anything if there is an unbalanced number of pawns per side). I've recently changed this to "material_value = score[number_of_pawns]", which is simpler. I've then used CLOP to determine the score as a function of the number of pawns (if you will, this is a different way to scale pawn value with game phase, using number of pawns rather than weighed number of pieces as a proxy).

The following is based on CLOP-derived parameters after 95000 games. Not all values seem equally well conserved, but the "all" column shows that the derived values are "clearly better" (+85 elo) than the old values (one question I have is if I can trust that this has converged, despite average values not changing very much anymore and the "all" column showing an improvement) - but I have NOT verified this yet by testing the values in actual play. So take the following with a pinch of salt.

Working back to the value of a single pawn, as a function of the number of remaining pawns (for that side) I get

Code: Select all

 1   -> 136
 2   -> 135
 3   -> 135
 4   -> 120
 5   -> 112
 6   -> 110
 7   -> 117
 8   -> 106

In other words, the last three pawns are clearly worth more than the first five, and the fifth pawn seems to be worth more than the sixth (ie, the transition is "smooth" when going from 5->3 pawns remaining).

Two things mainly surprise me: the last pawn does not have a higher value than the last two pawns. I would have expected the last pawn to be worth much more because if you fail to hang onto it you may not win the game even if you are ahead in material. This may be very hard to measure though.

The real surprise is the jump from 8->7 pawns, which are actually the most well-determined values of all (judging from the size of the error region), so the jump looks "real". It is surprising because if you work out the change in material value between 7 and 8 pawns, losing a single pawn from the opening position only sets you back ~30cp, which means you already have compensation if you have the bishop pair and your opponent does not. My gut-feeling says this can't be right and you need more, but perhaps it's not a great deal more?

Anyway, my real question was, does anyone else have an opinion/intuition about this?

[Sven]

One question coming into my mind is whether the value of a pawn really depends on the total number of friendly pawns, or in fact on the game phase. If I set pawnValueEG=110 and pawnValueMG=90, for instance, and if I further guess that "middlegame" might imply ~6 pawns on average and "endgame" ~3 pawns (a very rough estimate, of course), then the two ratios 110/90 = 1.2222 and 135/110 = 1.2273 are not too far away from each other. So it might be possible that any connection between the CLOP parameters you derived from many games and the total number of friendly pawns is in fact "arbitrary" and could be replaced by another relationship.

Perhaps you can test my theory by repeating your CLOP run with "number of enemy non-pawn, non-king pieces" instead of "number of friendly pawns". I would expect similar results, simply stating that the value of a pawn increases towards the endgame.

Another question would be whether the number of present a/h pawns (which usually have a lower value than other pawns) might have any disturbing influence on your measurement. For instance, in the initial position each side has 25% a/h pawns while later this ratio might go well below 25% if one of the two a/h pawns has already disappeared (which is quite likely in real game play due to the lower value).

These are just my thoughts - you asked for them ...

Sven

[hgm]

I think this is a fundamentally wrong model of material value. The last Pawn is only worth a lot to the leading side. Implementing it as an unconditional piece value would also make the weak side cling on to its last Pawn, which is often losing. E.g. in KNPPKBP. Trade your last Pawn for his non-last, and you have an easy draw through a B for P sac. Trade your B for his N, and it is almost always lost.

You can tune Pawn values until doomsday, but you will never get anything that is remotely as good as just dividing the score by (a completely guessed) two if the leading side has no Pawns. It is like fitting a circle with a square, and then worrying about the third decimal of the size to get a 'good' fit.

[jdart]

I agree with this.

I actually do not adjust pawn value by game phase, but I accomplish the same thing by adjusting the material score based on piece & pawn configuration and game phase.

As is well-known, in general, the side that is ahead material should be encouraged to trade pieces but not pawns.

In particular trading or losing pawns should be avoided if the non-pawn piece configuration is known to be drawish (for example KRN vs KR).

--Jon

[Karlo Bala]

I agree with this.

As is well-known, in general, the side that is ahead material should be encouraged to trade pieces but not pawns.

--Jon

Yes, but stronger side should keep the position reasonably open. IMHO 4-5 pawns are the optimal number for the stronger side (even better if pawns are on a different side of a board).

[Evert]

One question coming into my mind is whether the value of a pawn really depends on the total number of friendly pawns, or in fact on the game phase.

Well, I think it does depend on the game phase, with the value of the pawn maybe going up a bit when there are few of them left. "Game phase" is a vague term, however, and there's probably more than one way to incorporate that concept into an evaluation (and it'd be boring if we all did it the same way).

As I said, one way to look at it is that "number of pawns" is a proxy for "game phase" in the sense that when you have 4 or 5 pawns left it's more likely that you're in an end-game position than a middle-game position.

By the way, let's not forget that raw material is not the only term either: there's double pawn, passed pawn and any number of additional evaluation terms.

So it might be possible that any connection between the CLOP parameters you derived from many games and the total number of friendly pawns is in fact "arbitrary" and could be replaced by another relationship.

Yes. But that's probably true of most parameterisations.

Another question would be whether the number of present a/h pawns (which usually have a lower value than other pawns) might have any disturbing influence on your measurement. For instance, in the initial position each side has 25% a/h pawns while later this ratio might go well below 25% if one of the two a/h pawns has already disappeared (which is quite likely in real game play due to the lower value).

Good question. I don't know, but the value reduction for rook pawns is included through the piece-square tables...

[Evert]

I think this is a fundamentally wrong model of material value. The last Pawn is only worth a lot to the leading side. Implementing it as an unconditional piece value would also make the weak side cling on to its last Pawn, which is often losing. E.g. in KNPPKBP. Trade your last Pawn for his non-last, and you have an easy draw through a B for P sac. Trade your B for his N, and it is almost always lost.

You can tune Pawn values until doomsday, but you will never get anything that is remotely as good as just dividing the score by (a completely guessed) two if the leading side has no Pawns. It is like fitting a circle with a square, and then worrying about the third decimal of the size to get a 'good' fit.

True, but of course I don't evaluate pawns just by counting them.

In fact, given the piece values I quoted, my last pawn is worth the same as your second-last pawn, so I'm ok with trading it. Factor in that I actually have a trade-down term that encourages the side that is behind to trade pawns and I'm quite happy to trade off one of yours. I also recognise minor+pawn vs minor as a draw-ish end-game and reduce the score if the nominally leading side doesn't have winning chances.

[bob]

I think this is basically flawed. For example, if we reach an endgame where I have pawns at a2, f2, g2 and h2, and you have pawns at f7, g7 and h7, my a2 pawn is FAR more valuable than any other pawn on the board, until it is traded to let me invade and eat all of yours. If you remove my a pawn and your f pawn, I am worse, not better, even though we have one less pawn on either side. I still have a majority, but it might not be a winning majority.

Base material value is just that, the pawns actual value is the sum of that value plus your positional scoring. And your positional scoring ought to recognize that the a pawn in the above position gets more valuable as pieces are removed, and it is already more valuable because it is a distant/outside passer. Tweaking with the pure material component doesn't seem reasonable, the rest of your scoring should add to or detract from a pawn's value in a much more accurate way.

[Eelco de Groot]

In line with Evert's experiment, I have added a line to Stockfish Hybrid's material.cpp describing the value Evert found (but with a smaller correction at the moment, just a rough guesstimate) in terms of Larry's "major piece" redundancy I have no idea if this would work, I think it probably should have a lot more preconditions. To make it work in the opening alone it probably should have a weight a little bit like e->spaceWeight.

Code: Select all

const Value RedundantPawnPenalty    = Value(  3); //[Encourage sacrificing one pawn if the other side has done so.]
												              //[This should help giving back the pawn but also the first sacrifice. EdG]

All the redundancy terms together in this version of material.cpp:

Code: Select all

  // Polynomial material balance parameters
  const Value RedundantQueenPenalty   = Value(320);
  const Value RedundantRookPenalty    = Value(550);
  const Value RedundantKnightPenalty  = Value(-50); //[Based on Harm-Geert Muller's experiments with more than two knights] 
  const Value RedundantBishopPenalty  = Value( 20); //[Two same color bishops are probably slightly redundant, but untuned. EdG]
  const Value RedundantPawnPenalty    = Value(  3); //[Encourage sacrificing one pawn if the other side has done so.]
												                //[This should help giving back the pawn but also the first sacrifice. EdG]
  const Value DelayMinortradeBonus    = Value(125); //[For Kingattacks you like to have a full complement of knights and bishops,
												                //[three knights might be powerful too, but the second degree bonus is only
													             //in combination with the bishop pair]

Code: Select all

if (pieceCount[Us][PAWN] == 8 && pieceCount[Them][PAWN] == 7)
	  value -= pieceCount[Us][BISHOP] * pieceCount[Us][KNIGHT] * RedundantPawnPenalty;

Eelco

[Evert]

Well, I've done the verification match yesterday. It comes out as ~2 elo different after 10000 games (so well within the error bar).

It's a little annoying after the CLOP results suggested a clear improvement, but I'll keep the idea in reserve to revisit later.