Texel tuning for piece values

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
xr_a_y
Posts: 272
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Texel tuning for piece values

Post by xr_a_y » Sat Dec 08, 2018 9:08 pm

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
Posts: 3624
Joined: Fri Mar 10, 2006 4:23 am
Location: http://www.arasanchess.org

Re: Texel tuning for piece values

Post by jdart » Sun Dec 09, 2018 12:51 am

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

User avatar
hgm
Posts: 22666
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Texel tuning for piece values

Post by hgm » Sun Dec 09, 2018 6:48 am

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.

User avatar
xr_a_y
Posts: 272
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Texel tuning for piece values

Post by xr_a_y » Sun Dec 09, 2018 8:22 am

hgm wrote:
Sun Dec 09, 2018 6:48 am
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

User avatar
xr_a_y
Posts: 272
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Texel tuning for piece values

Post by xr_a_y » Sun Dec 09, 2018 8:26 am

xr_a_y wrote:
Sun Dec 09, 2018 8:22 am
hgm wrote:
Sun Dec 09, 2018 6:48 am
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 ...

User avatar
hgm
Posts: 22666
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Texel tuning for piece values

Post by hgm » Sun Dec 09, 2018 9:23 am

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.

User avatar
Evert
Posts: 2903
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: Texel tuning for piece values

Post by Evert » Sun Dec 09, 2018 9:52 am

xr_a_y wrote:
Sun Dec 09, 2018 8:22 am
hgm wrote:
Sun Dec 09, 2018 6:48 am
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.

User avatar
xr_a_y
Posts: 272
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Texel tuning for piece values

Post by xr_a_y » Sun Dec 09, 2018 10:50 am

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 ...
Attachments
pieces.png
pieces.png (60.5 KiB) Viewed 332 times
error.png
error.png (25.75 KiB) Viewed 332 times

Joost Buijs
Posts: 772
Joined: Thu Jul 16, 2009 8:47 am
Location: Almere, The Netherlands

Re: Texel tuning for piece values

Post by Joost Buijs » Sun Dec 09, 2018 10:51 am

xr_a_y wrote:
Sun Dec 09, 2018 8:26 am
xr_a_y wrote:
Sun Dec 09, 2018 8:22 am
hgm wrote:
Sun Dec 09, 2018 6:48 am
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.

User avatar
xr_a_y
Posts: 272
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Texel tuning for piece values

Post by xr_a_y » Sun Dec 09, 2018 11:23 am

Joost Buijs wrote:
Sun Dec 09, 2018 10:51 am
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 !

Post Reply