hgm wrote:But the Kaufman evaluation is totally trivial. Using a table for that is like using a table of integer products to save a multiplication...
It isn't as simple as that.
The edge pawns have less value than the others.
Every combination of:
KK, KB, BB will have a different value.
QP verses RR will have some edge defined for one side or the other and it will be quantified.
etc.
I don't think that there is any formula for it. It is just a probability study of material imbalance, and so for every combination for which they have data, they give a value of that combination.
hgm wrote:But the Kaufman evaluation is totally trivial. Using a table for that is like using a table of integer products to save a multiplication...
It isn't as simple as that.
The edge pawns have less value than the others.
Every combination of:
NN, NB, BB will have a different value.
QP verses RR will have some edge defined for one side or the other and it will be quantified.
etc.
I don't think that there is any formula for it. It is just a probability study of material imbalance, and so for every combination for which they have data, they give a value of that combination.
hgm wrote:But the Kaufman evaluation is totally trivial. Using a table for that is like using a table of integer products to save a multiplication...
It is not just used for the simplified formula Larry has on his webpage. The most constant thing I see it being applied to is pawn vs. piece imbalances. For example, my program will sometimes trade off a bishop or knight for 3 pawns in the opening (plus a little bit of compensation - usually a passed pawn, or some weakened king safety), and evaluates the position as equal, while Strelka will give the side with the bishop a substantial bonus from the material tables (+0.75 pawns or so iirc).
I'm amazed by how often my program trades into one of those material imbalance situations, and then ends up losing, after thinking it was ahead or even.
gladius wrote:I'm amazed by how often my program trades into one of those material imbalance situations, and then ends up losing, after thinking it was ahead or even.
I solved that problem in my passer evaluation, halving any bonuses for the side that has a smaller number of pieces. And of course the Pawn base value is chosen low enough that 3 Pawns for a Knight is considered a bad deal, unless the pawns have a really large bonus (which is difficult if it is halved and not advanced very far).
hgm wrote:But the Kaufman evaluation is totally trivial. Using a table for that is like using a table of integer products to save a multiplication...
It is not just used for the simplified formula Larry has on his webpage. The most constant thing I see it being applied to is pawn vs. piece imbalances. For example, my program will sometimes trade off a bishop or knight for 3 pawns in the opening (plus a little bit of compensation - usually a passed pawn, or some weakened king safety), and evaluates the position as equal, while Strelka will give the side with the bishop a substantial bonus from the material tables (+0.75 pawns or so iirc).
I'm amazed by how often my program trades into one of those material imbalance situations, and then ends up losing, after thinking it was ahead or even.
Just do what good chess players do and do not trade a piece for three pawns, or two pieces for a rook and pawn, unless you can actually _see_ an advantage in the resulting position. Otherwise it is just an easy way to lose slowly but surely...
hgm wrote:But the Kaufman evaluation is totally trivial. Using a table for that is like using a table of integer products to save a multiplication...
It is not just used for the simplified formula Larry has on his webpage. The most constant thing I see it being applied to is pawn vs. piece imbalances. For example, my program will sometimes trade off a bishop or knight for 3 pawns in the opening (plus a little bit of compensation - usually a passed pawn, or some weakened king safety), and evaluates the position as equal, while Strelka will give the side with the bishop a substantial bonus from the material tables (+0.75 pawns or so iirc).
I'm amazed by how often my program trades into one of those material imbalance situations, and then ends up losing, after thinking it was ahead or even.
Just do what good chess players do and do not trade a piece for three pawns, or two pieces for a rook and pawn, unless you can actually _see_ an advantage in the resulting position. Otherwise it is just an easy way to lose slowly but surely...
I think that the most interesting thing that Mr. Kaufman's work did was to quantify things that we already know. We know, for instance, that the a and h pawns are weaker than the others because they cannot attack on the missing edge. But his study found *values* for the differences. Similarly so for every imbalance of material and hence the huge table.
bob wrote:Just do what good chess players do and do not trade a piece for three pawns, or two pieces for a rook and pawn, unless you can actually _see_ an advantage in the resulting position. Otherwise it is just an easy way to lose slowly but surely...
My material values are roughly pawn = 950 cp, knight/bishop = 3250 cp, so there has to be at least 400 cp compensation for my program to go for the trade (which, if some of the pawns are part of the pawn shelter, is pretty easy to come by). So, if I had the material table bonus of 750 cp, it would need 1150 cp of compensation, which seems more in line with what should be happening.
I'm not sure what you mean by seeing an advantage though. The dynamic considerations in the position are frequently worth 400cp to my (admittedly not amazing) evaluation function, so it thinks the trade is great. 20 moves down the line however, it usually ends up being not so good . Other than handling these material imbalances, I guess I could penalize all my non-material weights in the opening, but that has lots of side effects as well.
"m" is the material imbalance with positive being good for white. It's using 100 for pawn and the material ratio for pieces is queen = 10, rook = 5, and bishop = knight = 3. "b" is the material bonus. Next is the material contents and the one in parenthesis is the material imbalance of both sides. "*" suggests a bishop pair advantage for one side.
Actually in Strelka, pawn = 106, so if you add/subtract 1/16 centipawn in all the values it would be the exact values in Strelka. I just scaled it to 100 to make it easier to compare.
The ideas for the output display came from Alessandro Scotti's Kiwi source code.
In the example above:
m= 200, b=-128 QRNNPPP rbbnnppppp (Qbbpp *)
white has the material advantage of 200 centipawns but based on the bonus it should only have 200 - 128 = 72 cp only.
The next example:
m= 100, b=-104 QRNNPPP rbbnnpppppp (Qbbppp *)
white has a 100cp advantage but based on the bonus it has a value of -4cp. This means a 4cp advantage for black even when white has the material advantage.
Any of you has ideas on how to solve this using formulas instead of collecting data from games?
Is there anyone interested to download the program I made? It outputs a 10Mb text file for the data above plus the actual material tables and flags scaled by 100, and is indexed by the indexing used in Strelka. You can use this in your engine to try if material correction tables indeed adds strenght.
I think curve/formula fitting is the best approach. I actually staretd doing that, as follows:
Merge the data for Black and while. For example, if you have
KR vs k
and
K vs kr
just add the totals together to form ona KR v k entry. This increases the counts for that imbalance and make it more statitsically relevant.
Next, split out and count the amount of each piece. You really want these numbers
P
N
B
R
Q
p
n
b
r
q
which are the counts of each piece type for each color.
Next, you need to come up with a formula for the correction:
C = -100*p +100*P -325*N + 325*n -328*b +325*B -500*r + 500*R
-900*q +900*q (these are just whatever standard values you want to give the pieces)
+A*p + B*P +C*p*n + D*p*N + E*p*b + F*p*B + G*p*r + H*p*R +
I*p*q + J*p*Q + K*n + L*N +....
and so on, with a constant for each combination of piece type counts
Then just curve fit and find the best value for each term.
I tried doing this manually, using the square of the difference between the correction and the win probabilities. You need to equate the win probablitlies to material difference to do this. I think I set 1 pawn=100 ELO...very crude.
It would be nice to find a good fit with the material in the "center" where material imbalance is not great. Who cares how good the fit is when one side is a queen ahead, since it hardly matters. In my case I only tried the manual approach for material differences of 3 or less pawns.
The above only uses linear terms. A better system could fit most of the data, and mark some positions that just do not fit well for exception handling. For example, B vs p is most likely a draw, but trying to get that to fit well might mess up other terms, and so it could be culled from the data to get a better fit of other stuff.
Is there a good (and free) package that can do these kinds of fits? I see stuff to handle a few terms, but we need a lot. 10+9+8+7+6+5+4+3+2+1 =55 actually for just the linear terms. Of course, many of these might come out to close to zero, once the data is analyzed. And if higher order terms are needed, there might be a lot more.
Another approach is to to a best fit of each term. See, for example what each term shows up on its own. If it comes close to zero it could probably be eliminated.
. Other than handling these material imbalances, I guess I could penalize all my non-material weights in the opening, but that has lots of side effects as well.