Texel tuning for piece values

[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 !

[Ronald]

With gradient descent a lot of times you will only find a local minimum and not always the global minimum. The values you get may be a local minimum. You may help the tuning proces by starting with values you think should be the optimal values. If you start with the textbook material values and you still end up with the same values then you really have a bug.

[Ferdy]

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 ?

This depends on the training positions you use. There are training positions that have equal material but has differences in positions like one is better in passer but has bad mobility. This has no effect on material tuning.

Try something like the one used by a0. Initially set your default piece to non optimal, p=30, b=n=120,r=300,q=450. Texel is the same but its values are closer to optimal, than those values. Create matches between this version at fast tc using that default values. Save the position and result and use it to train the engine. Use the new values after training and create another matches from this current values and so on. Create matches, save pos, train, update values. Your training may involve only the eval or qsearch . But the matches of games has a search time this would make the result in those games more accurate and is the driving force towards optimal values.

[D Sceviour]

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

I have not changed my opinion that imbalance formula are a waste of time. On the contrary, I like how Schooner frequently undertrades for a won endgame. It makes for some dashing tactics. White to move from Schooner-Fritz:

[d]r3r1k1/1p1q3n/1pp2p2/1Pn1p2Q/P1P1P3/2BP2P1/5R1P/5R1K w - - 0 35
RxP! Do not forget that chess engines have to see exchanges such as this very deep on the horizon, so it is not that obvious a position to get into. The full game was posted on this page:

http://talkchess.com/forum3/viewtopic.p ... 20#p777990