What is the correct value of the pieces?

[diep]

base value is base value. Period.

[Don]

Three comments:
1) The value of the pieces evolve with the phase of the game. The values you give above for Houdini are not "piece values", they're just multipliers for a more complex function. They could very well have been 100, 50, 87, 26, 151...
2) Piece values are influenced by the PST (piece-square tables). If you increase all the PST values by 10, the "piece values" will decrease by the same amount.
3) Piece values very much depend on the dynamic factors in the evaluation. If you increase the mobility score for of a piece, its static piece value will have to be decreased to maintain overall balance.

All this means that there is no such thing as a simple "piece value" in Houdini (or in any other engine, for that matter). Comparing the multiplier values you've found in the Houdini executable to classical, "human" piece values is completely meaningless.

Robert

Komodo, as well as other programs and probably Houdini too have different values for different game stages.

In Komodo we "center" everything so that the values are actually meaningful to us without too much interpretation. For example our bishop mobility is negative if the bishop is not very mobile and is close to zero when it has "average" mobility. Of course what is average is a judgement call but we try to make that judgement. So for mobility we have defined N squares of mobility to be the centering point - and that is different for each piece. Our piece square tables all have negative and positive entries also in order to capture this same concept. Whenever we implement a new evaluation concept we don't want to have to "lower" or "raise" the value of something else to compensate so we take care to "center" anything that has anything more than a trivial consequence on the evaluation function.

Our values for the opening are:

600, 3100, 3225, 4350, 9100

If i calculate that back to pawn = 1000 then that gives for
the pieces:

pawn = 1.000
knight = 5.167
bishop = 5.375
rook = 7.250
queen = 15.167

That's quite a lot for a piece in opening.

The interesting thing here is that the relative difference to sacrafice an
exchange is under 2.0 pawns. it's less than 1.9 in fact.

Most engines have a relative distance of 2.0 there or even more.

Seems in more modern automatic tuning the tuners tune it lower than 2.0

ending:

925, 3100, 3225, 5475, 9700

We also have other modifiers which have the effect of changing these such as the bishop pair, rook pair, "major piece pair involving queen" and a bunch of other stuff which also considers the effect of the pawns.

I doubt these values will work for just any program but I present them for what they are worth.

I do have a hypothesis on this too. If a program is terrible at handling some specific piece, should the value of that piece be the same as in a program that handled that piece well? Traditionally, programs did not handle their rooks well for example and the programs chances improved if there were no rooks on the board. Of course programs do well with queens too, due to tactics. In the chess club I once attended some weak kid there specializing in the use of knights because it works against weaker plays and he had a knack for playing them. For HIM, the knights were worth more than the bishops - and his entire play was based on deploying and attacking with the knights. He was not hard to beat, but you had to watch his knights and if you could win them his game fell completely apart. If he were a computer program I would say his knights NEEDED to be valued much more than the bishops.

The short version of this is that I believe the values of pieces should be somewhat based on the other heuristics - what really matters is maximizing your strengths and minimizing your weaknesses and for computer chess you have to literally assign numbers to those things.

The pawn values are understated by at least a 100 for reasons explained earlier, so you should add at least 100 to those numbers when making these calculations.

You refer to bonuses for things like passers, everyone has those Larry.

This is the basic material evaluation. It's important to factorize correctly and what i wrote down seems correct.

It is not factorizing correctly because it seems that the komodo team forgot to center the pawn value correctly by substracting something in the evaluation for pawns that are not passed pawns.

The reason the pawns appear to be too low is not primarily because of passer and candidates, even though that might be a small factor here. It's because of how we calculate mobility.

Almost every feature in a chess program is arbitrarily assigned to some piece - but in almost every case that could be viewed as arbitrary since most features interact to some degree. In the case of mobility the pawns are cheated out of many bonuses they would get for their role in the mobility calculation and the pieces absorb the difference. This basically forces the different in values to be greater than they might be otherwise.

In Komodo, mobility is counted by the safe squares the pieces can move to. Bishop and Knights cannot move to squares controlled by enemy pawns (and knights for the major pieces in addition.)

If you took the point of view that these should be bonuses the pawns earn you would also have to lower the values of everything else accordingly and our numbers would be more in line with what you probably believe is "normal."

This is precisely why you cannot take numbers from some other program and just plug then into your own program and expect it to come out they way you think. Almost every penalty and bonus in a chess program is arbitrarily attached to some piece even though the entire army is involved either directly or indirectly and those interaction affect the values of every piece.

There is another consideration too. The old books give 1,3,3,5,9 for the pieces, but this is very ill-defined. Is that the average value? Average over what? Is it the average over the entire game or just the early game or something else? Is it the median value between the best and worst values?

In Komodo we consider the values to represent how pieces are placed in well played games. In other words they are not average, but well posted. So In our piece square tables, if you "average" the values over the 64 squares they will not come out to zero.

When the book give values to the pieces this is really what they mean too.

[lkaufman]

The pawn values are understated by at least a 100 for reasons explained earlier, so you should add at least 100 to those numbers when making these calculations.

You refer to bonuses for things like passers, everyone has those Larry.

This is the basic material evaluation. It's important to factorize correctly and what i wrote down seems correct.

Of course everyone has such terms. It just works out that the way we implemented them, pawns are on average worth at least 100 mp more than their nominal value, so you need to add at least 100 to the pawn's value to get its "true" value in our program. In other words, we "centered" the pieces but not the pawns. We should correct that.

[Carotino]

On this subject, there are dozens of different evaluations, but no one was able to give a definitive answer.

That's because it is total dependant upon the rest of your evaluation.

If you have no evaluation at all, just 5 values for 4 pieces and 1 for pawn, then you'll see best value for a piece is around a 2.8

If you keep adding some chessknowledge, then this value quickly rises to 4.

I agree.

[diep]

The pawn values are understated by at least a 100 for reasons explained earlier, so you should add at least 100 to those numbers when making these calculations.

You refer to bonuses for things like passers, everyone has those Larry.

This is the basic material evaluation. It's important to factorize correctly and what i wrote down seems correct.

Of course everyone has such terms. It just works out that the way we implemented them, pawns are on average worth at least 100 mp more than their nominal value, so you need to add at least 100 to the pawn's value to get its "true" value in our program. In other words, we "centered" the pieces but not the pawns. We should correct that.

Everyone is doing that. The base values is what counts.
Don't write nonsense here you know.

If you would need to add 1 pawn to every pawn, then Komodo would give away a rook for any random knight/bishop + 1 pawn

Everyone has high piece values of course.

In far endgame, Diep's queen value is 19.2 pawns to be precise

Note that the piece values that Don posted here are similar to what Hydra seems to have been using

A pawn was 64 in Hydra and the values were similar of knight and bishop.

So divided gives similar values

This high piece value therefore is not the interesting thing. Everyone has that.

The interesting thing is the small difference of a light piece versus rook.

Just worth the equivalent of under 1.9 pawns extra.

In most programs, also Hydra and nimzo98 and Diep it's closer to 2.2 pawns equivalent

Of course the clones also have it set to under 2.0, yet it's interesting Komodo also has this....

[velmarin]

Three comments:
1) The value of the pieces evolve with the phase of the game. The values you give above for Houdini are not "piece values", they're just multipliers for a more complex function. They could very well have been 100, 50, 87, 26, 151...
2) Piece values are influenced by the PST (piece-square tables). If you increase all the PST values by 10, the "piece values" will decrease by the same amount.
3) Piece values very much depend on the dynamic factors in the evaluation. If you increase the mobility score for of a piece, its static piece value will have to be decreased to maintain overall balance.

All this means that there is no such thing as a simple "piece value" in Houdini (or in any other engine, for that matter). Comparing the multiplier values you've found in the Houdini executable to classical, "human" piece values is completely meaningless.

Robert

Komodo, as well as other programs and probably Houdini too have different values for different game stages.

In Komodo we "center" everything so that the values are actually meaningful to us without too much interpretation. For example our bishop mobility is negative if the bishop is not very mobile and is close to zero when it has "average" mobility. Of course what is average is a judgement call but we try to make that judgement. So for mobility we have defined N squares of mobility to be the centering point - and that is different for each piece. Our piece square tables all have negative and positive entries also in order to capture this same concept. Whenever we implement a new evaluation concept we don't want to have to "lower" or "raise" the value of something else to compensate so we take care to "center" anything that has anything more than a trivial consequence on the evaluation function.

Our values for the opening are:

600, 3100, 3225, 4350, 9100

If i calculate that back to pawn = 1000 then that gives for
the pieces:

pawn = 1.000
knight = 5.167
bishop = 5.375
rook = 7.250
queen = 15.167

That's quite a lot for a piece in opening.

The interesting thing here is that the relative difference to sacrafice an
exchange is under 2.0 pawns. it's less than 1.9 in fact.

Most engines have a relative distance of 2.0 there or even more.

Seems in more modern automatic tuning the tuners tune it lower than 2.0

ending:

925, 3100, 3225, 5475, 9700

We also have other modifiers which have the effect of changing these such as the bishop pair, rook pair, "major piece pair involving queen" and a bunch of other stuff which also considers the effect of the pawns.

I doubt these values will work for just any program but I present them for what they are worth.

I do have a hypothesis on this too. If a program is terrible at handling some specific piece, should the value of that piece be the same as in a program that handled that piece well? Traditionally, programs did not handle their rooks well for example and the programs chances improved if there were no rooks on the board. Of course programs do well with queens too, due to tactics. In the chess club I once attended some weak kid there specializing in the use of knights because it works against weaker plays and he had a knack for playing them. For HIM, the knights were worth more than the bishops - and his entire play was based on deploying and attacking with the knights. He was not hard to beat, but you had to watch his knights and if you could win them his game fell completely apart. If he were a computer program I would say his knights NEEDED to be valued much more than the bishops.

The short version of this is that I believe the values of pieces should be somewhat based on the other heuristics - what really matters is maximizing your strengths and minimizing your weaknesses and for computer chess you have to literally assign numbers to those things.

The pawn values are understated by at least a 100 for reasons explained earlier, so you should add at least 100 to those numbers when making these calculations.

You refer to bonuses for things like passers, everyone has those Larry.

This is the basic material evaluation. It's important to factorize correctly and what i wrote down seems correct.

It is not factorizing correctly because it seems that the komodo team forgot to center the pawn value correctly by substracting something in the evaluation for pawns that are not passed pawns.

The reason the pawns appear to be too low is not primarily because of passer and candidates, even though that might be a small factor here. It's because of how we calculate mobility.

Almost every feature in a chess program is arbitrarily assigned to some piece - but in almost every case that could be viewed as arbitrary since most features interact to some degree. In the case of mobility the pawns are cheated out of many bonuses they would get for their role in the mobility calculation and the pieces absorb the difference. This basically forces the different in values to be greater than they might be otherwise.

In Komodo, mobility is counted by the safe squares the pieces can move to. Bishop and Knights cannot move to squares controlled by enemy pawns (and knights for the major pieces in addition.)

If you took the point of view that these should be bonuses the pawns earn you would also have to lower the values of everything else accordingly and our numbers would be more in line with what you probably believe is "normal."

This is precisely why you cannot take numbers from some other program and just plug then into your own program and expect it to come out they way you think. Almost every penalty and bonus in a chess program is arbitrarily attached to some piece even though the entire army is involved either directly or indirectly and those interaction affect the values of every piece.

There is another consideration too. The old books give 1,3,3,5,9 for the pieces, but this is very ill-defined. Is that the average value? Average over what? Is it the average over the entire game or just the early game or something else? Is it the median value between the best and worst values?

In Komodo we consider the values to represent how pieces are placed in well played games. In other words they are not average, but well posted. So In our piece square tables, if you "average" the values over the 64 squares they will not come out to zero.

When the book give values to the pieces this is really what they mean too.

Everyone can see that 600 is not an appropriate value for the pawn,
and depends on other assessments,

But and wonder:
Why do you put your "Komodo" Static assessment of Ivanhoe's in this post?
http://www.talkchess.com/forum/viewtopi ... similarity
Do we wanted to kid?.

Or change after the evaluation?

[laoliveirajr]

The pawn values are understated by at least a 100 for reasons explained earlier, so you should add at least 100 to those numbers when making these calculations.

You refer to bonuses for things like passers, everyone has those Larry.

This is the basic material evaluation. It's important to factorize correctly and what i wrote down seems correct.

Of course everyone has such terms. It just works out that the way we implemented them, pawns are on average worth at least 100 mp more than their nominal value, so you need to add at least 100 to the pawn's value to get its "true" value in our program. In other words, we "centered" the pieces but not the pawns. We should correct that.

Larry,

I started programming at doing Capivara derivation of TSCP engine and deploying some theories as "FeWeTe" (FeldWertTheorie) << http://www.4shared.com/file/ZTYlAGhc/As ... perMa.html >> and "The Evaluation of Material Imbalances" << http://home.comcast.net/~danheisman/Art ... alance.htm >>.
The first error-free deployment of "The Evaluation of Material Imbalances" was Capivara LK 0.07s2.

Currently, do you think that your article still remain a preferred reference?
If you were to write an article today for beginners, and for those not so beginner, what would you advise??

Best wishes,
Lourenço

[lkaufman]

The pawn values are understated by at least a 100 for reasons explained earlier, so you should add at least 100 to those numbers when making these calculations.

You refer to bonuses for things like passers, everyone has those Larry.

This is the basic material evaluation. It's important to factorize correctly and what i wrote down seems correct.

Of course everyone has such terms. It just works out that the way we implemented them, pawns are on average worth at least 100 mp more than their nominal value, so you need to add at least 100 to the pawn's value to get its "true" value in our program. In other words, we "centered" the pieces but not the pawns. We should correct that.

Everyone is doing that. The base values is what counts.
Don't write nonsense here you know.

If you would need to add 1 pawn to every pawn, then Komodo would give away a rook for any random knight/bishop + 1 pawn

Everyone has high piece values of course.

In far endgame, Diep's queen value is 19.2 pawns to be precise

Note that the piece values that Don posted here are similar to what Hydra seems to have been using

A pawn was 64 in Hydra and the values were similar of knight and bishop.

So divided gives similar values

This high piece value therefore is not the interesting thing. Everyone has that.

The interesting thing is the small difference of a light piece versus rook.

Just worth the equivalent of under 1.9 pawns extra.

In most programs, also Hydra and nimzo98 and Diep it's closer to 2.2 pawns equivalent

Of course the clones also have it set to under 2.0, yet it's interesting Komodo also has this....

I think in both Rybka (and therefore the clones) and in Komodo, the two programs I worked on, the "true" value of the Exchange is very close to two pawns on average. It is lower in the opening, higher in the endgame. When you talk about the value in Hydra, Diep etc. , are you talking about the average of opening and endgame? How did you calculate it for Komodo?

[lkaufman]

Everyone can see that 600 is not an appropriate value for the pawn,
and depends on other assessments,

But and wonder:
Why do you put your "Komodo" Static assessment of Ivanhoe's in this post?
http://www.talkchess.com/forum/viewtopi ... similarity
Do we wanted to kid?.

Or change after the evaluation?

I'm sorry, I don't understand your question. Please rephrase.

[lkaufman]

The pawn values are understated by at least a 100 for reasons explained earlier, so you should add at least 100 to those numbers when making these calculations.

You refer to bonuses for things like passers, everyone has those Larry.

This is the basic material evaluation. It's important to factorize correctly and what i wrote down seems correct.

Of course everyone has such terms. It just works out that the way we implemented them, pawns are on average worth at least 100 mp more than their nominal value, so you need to add at least 100 to the pawn's value to get its "true" value in our program. In other words, we "centered" the pieces but not the pawns. We should correct that.

Larry,

I started programming at doing Capivara derivation of TSCP engine and deploying some theories as "FeWeTe" (FeldWertTheorie) << http://www.4shared.com/file/ZTYlAGhc/As ... perMa.html >> and "The Evaluation of Material Imbalances" << http://home.comcast.net/~danheisman/Art ... alance.htm >>.
The first error-free deployment of "The Evaluation of Material Imbalances" was Capivara LK 0.07s2.

Currently, do you think that your article still remain a preferred reference?
If you were to write an article today for beginners, and for those not so beginner, what would you advise??

Best wishes,
Lourenço

There is a difference between advice for human players and advice for computer programs. For human players, my original article is still pretty accurate for the average over the whole game; the values I give in my recent book are more appropriate with queens on the board. For computers, the major pieces seem to be worth a bit more relative to minor pieces than for humans, so the Exchange goes up a bit in value. The values we give for Komodo are pretty good, except as I explained the value of the pawn is too low for technical reasons.