How do you determine piece material value after optimizing the evaluation function?

[j.t.]

How do you determine piece material value after optimizing the evaluation function? For example, if I also optimize piece material values during evaluation optimization, the resulting piece material value of the knight is higher than the one of the bishop. But if one considers the whole evaluation, the bishop will be worth more on average, as the mobility is on average higher than for the knight.
A solution could be to make sure that all evaluation parameters are centered (e.g. mobility adds zero to a piece value on average).
However, I used a brute force approach: For every position from a large set of positions (e.g. the test set) I check for every piece on the board how much the evaluation would decrease if I removed it. If I take the average of this, I get more sensible values (knight is slightly worse than bishop).

Now I am wondering how other people solve this issue. I though also about determining the piece value in context of the current position, which should make the value I use for a piece more accurate (and thus make SEE and other methods that use piece values more effective). But it seems like the performance impact of something like this is too big and if this idea does indeed work, then it doesn't work well enough to compensate for the performance loss.

[Ferdy]

The ultimate test after optimization is through game test. Whether the value of a knight is higher than a bishop etc. does not matter anymore.

[j.t.]

The ultimate test after optimization is through game test. Whether the value of a knight is higher than a bishop etc. does not matter anymore.

In Nalwald I use piece material value at different places, for example in SEE calculation (which means that the amount of futility reductions, hash result futility pruning, delta pruning and fail-high delta pruning, and last but not least move ordering, depend on the material value of pieces). Additionally, there are parameters that should be normalized to centipawns (e.g. parameters for the mentioned search methods), which requires again a material value for a pawn that makes sense relative to the evaluation function.

[Ferdy]

You should use the same piece value in eval and other parts of the program.

[j.t.]

You should use the same piece value in eval and other parts of the program.

I don't think this works in all cases, as I explained in my beginning post. If you use piece square tables, part of the average value of a piece might be encoded there, so the piece material value you use in the eval doesn't give the whole picture.

[Ferdy]

You should use the same piece value in eval and other parts of the program.

I don't think this works in all cases, as I explained in my beginning post. If you use piece square tables, part of the average value of a piece might be encoded there, so the piece material value you use in the eval doesn't give the whole picture.

You can breakdown your piece square tables into piece and pst values.

[Joost Buijs]

What I did in the past with my HCE was adding an offset to the values in the PST to make the sum of these exactly zero, than you will get normal looking piece values with automated tuning (if everything is right of course). In fact you don't need piece-values at all if they are encoded in the PST, but sometimes it is handy to have piece-values for SEE or something like that.

[j.t.]

In fact, you don't need piece-values at all if they are encoded in the PST, but sometimes it is handy to have piece-values for SEE or something like that.

Yeah, I relied on this previously: I didn't tune the basic piece material values (100,300,300,500,900) and hoped that all extra information can be encoded in the PSTs, which is probably true. However, I believe by having tuning parameters for each piece value, the optimization will be more efficient.

[JVMerlino]

In fact, you don't need piece-values at all if they are encoded in the PST, but sometimes it is handy to have piece-values for SEE or something like that.

Yeah, I relied on this previously: I didn't tune the basic piece material values (100,300,300,500,900) and hoped that all extra information can be encoded in the PSTs, which is probably true. However, I believe by having tuning parameters for each piece value, the optimization will be more efficient.

I used a lazy method, as is my fashion, but it was pretty effective. My PSTs also include piece value. My SEE piece values are exactly the ones Joost lists above. However, instead of tuning hundreds of individual PST values, I simply tuned both an MG/EG "offset" for each piece type, to be added or subtracted to the PST value during evaluation.