Texel tuning variant

Discussion of chess software programming and technical issues.

Moderators: hgm, Dann Corbit, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
Ferdy
Posts: 4527
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Texel tuning variant

Post by Ferdy » Thu Jan 21, 2021 2:15 am

After reducing the error by changing one parameter by +/- step, update the param value but don't use it when optimizing the next param value.

For example you have initially a param1=10, param2=20, and initial error, increment param1 by 1 if error is reduced set param1 to 11. Now increment param2 by 1 (but set param1 to its original value or 10) if error is reduced compared to initial error set param2 to 21. Then finally calculate the error using the updated param1=11, param2=21. The tuning process looks stable, as the param being tuned first does not affect the subsequent param to be tuned next.

In my test using gradient or difference quotients, with score from evaluation function, it looks promising. Training positions around only 28k are from self-play games. Positions are saved for training if the game move is not a capture not a promote move not a checking move and the side to move is not in check and abs(score) <= 1000cp.

Texel tuning ref is here.

TC=10+0.1

Code: Select all

Score of new vs old: 445 - 429 - 1126  [0.504] 2000
...      new playing White: 269 - 181 - 550  [0.544] 1000
...      new playing Black: 176 - 248 - 576  [0.464] 1000
...      White vs Black: 517 - 357 - 1126  [0.540] 2000
Elo difference: 2.8 +/- 10.1, LOS: 70.6 %, DrawRatio: 56.3 %
Parameters being optimized:
pp=passed pawn, mobB=bishop mobility

Code: Select all

+---------+-------+-------+
| name    |   old |   new |
+=========+=======+=======+
| ppR2En  |     3 |     3 |
+---------+-------+-------+
| ppR3En  |     5 |    46 |
+---------+-------+-------+
| ppR4En  |    15 |    28 |
+---------+-------+-------+
| ppR5En  |    29 |    48 |
+---------+-------+-------+
| ppR6En  |    66 |    66 |
+---------+-------+-------+
| ppR7En  |   100 |   100 |
+---------+-------+-------+
| mobB0Op |   -22 |   -22 |
+---------+-------+-------+
| mobB1Op |   -16 |   -16 |
+---------+-------+-------+
| mobB2Op |    -8 |     0 |
+---------+-------+-------+
| mobB3Op |     0 |    -2 |
+---------+-------+-------+
Tuning was finished after 39 iterations.

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

Re: Texel tuning variant

Post by hgm » Thu Jan 21, 2021 7:03 pm

Modifying only one parameter at the time is a very poor method of optimization for most evaluations, even for something as simple as the piece values. You will very quickly reach a situation where a change of any of the values will deteriorate things, even though changing many of them in the right ration would give an improvement. This is the 'river-valley problem', where your fitness landscape is a narrow gully not parallel to any of the coordinate axes.

fabianVDW
Posts: 146
Joined: Fri Mar 15, 2019 7:46 pm
Location: Germany
Full name: Fabian von der Warth

Re: Texel tuning variant

Post by fabianVDW » Fri Jan 22, 2021 9:38 am

What is the point in optimizing without using any gradient information, even when freely available? I don't get it.
Author of FabChess: https://github.com/fabianvdW/FabChess
A UCI compliant chess engine written in Rust.
FabChessWiki: https://github.com/fabianvdW/FabChess/wiki
fabianvonderwarth@gmail.com

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

Re: Texel tuning variant

Post by hgm » Fri Jan 22, 2021 12:06 pm

Laziness, mostly. Optimizing by randomly trying is trivial. And in the second place generality; it also works when gradient information is not 'freely available'. You don't need any assumption on the evaluation at all.

Post Reply