What is the correct value of the pieces?

[laoliveirajr]

Excuse me ... sometimes I confuse implementation with deployment, to translate!

Implementation == Implementação (in Portugese)
Deployment == Implantação (in Portugese)

[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.

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

A pawn is not 600 in Komodo - it is much more. The endgame value of a pawn is 950, almost 1000 and as soon as anything comes off the board it goes up - so don't get too carried away with our low values. For reasons both Larry and I stated you can probably raise these by 100 and that actually changes the ratio drastically.

It's a silly distinction because what really matters is the knight and bishop values relative to the pawns - and our base values for knights and bishops are on the low side compared to other programs if you believe that a pawn should be actually worth "exactly" 1000.

If you consider only the opening values the ratio between the pawn and knight is pretty high, but if you add 100 points (which probably reflects Komodo's true assessment) it is right in line with other programs.

So most of this is just a lot of noise that doesn't really mean much. Even if it does have some deep dark meaning these are the values that work best for Komodo as we proved to ourselves - Q.E.D. (Q.E.D. is Latin for "so there!"

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?

Are you refering to the fact that I said "a pawn is 1000 in Komodo?" If you would read this more carefully I was comparing the scales of Invahoe's evaluation which is pawn=100 to Komodo's pawn = 1000. The evaluation function for Komodo is divided by 10 before being returned to the search.

[Don]

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

If you see anything similar in the clones evaluation and Komodo's the reason is pretty obvious, Larry designed the Rybka evaluation and he also designed the Komodo evaluation. The clones were strongly based on Rybka for the evaluation function as well as the search - so this is no mystery.

Don