Question for Bob Hyatt

[lkaufman]

If you cover all plausible material imbalances in your "bad trade" code, then indeed it should be functionally the same as adjusting the piece values. But Uri's comment indicated you only cover two minors vs. rook and minor vs. pawns. If so then you will be undervaluing the minors in other cases, such as three minors vs. two rooks, three minors vs. queen, rook and two minors vs. queen, and undervaluing the rook in the case of rook vs. several pawns. These are all rare, so the net Elo loss may be difficult to detect (maybe 1 point or so), but it will lead to evaluations that are obviously wrong when these rare imbalances turn up. So if you like this "bad trade" code, I would recommend covering these other cases there as well, unless perhaps you already do so.

[hgm]

OK, so it is equivalent to having altered piece values. In that case, we should ignore the piece base values in Crafty, as they are just implementation details of no fundamental value, but in stead look at the effective values including the bad-trade bonuses / penalties, as they are used to decide if a certain trade is favorable or not.

[Uri Blass]

If you cover all plausible material imbalances in your "bad trade" code, then indeed it should be functionally the same as adjusting the piece values. But Uri's comment indicated you only cover two minors vs. rook and minor vs. pawns. If so then you will be undervaluing the minors in other cases, such as three minors vs. two rooks, three minors vs. queen, rook and two minors vs. queen, and undervaluing the rook in the case of rook vs. several pawns. These are all rare, so the net Elo loss may be difficult to detect (maybe 1 point or so), but it will lead to evaluations that are obviously wrong when these rare imbalances turn up. So if you like this "bad trade" code, I would recommend covering these other cases there as well, unless perhaps you already do so.

I did not look at Crafty's relevant code and my comments are based on my memory about past posts about Crafty's bad trade code.

I am not sure if Bob cover the case of three minors vs queen
but I think that having different value of pieces is more simple than having many cases for bad trade code.

Uri

[bob]

If you cover all plausible material imbalances in your "bad trade" code, then indeed it should be functionally the same as adjusting the piece values. But Uri's comment indicated you only cover two minors vs. rook and minor vs. pawns. If so then you will be undervaluing the minors in other cases, such as three minors vs. two rooks, three minors vs. queen, rook and two minors vs. queen, and undervaluing the rook in the case of rook vs. several pawns. These are all rare, so the net Elo loss may be difficult to detect (maybe 1 point or so), but it will lead to evaluations that are obviously wrong when these rare imbalances turn up. So if you like this "bad trade" code, I would recommend covering these other cases there as well, unless perhaps you already do so.

None of this is actually correct.

First, our "bad trade" is a specific penalty, but one that is proportional to the amount of material involved. It is (today) implemented in a table:

score_mg += imbalance[majors][minors];

Majors is the total major pieces, (Q=2, R=1) for each side, with the black total subtracted from the white, with a +4 bias to make the minimum value 0. Minors is done the same way, except each minor is just 1. The table is a 9x9 array that encapsulates how we want to penalize the score for various cases, such as two minors down, a rook up, or minor down (which might mean pawns up but we don't count those). And so forth. I'd have to look at specific values in the table, but believe we have always handled the traditional cases such as 3M vs Q and such. And we are not including pawns here at all, so it is just about the pieces. Pawns are obviously counted in the material, and the more one side has, the bigger bonus for that they get just from normal scoring. But all we try to deal with here is just counting majors and minors to see how unbalanced things are.

[bob]

If you cover all plausible material imbalances in your "bad trade" code, then indeed it should be functionally the same as adjusting the piece values. But Uri's comment indicated you only cover two minors vs. rook and minor vs. pawns. If so then you will be undervaluing the minors in other cases, such as three minors vs. two rooks, three minors vs. queen, rook and two minors vs. queen, and undervaluing the rook in the case of rook vs. several pawns. These are all rare, so the net Elo loss may be difficult to detect (maybe 1 point or so), but it will lead to evaluations that are obviously wrong when these rare imbalances turn up. So if you like this "bad trade" code, I would recommend covering these other cases there as well, unless perhaps you already do so.

I did not look at Crafty's relevant code and my comments are based on my memory about past posts about Crafty's bad trade code.

I am not sure if Bob cover the case of three minors vs queen
but I think that having different value of pieces is more simple than having many cases for bad trade code.

Uri

It is trivial to deal with "many cases" using a simple array indexing scheme...

Imbalance[minors][majors] is trivial enough and can handle a bunch of different cases with no extra code.

[bob]

OK, so it is equivalent to having altered piece values. In that case, we should ignore the piece base values in Crafty, as they are just implementation details of no fundamental value, but in stead look at the effective values including the bad-trade bonuses / penalties, as they are used to decide if a certain trade is favorable or not.

I think you can ignore almost everything in that area. What is the value of a piece? It's static value? It's static value + pc/sq table value? static+pcsq+other dynamic scoring terms? And then it gets more complicated. For a knight, do you give it a bonus for blockading a pawn (knights are the best blockaders for a single pawn) or do you penalize the pawn instead? I'm not sure that individual material values make much sense in the context of "static evaluation" since there is so much that goes into this. And I completely ignored a really big contributor, king safety.

Tracy actually tried to use Larry's material value stuff a good while back, and for us it _always_ made us play worse.

[bob]

Bob,

I see you only display scores to 2 digits. If you are trying to optimize something with a small effect, would'nt displaying a bit more digits help? You are running thousands of games so at least another digit should be somewhat valid.

Not sure what you mean by "scores"???

[hgm]

Indeed, an advanced evaluation is not simply a sum of single-piece terms.

Yet the average piece value is a reasonably well-defined quantity, that can be extracted from a Chess program through the following procedure:

Create a test suite of representative positions, e.g. a few thousand positions randomly chosen from games the program has played. Run QS on those positions, and discard those where stand-pat was not the best 'move'. Then, delete a randomly chosen piece of type X from the position, and calculate the eval again. Take the difference of the eval with and without the deleted piece, and average that. The result wll be the average piece value your eval assigns to a piece of type X.

[lkaufman]

Of course the stated value of a piece is not very important, as you can always adjust the piece location table to compensate for any error in the nominal value. The only real importance of getting the nominal value of the piece about right is if you do things like "lazy eval" or make any use of the actual material balance to make decisions. So in Rybka I tried to get them about right, but the benefit was perhaps under one Elo point. In Doch we made a special effort to get them about right at least in terms of the piece location tables and mobility being about neutral on average, so that the table values and/or mobility values can be increased or decreased by any desired percentage without much consequence to the average value of the piece in question. I think we got the pawn wrong though; our next version will correct this (mostly).

[lkaufman]

"In some sense, I get the feeling that its not really possible to get good single numbers that deal with all these situations reasonably:
1. piece for pawns
2. exchange for pawns
3. 2 pieces for rook + pawns
and still interact well with king safety/passed pawn weights."

In Rybka 3 I did not find this to be so to any meaningful degree. Rather, the problem was that the optimum value for minor pieces based on hyperspeed play was lower than I consider reasonable, for all of these situations. I just don't know if it's due to the speed of play or to differences between computers and human grandmasters. The only imbalance that seems to need special attention is queen vs. three minors.