Texel tuning for piece values

[xr_a_y]

I understand how texel tuning works for PST, or for other evaluation parameters. But I don't understand how someone can tune piece values this way. Usually in the sample positions (some millions) the numbers of queens will mostly always be the same (1 per color), and the number of pawns will also mostly be the same (+/-1). Only the number of knight/bishop/rook will differ sometimes thanks to some exchange that have been done. But in the millions of positions used, most of them will show the exact same number of pieces on the two side. This way there is no chance to tune piece values I think, the convergence rate would be infinitly small and mini batch gradient or stochastic gradient "sampling" will most alway slead to near 0 gradient for queens, or pawn value.

How some engines were successfull to do so ?

[jdart]

most of them will show the exact same number of pieces on the two side

This actually isn't true. There are lots of games with material imbalances. This is especially so in lower-level games where players tend to drop pieces.

However, I don't actually tune piece values with the Texel method. I keep them fixed but there are tunable correction factors for imbalanced material configurations.

--Jon

[hgm]

There also is little need to do it, because Larry Kaufman already did it for us, and shared the results.

It is true that you cannot derive imbalance values for, say, 3 Queens vs 7 Knights this way. But if you are interested in those you can simply generate your own set of positions with imbalances of that type through computer self-play from start positions with a similar imbalance. In the worst case the self-play sucked because the it used completely different values from those that came out of the tuning procedure. But then you simply repeat the procedure through self-play with the better tuned values, etc.

[xr_a_y]

There also is little need to do it, because Larry Kaufman already did it for us, and shared the results.

ok I get that but why Rofchade get pieces value like those then

Code: Select all

const eval pieceValue[2][6] =
{ 82, 337, 365, 477, 1025, 12000,
  94, 281, 297, 512,  936, 12000 };

Why not use 100 as MG pawn value ?

What about this post ? http://talkchess.com/forum3/viewtopic.p ... es#p778420

[xr_a_y]

There also is little need to do it, because Larry Kaufman already did it for us, and shared the results.

ok I get that but why Rofchade get pieces value like those then

Code: Select all

const eval pieceValue[2][6] =
{ 82, 337, 365, 477, 1025, 12000,
  94, 281, 297, 512,  936, 12000 };

Why not use 100 as MG pawn value ?

What about this post ? http://talkchess.com/forum3/viewtopic.p ... es#p778420

ok maybe because the pst used are not centered on zero ...

[hgm]

You cannot interpret these piece value outside the context of other evaluation terms. Especially '1 Pawn' is an ill-defined concept. There are many kinds of Pawns, varying in value from 50cP to 250cP, depending on whether it is a blocked, isolated, doubled edge Pawn or a 7th-rank passer. The common lore that R=5 and Q=9 probably was derived from end-games with few Pawns, where most Pawns that compensate the piece imbalance are passers, not scattered too much. In the world of Pawn evaluations that would count like one of the better Pawns.

[Evert]

There also is little need to do it, because Larry Kaufman already did it for us, and shared the results.

ok I get that but why Rofchade get pieces value like those then

Code: Select all

const eval pieceValue[2][6] =
{ 82, 337, 365, 477, 1025, 12000,
  94, 281, 297, 512,  936, 12000 };

Why not use 100 as MG pawn value ?

What about this post ? http://talkchess.com/forum3/viewtopic.p ... es#p778420

You have to fix something.
You can fix the MG pawn value at 100, if you like. Personally, I fix the scale factor between evaluation score and expected outcome (I think it’s called “k” in most posts that describe the method) at 1.0.
It is true that the positions you sample must have the material imbalance terms you want to tune, but that is actually true of all terms you want to tune. You cannot tune passed pawn terms on positions that don’t have passed pawns, for instance.

[xr_a_y]

Yes i am working at fixed "k", using the optimal one based on initial guess parameters.

I meant, doesn't at least one piece value shall be fixed also ?. That's why I was saying pawnMG=100 ; of course malus / bonus will be apply to that initial value for passed pawn for instance.

Using a mini batch gradient (with momentum, alpha=0.9, normalized gradient and learning rate of 20, with batch size of 1024 ; the full data size is 1300000 positions : the famous Ethereal.fens), the optimal "k" and starting from piece values all equal to 450, I see error decrease but piece values going quite weird. After 1200 iterations I get this :

Code: Select all

# Info  2018-12-09 11:45:59-389: pawn 398
# Info  2018-12-09 11:45:59-389: knight 452
# Info  2018-12-09 11:45:59-389: bishop 432
# Info  2018-12-09 11:45:59-389: rook 437
# Info  2018-12-09 11:45:59-389: queen 454
# Info  2018-12-09 11:45:59-389: EGpawn 534
# Info  2018-12-09 11:45:59-389: EGknight 336
# Info  2018-12-09 11:45:59-389: EGbishop 267
# Info  2018-12-09 11:45:59-389: EGrook 639
# Info  2018-12-09 11:45:59-389: EGqueen 457

If we look at normalized gradient

Code: Select all

# Info  2018-12-09 11:45:59-395: Gradient normalized 0 0.215893
# Info  2018-12-09 11:45:59-395: Gradient normalized 1 -0.00149211
# Info  2018-12-09 11:45:59-395: Gradient normalized 2 0.28178
# Info  2018-12-09 11:45:59-395: Gradient normalized 3 0.245355
# Info  2018-12-09 11:45:59-395: Gradient normalized 4 -0.00279828
# Info  2018-12-09 11:45:59-395: Gradient normalized 5 -0.293916
# Info  2018-12-09 11:45:59-395: Gradient normalized 6 0.454084
# Info  2018-12-09 11:45:59-395: Gradient normalized 7 -0.69382
# Info  2018-12-09 11:45:59-395: Gradient normalized 8 0.199534
# Info  2018-12-09 11:45:59-395: Gradient normalized 9 0.00147859

we see that only some parameters have a chance to evolv. For example queen value and queen EG value get very very small gradient.

Maybe I shall try something else than gradient descent ...

[Joost Buijs]

There also is little need to do it, because Larry Kaufman already did it for us, and shared the results.

ok I get that but why Rofchade get pieces value like those then

Code: Select all

const eval pieceValue[2][6] =
{ 82, 337, 365, 477, 1025, 12000,
  94, 281, 297, 512,  936, 12000 };

Why not use 100 as MG pawn value ?

What about this post ? http://talkchess.com/forum3/viewtopic.p ... es#p778420

ok maybe because the pst used are not centered on zero ...

The values Larry Kaufmann gives are just a guideline that most engines were using in the past, all values are relative to each other, so it really doesn't matter what value you assign to a pawn to begin with.

In the past I used hand tuned values, and I started by using values like { 100, 325, 325, 500, 900 }, these are really the old school values, after tuning them with Texel style tuning, they look now like this:

Code: Select all

{ 85, 353, 352, 477, 913 },
{115, 285, 316, 556, 1185 };

Of course these values also depends upon the values of the PST and the values you assign to the positional evaluation, my PST's are scaled in such a way that the sum of all squares for one piece == 0. Personally I think that the whole concept of PST's is flawed, it is just a remnant of the past where we used to have lazy evaluation with material and just a few positional terms to gain a few percent in speed.

BTW. my k-factor currently is: 1.68, but that also doesn't matter much of course.

My material evaluation is still in centipawns, but for the positional evaluation I use millipawns because the resolution seemed a bit too low.

Over here gradient descent works fine, I don't see any problem with it, so if it goes weird in your case there must be a bug of some kind.

[xr_a_y]

Over here gradient descent works fine, I don't see any problem with it, so if it goes weird in your case there must be a bug of some kind.

Probably !