Relative Piece Values

[mjlef]

Most strong program seem to use relative piece values of P:N:B:R:Q of roughly 1:4:4:6:12

I recently did a bunch of runs with roughly 1:4:4:5.5:12 and it did a lot better. Are these what others are using now?

[Edsel Apostol]

Most strong program seem to sue relative piece values of P:N:B:R:Q of roughly 1:4:4:6:12

I recently did a bunch of runs with roughly 1:4:4:5.5:12 and it did a lot better. Are these what others are using now?

I'm using 100, 325, 325, 500, 975. Strelka uses 100,300,300,500,1000 but there's a material correction table.

[hgm]

I recently did a bunch of runs with roughly 1:4:4:5.5:12 and it did a lot better. Are these what others are using now?

If it did a lot better then the result is suspect to begin with. The only trades it would affect are Q vs 2R and B/N+2P vs R. For both of these the opportunity to actually do such a trade should be quite rare.

I think first you should eliminate all games from your sample that did not have a Q vs 2R or B/N+2P vs R trade, and analyze only those that remain (as to their occurrence and average result). The other games only contribute noise.

[Greg Strong]

Say, H.G., what values are you using for 10x8 these days? I seem to recall you did some significant research in this area.

Thanks!

[bob]

Most strong program seem to use relative piece values of P:N:B:R:Q of roughly 1:4:4:6:12

I recently did a bunch of runs with roughly 1:4:4:5.5:12 and it did a lot better. Are these what others are using now?

I think those that use such values are using them as a crutch, to avoid the traditional problem of minor for three pawns (bad) and two minors for rook + pawn (also bad).

One can also dynamically adjust scores based on various combinations, or just catch the two above where I have always had a "bad trade" concept in Crafty so that I don't have to tweak with material values to solve that particular issue...

[Bill Rogers]

Years ago I discovered a little known fact about the value of pieces. What I did was to count the number of square that each piece could attack. I then added one point to each piece that could attack both colors with the exception of the King which I subtracted one point. When all the pieces were totaled I diveded the totals by three. It comes out to an amazingly close answer to what the pieces have been rated over the years.
Have a few spare minutes, give it a try.
Bill

[Tony]

Years ago I discovered a little known fact about the value of pieces. What I did was to count the number of square that each piece could attack. I then added one point to each piece that could attack both colors with the exception of the King which I subtracted one point. When all the pieces were totaled I diveded the totals by three. It comes out to an amazingly close answer to what the pieces have been rated over the years.
Have a few spare minutes, give it a try.
Bill

If you take the number of the day of the week, take the srt 64 times, and add 2 if the piece is a jumper, add 2 if it can move diagonally, add 4 if it can move orthoganally and add 2 if the piece starts with a Q, you will get pretty close to the default values as well.



Tony

[michiguel]

Most strong program seem to use relative piece values of P:N:B:R:Q of roughly 1:4:4:6:12

I recently did a bunch of runs with roughly 1:4:4:5.5:12 and it did a lot better. Are these what others are using now?

IMHO, It depends a lot what else it is done in evaluation. I think that looking at these values is meaningless. For instance, if you give penalties for lack of mobility of bonuses for increased mobility, it will affect the optimal value of the piece.

Miguel

[FrancoisK]

Hi,

I am using 1000 : 3250 : 3250 : 5000 : 9750 in BugChess2.
However Miquel is right : the average bonus added by evaluation should be take into account if it changes with piece type.

As I think there is room for improvement in this area in my engine, i have started generating my material table.
I am not taking positions from actual games like Alessandro suggested in a very interesting thread, my positions are randomly taken from my engine's analysis trees and selfplayed by my engine to know the result. I am already seeing significant improvements in fast selfplay matches after a few weeks.

Cheers

François

[hgm]

Say, H.G., what values are you using for 10x8 these days? I seem to recall you did some significant research in this area.

Thanks!

P = 85
N = 300
B = 350 (+40 for pair)
R = 475 (w.o. open-file bonus)
A = 875
C = 900
Q = 950

still modulated by piece-square positional values, of course. These are the values the pieces have on the squares where you typically find them in games. Note that this is not the same as averaging the PST values over the board, as in practice the pieces will avoid the squares with low values. So simple averagng would overestimate the importance of very bad squares (like corner squares for Knights).

But this is opening value, and since then I have done some tests in connection with Superchess that showed that the end-game values of the heavy pieces differ by more, and that Q-A is definitely more than a Pawn there.

I have not implemented this in any of my programs yet, though. It seems what is needed is a material interaction term, which discounts the value of high pieces for every lower (non-pawn) piece the opponent has. Due to such a term a Q vs R+B trade might be favorable in the precence of 2+2 other Queens (or C/A),, but not for a single Queen.