Troubles with Texel Tuning

[AndrewGrant]

I've been trying to apply Texel Tuning to my engine for the last few days now, with no success. I imagine I am making a silly mistake, but I cannot seem to find it.

I have tried tuning with set of 6M quiet/noisy positions, as well as with a set of ~1M quiet positions. I have tried always returning the score from white's perspective, and always returning it from the proper perspective. I queued up my latest run last night and let it run while I slept / went to work. Here are the 'tuned' values for my PSQT and mobility tables

Code: Select all

-144 -216 -217 -154 9 -33 -69 -75 -93 -1241 13 -5 -2 -103 -125 -136 -192 -127 -4
 -12 -5 -34 -41 -5 -75 -68 0 -126 -2 -170 607 -8 174 -117 -32 -59 -96 -179 -224
-118 -144 -127 -122 -146 -300 -178 -6 -163 -113 -76 -105 -174 -129 -156 -132 -99
 -44 -45 -206 -177 -69 1822 -8 -37 -160 -100 -155 -123 -104 -131 -153 -193 -166
-127 -173 -164 -53 50 -36 -1946 -558 -317 -221 -229 -256 -173 -211 -238 -167 -17
2 -205 -190 -194 -206 -9 -115 -207 -141 -34 -404 8 -6 4 2 -31 -10985 3239 -134 1
250 -25 595 -14 -10 -145 -3 -7 -82 -234 -281 -173 -256 -110 -291 -383 -58 -157 -
124 -61 -8 2 -124 -382 -11 -9 0 5 -24 11 37 19 -51 -7 -7 8 -24 -104 -55 -70 -101
 -117 -83 -205 -119 -299 -138 -443 -321 -727 -156 -531 -19 -9 0 5 0 0 0 -1 -152
-182 -225 -157 -160 -180 -152 -104 -162 -186 -157 -148 -168 -308 -196 -292 -232
-217 -275 -145 -383 -241 -409 -167 2 0 0 1 139 -14 -373 7 -93 50 5 -83 -59 0 -13
9 -222 -50 -11 -263 -171 -160 -169 -105 -298 20 -354 -256 -317 -264 -244 -505 -2
40 -369 -602 -1094 -131 0 -197 80 -325 -22 -405 -260 -306 -199 -376 -210 -173 -2
69 -359 -242 -246 -259 -229 -171 -211 -435 -293 -257 -265 -241 -343 37 -328 -472
 -108 -102 -428 -2 -290 -59 31 -171 -198 -110 -153 -21 -211 -9 -154 -210 -20 -14
1 -369 -353 -154 -210 -223 -258 -11 -557 -402 -608 -557 -427 -409 -1236 -404 -99
6 -302 -421 -174 -185 -428 -322 -215 -303 -205 -319 -301 -307 -319 -531 -204 -31
9 -236 -184 -252 -312 -285 -227 -310 -153 -238 -193 -195 -211 -183 319 -124 -95
-116 -78 -241 5 -86 -1 -87 -125 -186 15 81 -4 -198 -334 -155 1 -313 -11 -114 -16
 -167 -257 -492 -17 -329 -385 -22 -414 -550 -490 -251 -456 -146 -446 -386 -554 -
516 -516 -375 -382 -394 -600 -530 -482 -434 -432 -328 -442 -430 -530 -353 -514 -
423 -497 -385 -525 -387 -407 -475 -454 -402 -280 -339 -381 -471 -710 -587 -442 -
416 -376 -642 -548 -539 -474 -492 -465 -569 -527 -611 -390 -532 -534 -824 -720 -
553 -393 -405 -682 -291 -787 -600 -857 -596 -825 -1167 -1526 -775 -1188 -1013 -1
104 -1319 -1140 -959 -1038 -927 -753 -1113 -1078 -978 -1158 -648 -1193 -1040 -95
8 -667 -921 -896 -1263 -1352 -974 -1054 -788 -881 -927 -1191 -1007 -712 -747 -66
8 21 23 23 160 10 35 4 9 -178 11 17 -58 9 10 -4 -182 -1 -27 -72 -6 -10 -123 -61
-18 -8 -1437 -633 -40 -25 1 2 1466 10 -12 -2 38 -10 -27 -5 -6 -4 -56 -9 -5 46 -6
 21 -6 -96 -56 45 -34 -40 -123 -34 -21 88 163 243 -23 229 -199 88 20

I think almost every term is negative, and WAY to large. There is even an -10985 term in there for god knows what.

Here is a link to the source file: https://pastebin.com/K8aRaaeQ

Here is a few lines from my FEN file : https://pastebin.com/raw/Ttf6SvY5

I will also note, both my qsearch and eval routines are deterministic. I have all tables disabled when I compile to do texel tuning.

Any help or suggestions would be greatly appreciated.

Thanks,
Andrew

[AlvaroBegue]

I think almost every term is negative, and WAY to large. There is even an -10985 term in there for god knows what.

Well, perhaps you could start by figuring out what that term is for. Then figure out if the database you used for training contains examples where that feature is present and how many of them are wins, draws and losses for white.

[jdart]

If you are using just the eval not a search for each position, then you *must* use only quiet positions in the training set.

If the training set results are from the white POV (e.g. 1.0 for a White win) then you must use the eval from the White POV.

You have a horribly inefficient tuning method. Consider using a gradient-based method such as ADAM.

--Jon

[Evert]

You can read about my own experience with setting this up here: http://www.talkchess.com/forum/viewtopic.php?t=65039

I use the a multi-dimensional fitting routines from GSL, which work well for me. I have simple batch-gradient descent as an alternative, but I find it difficult to tweak the scale factor for each variable. My evaluation function uses floats (doubles, actually) during the fitting process. My goal function is 1/(1+exp(-E)), with E the evaluation for a given position in nominal pawn units (internally, this works out to VP=256 in the end game). In other words, I fixed K=1 and let other terms adjust as they will. Some things I have learned from this:

• Start simple, for instance with piece values. You don't need millions of positions here either. The goal is to verify that the method works. It should converge on ok-ish piece values starting from 0 in a few minutes. There is no point in running it overnight unless you know it works.
• Truly pathological values (EG value lower than MG value, Rook below Minor, penalty for Rook on open files, penalty for high mobility, penalty for pawn centre) indicate missing knowledge, or an incorrect implementation (for instance neglecting to flip the sign fo black).
• Use quiet positions, preferably those encountered during search. Determine the expected outcome of these positions (in other words, not the outcome of the game the position came from).
• I have yet to get anything sensible from piece square tables. They dob't appear to be that significant, apart for Knights and Kings.
• Beware of covariant variables. I've had (buggy) cases of two variables opposing eachother, which lead the tuner to let both of them grow large while keeping the difference constant. That never converges.

Hope this has something useful for you. I think I had some more to say, but I don't remember what.

[Evert]

Oh, here's one more thing: if you're tuning different types of mobility (say, safe versus unsafe) make sure you don't end up assigning pieces with a massive penalty for having no unsafe squares to go to. Plain mobility can be positive or negative, but if you count extra things on top, don't penalise for not having them.

[brtzsnr]

If all your values are erratic most likely is because you are using non-quiet positions to tune. You cannot give a high score to a queen that's captured by a pawn in 1 move. Start with quiet positions which I and a few others had good experience.

Moreover, unless you omit regularization, the average PSqT should be 0 otherwise you can just adjust the piece value to make the PSqT 0.

[AndrewGrant]

How have you adapted SGD for chess? How are you updating the gradients for each evaluation term?

[Ferdy]

I think almost every term is negative, and WAY to large. There is even an -10985 term in there for god knows what.

Here is a link to the source file: https://pastebin.com/K8aRaaeQ

Once the error is reduced, get out of the delta loop and try right away the next param. Something like below.

Code: Select all

// Increasing Parameter was a success
if &#40;this < best - DBL_EPSILON&#41;&#123;
	best = this;
	improved = 1;
	// continue;
	
	// Save the tried best parameter value
	
	break; // Break out of delta loop
&#125;

[AndrewGrant]

Are you using popcount(white pawns) - popcount (black pawns), and the multiplying that by the phase factor ?

Say term 0 is pawn midgame

Code: Select all

for each position
  Error = result - 1/(1+pow(10, -k*eval/400))
  Gradient [0] += error * pawn difference * phase / max phase?

[Evert]

How have you adapted SGD for chess? How are you updating the gradients for each evaluation term?

Numerically, because I'm too lazy to keep track of which evaluation terms are linear (at the moment, all of them, but I don't want to rule out that some of them won't be later on). I get better convergence from GSL's fitting functions.