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 ?
Texel tuning for piece values
Moderators: hgm, Rebel, chrisw
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
-
- Posts: 4367
- Joined: Fri Mar 10, 2006 5:23 am
- Location: http://www.arasanchess.org
Re: Texel tuning for piece values
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.most of them will show the exact same number of pieces on the two side
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
-
- Posts: 27811
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Texel tuning for piece values
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.
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.
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Texel tuning for piece values
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 };
What about this post ? http://talkchess.com/forum3/viewtopic.p ... es#p778420
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Texel tuning for piece values
ok maybe because the pst used are not centered on zero ...xr_a_y wrote: ↑Sun Dec 09, 2018 9:22 amok I get that but why Rofchade get pieces value like those then
Why not use 100 as MG pawn value ?Code: Select all
const eval pieceValue[2][6] = { 82, 337, 365, 477, 1025, 12000, 94, 281, 297, 512, 936, 12000 };
What about this post ? http://talkchess.com/forum3/viewtopic.p ... es#p778420
-
- Posts: 27811
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Texel tuning for piece values
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.
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Texel tuning for piece values
You have to fix something.xr_a_y wrote: ↑Sun Dec 09, 2018 9:22 amok I get that but why Rofchade get pieces value like those then
Why not use 100 as MG pawn value ?Code: Select all
const eval pieceValue[2][6] = { 82, 337, 365, 477, 1025, 12000, 94, 281, 297, 512, 936, 12000 };
What about this post ? http://talkchess.com/forum3/viewtopic.p ... es#p778420
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.
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Texel tuning for piece values
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 :
If we look at normalized gradient
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 ...
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
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
Maybe I shall try something else than gradient descent ...
-
- Posts: 1564
- Joined: Thu Jul 16, 2009 10:47 am
- Location: Almere, The Netherlands
Re: Texel tuning for piece values
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.xr_a_y wrote: ↑Sun Dec 09, 2018 9:26 amok maybe because the pst used are not centered on zero ...xr_a_y wrote: ↑Sun Dec 09, 2018 9:22 amok I get that but why Rofchade get pieces value like those then
Why not use 100 as MG pawn value ?Code: Select all
const eval pieceValue[2][6] = { 82, 337, 365, 477, 1025, 12000, 94, 281, 297, 512, 936, 12000 };
What about this post ? http://talkchess.com/forum3/viewtopic.p ... es#p778420
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 };
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.
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Texel tuning for piece values
Probably !Joost Buijs wrote: ↑Sun Dec 09, 2018 11: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.