Tuning piece values with CLOP

[jarkkop]

Could you add in CLOP a log file that logs all parameter combinations that trigger in the max tab the max column show a value set. These are the possible good values to try? This column update can happen when Eigenvectors all reach negative values. Is this a local minimum if CLOP oscillates away from this negative Eigenvectors set?
I might have misunderstood everything so correct me if necessary.

[bob]

* pawn = 80 (opening) 100 (endgame = pivot point)

Jazz very clearly overvalues the pawns early on (perhaps later too, haven't really checked that), but fixing that is not as easy as defining an early game and an endgame value for it (but I could of course add the code for doing so quite easily).

Regardless, I'll be revisiting the value of the pawn later.

* knight = bishop = variable1
* bishop pair hardcoded so something like 50
* rook = variable1+variable2 (so variable2 represent the exchange value and is > 0, it avoids stupid sampling of rook < knight values)
* queen = rook+variable3 = var1+var2+var3 (same reason)

I was now tuning in four dimensions, with any material imbalance tweaks (apart from bishop pair) set to 0. This seems to work ok (but I disabled razoring and forward pruning, which have margins that make implicit assumptions about the piece values and my gut tells me would interfere with tuning them).

I did specify margins that are "sensible": knight ~ bishop, knight ~ 300cp +/- delta, rook ~ knight + 200cp, queen ~ 3 knights ~ 2 rooks.

Then you can fix these values and optimize the bishop pair, and the difference bishop-knight=epsilon (probably small and hard to measure).

Actually, one of the things that came out of all the tuning runs I've done (so it seems to be very robust) is that the knight needs to be devalued by 25cp relative to the bishop. I haven't really looked into this much yet or verified this, but it probably comes from two things: an untuned (fixed) bishop-pair bonus, and unbalanced piece-square tables (so the average contribution from them is non-zero). Fixing the piece square tables to correct that is not entirely trivial (in Jazz) because the piece square tables are not static, unless I just add a constant to them. Which seems a bit silly since the constant could (should?) just be absorbed in the piece value anyway.

Your knight = bishop - 25cp is really a wrong concept. That's an evaluation issue. A bishop with no mobility is worth much less than a knight on a good square. Trying to make the piece values deal with such an issue really just gives you an "average piece value" that is only correct in a very few positions, which is not what I want to do...

[diep]

* pawn = 80 (opening) 100 (endgame = pivot point)

Jazz very clearly overvalues the pawns early on (perhaps later too, haven't really checked that), but fixing that is not as easy as defining an early game and an endgame value for it (but I could of course add the code for doing so quite easily).

Regardless, I'll be revisiting the value of the pawn later.

* knight = bishop = variable1
* bishop pair hardcoded so something like 50
* rook = variable1+variable2 (so variable2 represent the exchange value and is > 0, it avoids stupid sampling of rook < knight values)
* queen = rook+variable3 = var1+var2+var3 (same reason)

I was now tuning in four dimensions, with any material imbalance tweaks (apart from bishop pair) set to 0. This seems to work ok (but I disabled razoring and forward pruning, which have margins that make implicit assumptions about the piece values and my gut tells me would interfere with tuning them).

I did specify margins that are "sensible": knight ~ bishop, knight ~ 300cp +/- delta, rook ~ knight + 200cp, queen ~ 3 knights ~ 2 rooks.

Then you can fix these values and optimize the bishop pair, and the difference bishop-knight=epsilon (probably small and hard to measure).

Actually, one of the things that came out of all the tuning runs I've done (so it seems to be very robust) is that the knight needs to be devalued by 25cp relative to the bishop. I haven't really looked into this much yet or verified this, but it probably comes from two things: an untuned (fixed) bishop-pair bonus, and unbalanced piece-square tables (so the average contribution from them is non-zero). Fixing the piece square tables to correct that is not entirely trivial (in Jazz) because the piece square tables are not static, unless I just add a constant to them. Which seems a bit silly since the constant could (should?) just be absorbed in the piece value anyway.

Your knight = bishop - 25cp is really a wrong concept. That's an evaluation issue. A bishop with no mobility is worth much less than a knight on a good square. Trying to make the piece values deal with such an issue really just gives you an "average piece value" that is only correct in a very few positions, which is not what I want to do...

25 cp makes sense to me if there isn't a bishop pair bonus...

Look this is all grammar school tuningsalgorithms Bob, used with a handful of parameters - and it's not even managing to tune that real accurate.

[Evert]

Your knight = bishop - 25cp is really a wrong concept. That's an evaluation issue. A bishop with no mobility is worth much less than a knight on a good square. Trying to make the piece values deal with such an issue really just gives you an "average piece value" that is only correct in a very few positions, which is not what I want to do...

I think you misunderstood what I said.
I'm not saying the knight should be 25cp lower than a bishop, I'm saying that once all evaluation terms are factored in, the average value of the knight seems to be (currently) overevaluated relative to the bishop by ~25 cp (that is, if you expect the base value to be the same for both). This has nothing to do with trying to tune piece values to reflect mobility, but rather is a reflection of the different evaluation terms not being properly balanced. This has the effect of adding (on average) a spurious 25cp to the evaluation of the knight. Constant terms in the piece evaluation can of course be absorbed in the piece value (or the other way around, piece values could be put in the piece square tables).

At least that's my interpretation of the result. An alternative interpretation is that the bishop is undervalued (due to penalties) and this is reflected in the tuning by dropping the value of the knight to the same (effective) level. Sounds less plausible to me though.

Note that if I run a verification match, even after CLOP has (or claims to have) converged, I cannot confirm that the tuned piece values are any better... which I plan to look into, but it'll have to wait until I get back from a work trip.

[Evert]

25 cp makes sense to me if there isn't a bishop pair bonus...

Of course there is a pair bonus (as I mentioned earlier).

All I would claim from a 25cp offset between the base value of a knight and the base value of a bishop is that the other evaluation terms for at least one of them are poorly balanced and badly tuned. Which is actually why I wanted to tune things in the first place (starting with the static piece values, which may or may not have been the best starting point in the end).

[Adam Hair]

25 cp makes sense to me if there isn't a bishop pair bonus...

Of course there is a pair bonus (as I mentioned earlier).

All I would claim from a 25cp offset between the base value of a knight and the base value of a bishop is that the other evaluation terms for at least one of them are poorly balanced and badly tuned. Which is actually why I wanted to tune things in the first place (starting with the static piece values, which may or may not have been the best starting point in the end).

I can relay what I have noticed for two different engines. One of them, Cupcake (Dan Honeycutt), has a simple evaluation function (PSTs; bishop pair; rook-file bonuses; mobility; king safety; doubled, passed, and isolated pawn parameters; game phase consideration). The other, Gaviota (Miguel Ballicora), has a evaluation function with many more parameters that have been well-tuned by Miguel. There is approximately a 1/8 pawn difference between the knight value and the bishop value (bishop = knight + ~12cP) for Gaviota. In the process of tuning Cupcake, I have found a similar sized difference between the knight and bishop values (maybe a little larger; I do not have the values in front of me at the moment). So, unless there is some eval parameter that is mistuned or missing from Jazz, Cupcake, and Gaviota, then it may be that there should be a small difference in the value of the knight and the bishop. Of course, the 25 cP difference for Jazz may be a little high.

By the way, Komodo has its bishops valued slightly higher than its knights (12.5 cP).