Question for Bob Hyatt

[mjlef]

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.

[mjlef]

Larry,

Most programs now seem to change the value of the pawn based on game stage. Do you ratios hodl true throughout the game, or do peices get lower ratios as material is exchanged?

I guess I am saying two things need to be optimized: both opening and endgame values of pieces. Just tuning one will not get you the best scores.

Mark

[Sven]

Eelco you are misquoting.

Pawn=80 in Fruit 2.1 not 100.

[...]

3.25 / 0.8 = 4.0625 pawn.

[...]

Yes, sorry I realized my mistake before reading your above post and edited mine. I still don't think the Fruit 2.1 values are true averages though. [...]

Your quoting of "ValuePawn = 100" for Fruit 2.1 was not completely wrong at least. The ValueXXX constants given in value.h are not related to the evaluation function but are used within the search, e.g. for delta pruning and SEE. Since there the ratio of these static, phase-independent values is indeed 100 : 325 : 325 : 500 : 1000, the question is why these have not been adapted to the 80 : 325 ... resp. 90 : 325 ... ratio that is used in the evaluation function.

My only explanation would be that in fact the ratio of piece values in an "average" position (o.k., what is that?!) is closer to 100 : 325 ... than to 80 : 325 ... because of bonuses that are usually applied. If that is not the case then the static values used for search are somehow misaligned to the values used for evaluation, and I wonder why this is the case. If I write an SEE function in order to statically estimate the possible material loss of a capture move but use values that are far off w.r.t. my real evaluation function which defines my "reality" then my estimate of the reality may be far off, too. So there might be a good reason for doing so.

Has someone any explanation for that difference in Fruit 2.1?

Sven

[Eelco de Groot]

Eelco you are misquoting.

Pawn=80 in Fruit 2.1 not 100.

[...]

3.25 / 0.8 = 4.0625 pawn.

[...]

Yes, sorry I realized my mistake before reading your above post and edited mine. I still don't think the Fruit 2.1 values are true averages though. [...]

Your quoting of "ValuePawn = 100" for Fruit 2.1 was not completely wrong at least. The ValueXXX constants given in value.h are not related to the evaluation function but are used within the search, e.g. for delta pruning and SEE. Since there the ratio of these static, phase-independent values is indeed 100 : 325 : 325 : 500 : 1000, the question is why these have not been adapted to the 80 : 325 ... resp. 90 : 325 ... ratio that is used in the evaluation function.

My only explanation would be that in fact the ratio of piece values in an "average" position (o.k., what is that?!) is closer to 100 : 325 ... than to 80 : 325 ... because of bonuses that are usually applied. If that is not the case then the static values used for search are somehow misaligned to the values used for evaluation, and I wonder why this is the case. If I write an SEE function in order to statically estimate the possible material loss of a capture move but use values that are far off w.r.t. my real evaluation function which defines my "reality" then my estimate of the reality may be far off, too. So there might be a good reason for doing so.

Has someone any explanation for that difference in Fruit 2.1?

Sven

Hello Sven,

Agree with your explanation, it is the most simple one by Occam. These values are closer to the "par" values as I believe Larry calls them, close to his Rybka 3 values if a pawn = 1, also if you can't use any additional evaluation you probably have to err on the safe side a bit, it depends on the situation which side is the safe side

The fact that the "average" or par values do seem to arrive at close to multiples of a pawn or, in case of minor pieces, multiple quarter pawns is probably not wholly coincidental, partially without exchanges the game is not very playable so that forces possible exchange rates a bit, and in turn the reason the rules of chess as we know them do seem to make for an attractive game is in fact dependant on there being exchange rates that allow almost posionally neutral material exchanges that still totally change the situation on the board. Without variations leading to material imbalances which are nevertheless still playable for both sides, chess would not be a very popular game!

Regards,
Eelco

[lkaufman]

I'm not familiar with your "bad trade" code, could you explain a bit? What is the purpose of doing it this way rather than just raising the minor piece values? Is it your opinion that each specific imbalance deserves its own evaluation, that no set of purely material values gets this right? In Rybka 3 we do have some code that modifies the values based on specific imbalances, but in general the values are tiny and the benefit almost too small to measure. Can you say that in Crafty using this "bad trade" code (rather than just modifying the piece values) has added a measurable number of Elo points?

[hgm]

I never understood what exacty the Crafty bad-trade code is doing, but I can imagine that it has to do wth the following fundamental problem:

Traditional Chess engines are quite poor at risk mangement. If they have to choose between a quiet position where they are a Pawn ahead, or a very wild one, where they are also a Pawn ahead, they often have no preference for one or the other. While the winning probability in practice is not only determined by your advantage, but also by the uncertainty in this advantage. E.g. at the point where the uncertainty becomes much larger than the magnitude of the advantage, you will still hardly do better than 50%.

Having imbalanced material is definitely a factor that drives up the uncertainty. A Knight versus three Pawns can go one way or the other way, but it hardly ever will end in a bloodless draw. So if you have N+4P vs. N+3P, you would probably have better chances than either with 4P vs N or with N+P vs 3P. (Assuming, for the sake of argument, that N=3P, which in 8x8 Chess of course we all know it isn't.)

This could of course be incorperated in material tables, but additive piece values will never be able to handle it purely through the evaluation. I imagine this is what the bad-trade code of Crafty tries to solve.

[Uri Blass]

I never understood what exacty the Crafty bad-trade code is doing, but I can imagine that it has to do wth the following fundamental problem:

Traditional Chess engines are quite poor at risk mangement. If they have to choose between a quiet position where they are a Pawn ahead, or a very wild one, where they are also a Pawn ahead, they often have no preference for one or the other. While the winning probability in practice is not only determined by your advantage, but also by the uncertainty in this advantage. E.g. at the point where the uncertainty becomes much larger than the magnitude of the advantage, you will still hardly do better than 50%.

Having imbalanced material is definitely a factor that drives up the uncertainty. A Knight versus three Pawns can go one way or the other way, but it hardly ever will end in a bloodless draw. So if you have N+4P vs. N+3P, you would probably have better chances than either with 4P vs N or with N+P vs 3P. (Assuming, for the sake of argument, that N=3P, which in 8x8 Chess of course we all know it isn't.)

This could of course be incorperated in material tables, but additive piece values will never be able to handle it purely through the evaluation. I imagine this is what the bad-trade code of Crafty tries to solve.

No

I think that bad trade code simply increase the value of minor pieces
and I do not think that it is a good idea.

I think that it is better to increase the value of minor pieces directly and not to have a bad trade code.

The idea is that
N vs PPP or BN vs RP or NN vs RP or BB vs RP is good for the side with the B or N.

The only reason that I read against simply increasing the value of the knight and the bishop is the opinion that
NP vs R or BP vs R is not good for the side with the knight or the bishop relative to the increased values and I do not think that this opinion is correct.

Uri

[lkaufman]

Even if you are concerned about reducing the value of the (rook vs. minor) Exchange, simply by increasing the value of the rook by the same amount as the increase in the minor (while increasing the queen by double this amount) will automatically retain the same value for the Exchange while increasing the value of two minors vs. rook and minor vs. pawns. It will also leave the queen vs. any two pieces unchanged, while it will decrease queen vs. three minors, which is surely good as all chess programs without special code overvalue the queen in this case. So based on your description I cannot guess the reason for this "bad trade" code.

[bob]

I never understood what exacty the Crafty bad-trade code is doing, but I can imagine that it has to do wth the following fundamental problem:

Traditional Chess engines are quite poor at risk mangement. If they have to choose between a quiet position where they are a Pawn ahead, or a very wild one, where they are also a Pawn ahead, they often have no preference for one or the other. While the winning probability in practice is not only determined by your advantage, but also by the uncertainty in this advantage. E.g. at the point where the uncertainty becomes much larger than the magnitude of the advantage, you will still hardly do better than 50%.

Having imbalanced material is definitely a factor that drives up the uncertainty. A Knight versus three Pawns can go one way or the other way, but it hardly ever will end in a bloodless draw. So if you have N+4P vs. N+3P, you would probably have better chances than either with 4P vs N or with N+P vs 3P. (Assuming, for the sake of argument, that N=3P, which in 8x8 Chess of course we all know it isn't.)

This could of course be incorperated in material tables, but additive piece values will never be able to handle it purely through the evaluation. I imagine this is what the bad-trade code of Crafty tries to solve.

The "bad trade" code is simply based on the observation that 99% of the time, trading a knight for 2 or 3 pawns, or a pair of minors for a rook + pawn, are bad ideas. Most commonly, the extra piece the opponent has is used to pick off pawns one by one until we simply end up a piece down and dead lost. Many try to eliminate this by simply finagling material values. Which is effectively the same thing that I do. But I can now adjust the material score in any way I want, without breaking the scores with regard to material imbalances.

I find this easier to tune than creating a material imbalance table, and then having to retune when other scoring terms change. For example, increasing any passed pawn scoring tends to create more minor for 2-3 pawn cases, because the 2-3 pawns _plus_ the additional passed pawn scoring which might apply to one or more of those pawns can cause the problem to occur with more frequency. With the bad trade code, I just have one score to change.

[bob]

I never understood what exacty the Crafty bad-trade code is doing, but I can imagine that it has to do wth the following fundamental problem:

Traditional Chess engines are quite poor at risk mangement. If they have to choose between a quiet position where they are a Pawn ahead, or a very wild one, where they are also a Pawn ahead, they often have no preference for one or the other. While the winning probability in practice is not only determined by your advantage, but also by the uncertainty in this advantage. E.g. at the point where the uncertainty becomes much larger than the magnitude of the advantage, you will still hardly do better than 50%.

Having imbalanced material is definitely a factor that drives up the uncertainty. A Knight versus three Pawns can go one way or the other way, but it hardly ever will end in a bloodless draw. So if you have N+4P vs. N+3P, you would probably have better chances than either with 4P vs N or with N+P vs 3P. (Assuming, for the sake of argument, that N=3P, which in 8x8 Chess of course we all know it isn't.)

This could of course be incorperated in material tables, but additive piece values will never be able to handle it purely through the evaluation. I imagine this is what the bad-trade code of Crafty tries to solve.

No

I think that bad trade code simply increase the value of minor pieces
and I do not think that it is a good idea.

I think that it is better to increase the value of minor pieces directly and not to have a bad trade code.

You can think what you want, but the above is dead wrong. How can it matter if you adjust the value of the pieces directly, or you add in a penalty when you see a particular case arise. Scores will be identical. I like the bad trade score because it lets me adjust this penalty in exactly one place, rather than being spread all over the material scores. And when I choose to change the value of one or more pieces, as when we tuned them, you then have to factor in the "bad trade" idea directly if you don't have it as a separate scoring term.

Functionally, they are perfectly equivalent. The only difference is which do you find easier to fine-tune. I like our way, but _only_ for that reason. And note that in Crafty, the older version of "bad trade" is no longer done, we have an array lookup which produces _exactly_ the same scores, but a bit faster. But we fill in this array the same way we used to compute the bad trade scores.

The idea is that
N vs PPP or BN vs RP or NN vs RP or BB vs RP is good for the side with the B or N.

The only reason that I read against simply increasing the value of the knight and the bishop is the opinion that
NP vs R or BP vs R is not good for the side with the knight or the bishop relative to the increased values and I do not think that this opinion is correct.

Uri