values for chess figures...

[Sven]

Another good example that shows how drastically piece values are altered when there is no promise of an end-game is of course the Knights vs Queens position:
[d]1q1qk1q1/3ppp2/8/8/8/1NN2NN1/3PPP2/2NNKN2 w - -
The Queens are slaughtered, because they have no easy way to trade down to an end-game. So the Knights can exploit their higher middle-game value compared to Queen indefinitely. so 7 Knights (classical piece value 21) beat 3 Queens (classical value 27) easily.

Please share your well-founded analysis of that position with us (with me), and please explain why you say that the queens will be "slaughtered". Have you written a program specialized for such kind of positions that finds the "truth" better than today's strongest chess engines?

It may be true that the queen side has no easy way to trade down to endgame. But why does that make the position won for white? It could be a draw, if the best that white can enforce is to trade something like NNN vs QP. It still needs a proof that white can enforce winning each queen for not more than two knights.

In my opinion the position *could* be close to a draw, although I see no way for me to really analyze it properly.

Clearly the large number of knights would require a well-tuned material imbalance function (or table), since even the positional penalties for highly restricted queen mobility due to many squares being controlled by knights will usually not be sufficient to correctly evaluate that situation. However, I doubt that many strong engines include such specialized knowledge since positions with seven knights of one color do not occur in practical game play so adding that knowledge does not add elo points. You know that this is an important argument for many of us.

If the requirements are different from "elo gain" then for me the solution is still based on the "imbalance" functionality and not much related to the basic settings of the material values. The latter are just a starting point matching sufficiently enough "real" chess positions, while it is clear that you can also define examples like this one where these material values fail miserably without additional mechanisms like "imbalance". In middlegame, three knights might roughly equalize one queen, but maybe the equivalent for two queens is already closer to five than to six knights. Are there any "scientific" data about that?

Also I can't follow your statement about the "higher middlegame value of knights compared to queens". Your example only shows that the combination of many knights creates additional power but when leaving your very special example, one queen is still much stronger than a knight even in middlegame, in the vast majority of "real" standard chess cases.

Sven

[Sven]

I think this is sort of a pointless distinction because, as Miguel points out, the value of a pawn varies a lot with the position. Therefore specifying the value of a pawn is a somewhat fuzzy endeavor. It's impossible to insist on "one pawn = 100 evaluation units" once you acknowledge that the value of a pawn is not a constant.

In daydreamer, I think on average pawns are worth about 100 if you discard passer bonuses. However, their value varies based on game phase, location, pawn structure, etc. There's not any place in the code that says "Pawn = 100". Their base value is 85 in the midgame and 115 in the endgame. I guess you could say that this is confusing, but at least it acknowledges that pawn values aren't static over the course of a game.

As I already said several times: your way of letting the pawn value vary between 85 and 115 is fully ok, it is just that your evaluation unit is not "centipawns", and that nobody can tell easily how much your knight is worth relative to your pawn.

As an example, if your material values were:

Code: Select all

piece    MG   EG
================
pawn     85  115
knight  325  325
bishop  325  325
rook    500  500
queen   975  975

then the following would be mathematically "equivalent" to it (except for rounding) by scaling up all MG and EG values accordingly (by a factor of 100/85), possibly also including positional scores:

Code: Select all

piece    MG   EG
================
pawn    100  135
knight  382  382
bishop  382  382
rook    588  588
queen  1147 1147

You can't tell easily which is "better" IMO, except for the eye perhaps. But at least the latter shows better how much your pieces are worth compared to a "midgame pawn".

Scaling down the EG values in the latter example so that the EG pawn value is also 100 would be possible, too, and would reveal an EG knight value of less than three pawns in that example. I am not sure whether I would go that far but at least it would be more consistent to do so than not.

Sven

[lkaufman]

Missing from all the replies so far is any discussion of the difference between optimum values for computers and optimum values for human GMs. I believe that there are clear differences, although we can only speculate as to why this is so. The computers seem to do better with a higher queen value and lower minor piece values than the optimum values for human GMs.
To avoid all the endless arguments about what standard to use, what phase of the game, etc. I propose the following set of standards for discussion of values, and suggest that programs be written to conform to this standard (Rybka and Komodo both come close, but I had not yet fully defined this standard when I worked on their evals). The game phase should have half of the total non-pawn material remaining on the board (using whatever values you use). Total pawn count should be ten. A pawn must be neither passed nor "bad" (isolated, doubled, or backward). The piece or pawn in question shall be on the b3 square for White, b6 for Black (I consider this the most neutral square in general). A pawn conforming to the above shall be 1.00.
My original values of 3.25, 3.25, 5, and 9.75 (and 0.5 for the bishop pair) were based on an overall average from GM games, but with the above restrictions the pawn is probably worth a bit less than average so the values rise a bit. For human use I would recommend 3.5 for knight and bishop, 5.25 for rook, and 10 for queen, again with 0.5 for the bishop pair. But with computers, some things change. The bishop is worth more than the knight, roughly 0.1 pawn more, which reduces the bishop pair to about 0.4 so that BB vs BN will remain half a pawn. The rook gains a bit, as the rook for knight exchange seems to be worth the full two pawns in computer play. The queen gains even more; queen vs. two rooks (with half the minors present and the ten pawns specified) is pretty close to even. So we might have N=3.5, B=3.6, R=5.5, Q=11 (maybe just a tad less). This may depend on program specifics; for example a program which does not include checks in quiescence might value a queen higher than one which does.
I leave it to the readership to explain why these differences between humans and computers exist.

[Aaron Becker]

As I already said several times: your way of letting the pawn value vary between 85 and 115 is fully ok, it is just that your evaluation unit is not "centipawns", and that nobody can tell easily how much your knight is worth relative to your pawn.

As an example, if your material values were:

Code: Select all

piece    MG   EG
================
pawn     85  115
knight  325  325
bishop  325  325
rook    500  500
queen   975  975

then the following would be mathematically "equivalent" to it (except for rounding) by scaling up all MG and EG values accordingly (by a factor of 100/85), possibly also including positional scores:

Code: Select all

piece    MG   EG
================
pawn    100  135
knight  382  382
bishop  382  382
rook    588  588
queen  1147 1147

You can't tell easily which is "better" IMO, except for the eye perhaps. But at least the latter shows better how much your pieces are worth compared to a "midgame pawn".

Scaling down the EG values in the latter example so that the EG pawn value is also 100 would be possible, too, and would reveal an EG knight value of less than three pawns in that example. I am not sure whether I would go that far but at least it would be more consistent to do so than not.

Sven

If my pawns are worth 100 on average over a large number of positions, how is it misleading to call my unit of measurement a centipawn? In your rescaled system, pawns are worth over 100 on average, so how is that closer to a true centipawn system? Or by "pawn=100" do you mean "midgame pawn on e2 with no structural weaknesses=100"? That's is not what I'd call intuitive or simple. In my system a pawn in the right game phase (midway between midgame and endgame) is worth exactly 100 for its material score. Why should we say that a midgame pawn=100 system is centipawns, an endgame pawn=100 system is centipawns, but this system is not? It's completely arbitrary.

[Sven]

Larry, I regard your posting as a very interesting and helpful contribution, many thanks!

One question remains for me: in the beginning you wrote

The computers seem to do better with a higher queen value and lower minor piece values than the optimum values for human GMs.

but later on your suggested values for minor pieces in computer play are >= your values for human play:

For human use I would recommend 3.5 for knight and bishop, 5.25 for rook, and 10 for queen, again with 0.5 for the bishop pair. But with computers, some things change. [...] So we might have N=3.5, B=3.6, R=5.5, Q=11 (maybe just a tad less).

So may I assume that the first part is somewhat outdated?

Sven

[lkaufman]

Well, it's semantics. For computers the minor pieces are worth less relative to the major pieces than for humans. I don't have any basis for saying that the minors are worth more or less relative to pawns for engines than for humans, so I kept knight at 3.5. The piece for pawns ratio is the trickiest, because the value of the pawn is so dependent on exactly what pawn you define as average. You can be very specific for engines, but when humans say they value a knight at 3 or 3.5 pawns or whatever, they have different meanings of "pawn" in mind.

[Sven]

If my pawns are worth 100 on average over a large number of positions, how is it misleading to call my unit of measurement a centipawn? In your rescaled system, pawns are worth over 100 on average, so how is that closer to a true centipawn system? Or by "pawn=100" do you mean "midgame pawn on e2 with no structural weaknesses=100"? That's is not what I'd call intuitive or simple. In my system a pawn in the right game phase (midway between midgame and endgame) is worth exactly 100 for its material score. Why should we say that a midgame pawn=100 system is centipawns, an endgame pawn=100 system is centipawns, but this system is not? It's completely arbitrary.

Maybe we are all saying the same, just with different words. Maybe you are right that using a range [85..115] for pawn values is sufficient to say that your "reference pawn" has a value of 100 and therefore your system may also be called a centipawn system.

So I now officially tag your engine with the "centipawn certificate"

Former arguments were different, there a pawn was in the range [80..90] or so. I would definitely keep up my proposal to scale that up, for the reasons I already gave.

Also Larrys post showed me that it makes sense to define reference conditions that are somehow related to the middle of the game, not necessarily to the opening.

Sven