Crazy king psqt values from automated tuning

[adityachandra]

Hi all, I have been doing texel tuning on my evaluation as I added more features, all has been going well, except some issues on edge cases. Take a look at this king piece square table:

Code: Select all

    465, -210, 420, -235, -575, 580, 375, 270, 
    395, 565, 400, 115, 290, 485, 315, 240, 
    230, 65, -225, 65, -360, -270, 40, 245, 
    -465, -450, -415, -435, -460, -475, -245, -415, 
    -480, -240, -480, -455, -460, -500, -495, -285, 
    -250, -30, -295, -245, -225, -145, -80, -105, 
    55, -40, -110, -155, -130, -80, 20, 20, 
    -105, 35, -10, -125, -25, -65, 55, 40

Ranges for the two back ranks are pretty sane compared to the final rank where a 465 is next to a -210???
I think this is because there are not many positions where king is on these squares in middle game, but there's a large amount of data for king on 7th and 8th rank, hence squares there have balanced values. However I am using ~1.4million positions to train, which seems enough, especially for 400 parameters.
So I think more data isn't the solution...
Then I have a question, how do I ensure in texel's tuning that parameters don't take such weird values, as with the middle game king in the forward ranks???

[dangi12012]

Do the count of positions where king is on the square and post all 64 values here.

[Ras]

Then I have a question, how do I ensure in texel's tuning that parameters don't take such weird values, as with the middle game king in the forward ranks???

Try some regularisation. E.g. when evaluating the parameter error, add some term like 0.01*abs(value) for PSTs.

[adityachandra]

Do the count of positions where king is on the square and post all 64 values here.

For white king:

Code: Select all

730 1309 1481 1499 1683 1641 1525 940 
1793 3014 3544 3617 3871 4355 3746 2264 
2665 4948 5755 6277 6900 7439 7136 4189 
3463 5810 7832 9027 9938 11151 9961 6724 
3401 6527 9452 12311 15247 16432 14372 9357 
4092 7690 11882 18509 23669 28727 25970 17186 
4183 8602 13985 21230 34273 37551 58201 41317 
3161 13645 20467 15798 232824 32825 479791 39096 

For black king:

Code: Select all

2490 10426 16766 17673 262131 33856 447004 38557 
4029 8289 15306 22246 36172 38928 58341 41024 
4205 8007 12359 18231 23363 29567 26495 17254 
3578 6534 9562 12455 15382 16651 14322 9248 
3486 6028 7713 9160 9657 10964 9756 6770 
2830 5000 5826 6176 6560 7250 6992 3972 
2031 3055 3570 3498 3801 4315 3451 2066 
1248 1836 1888 1977 2034 1986 1722 931 

Now that I see, there are still hundreds of data points where the white king is say, on the top right corner of the board. Maybe these positions occur late in the game so the middle game piece square tables don't get a huge say on them.

[adityachandra]

Then I have a question, how do I ensure in texel's tuning that parameters don't take such weird values, as with the middle game king in the forward ranks???

Try some regularisation. E.g. when evaluating the parameter error, add some term like 0.01*abs(value) for PSTs.

I have looked a bit into regularisation now that you say it, I'll try it out, perhaps having some sort of general way to do it for all parameters not just PSTs...

[Joost Buijs]

Hi all, I have been doing texel tuning on my evaluation as I added more features, all has been going well, except some issues on edge cases. Take a look at this king piece square table:

Code: Select all

    465, -210, 420, -235, -575, 580, 375, 270, 
    395, 565, 400, 115, 290, 485, 315, 240, 
    230, 65, -225, 65, -360, -270, 40, 245, 
    -465, -450, -415, -435, -460, -475, -245, -415, 
    -480, -240, -480, -455, -460, -500, -495, -285, 
    -250, -30, -295, -245, -225, -145, -80, -105, 
    55, -40, -110, -155, -130, -80, 20, 20, 
    -105, 35, -10, -125, -25, -65, 55, 40

Ranges for the two back ranks are pretty sane compared to the final rank where a 465 is next to a -210???
I think this is because there are not many positions where king is on these squares in middle game, but there's a large amount of data for king on 7th and 8th rank, hence squares there have balanced values. However I am using ~1.4million positions to train, which seems enough, especially for 400 parameters.
So I think more data isn't the solution...
Then I have a question, how do I ensure in texel's tuning that parameters don't take such weird values, as with the middle game king in the forward ranks???

When you get weird values there is not much you can do to restrict them. Either your training positions are missing relevant information, or there is something wrong with the algorithm you use to optimize the PSQT's.

It's been a long time since I last used logistic regression with gradient descent to optimize my HCE, the values I found for the king PSQT are:

Code: Select all

int psqKingMG[64] =
{
61,   89,   61,   24,   24,   61,   89,   61,
64,   77,   42,   15,   15,   42,   77,   64,
23,   54,   10,  -15,  -15,   10,   54,   23,
7,   20,   -6,  -26,  -26,   -6,   20,    7,
2,   15,  -22,  -40,  -40,  -22,   15,    2,
-13,   -2,  -34,  -59,  -59,  -34,   -2,  -13,
-31,  -15,  -42,  -58,  -58,  -42,  -15,  -31,
-45,  -30,  -52,  -75,  -75,  -52,  -30,  -45,
};

int psqKingEG[64] =
{
-58,  -36,  -16,  -20,  -20,  -16,  -36,  -58,
-32,   -8,    8,    9,    9,    8,   -8,  -32,
-14,    7,   26,   29,   29,   26,    7,  -14,
-7,   20,   28,   28,   28,   28,   20,   -7,
-10,   25,   41,   41,   41,   41,   25,  -10,
-12,   28,   34,   37,   37,   34,   28,  -12,
-35,    2,    0,    7,    7,    0,    2,  -35,
-53,  -29,  -22,  -19,  -19,  -22,  -29,  -53,
};

I trained these PSQT's horizontally mirrored, e.g. A1..D1 is the same as H1..E1, without mirroring these values would be different. It all depends very much upon the dataset you use for training, if there is too little information about these king-positions in your dataset you will get weird values.

[adityachandra]

Hi all, I have been doing texel tuning on my evaluation as I added more features, all has been going well, except some issues on edge cases. Take a look at this king piece square table:

Code: Select all

    465, -210, 420, -235, -575, 580, 375, 270, 
    395, 565, 400, 115, 290, 485, 315, 240, 
    230, 65, -225, 65, -360, -270, 40, 245, 
    -465, -450, -415, -435, -460, -475, -245, -415, 
    -480, -240, -480, -455, -460, -500, -495, -285, 
    -250, -30, -295, -245, -225, -145, -80, -105, 
    55, -40, -110, -155, -130, -80, 20, 20, 
    -105, 35, -10, -125, -25, -65, 55, 40

Ranges for the two back ranks are pretty sane compared to the final rank where a 465 is next to a -210???
I think this is because there are not many positions where king is on these squares in middle game, but there's a large amount of data for king on 7th and 8th rank, hence squares there have balanced values. However I am using ~1.4million positions to train, which seems enough, especially for 400 parameters.
So I think more data isn't the solution...
Then I have a question, how do I ensure in texel's tuning that parameters don't take such weird values, as with the middle game king in the forward ranks???

When you get weird values there is not much you can do to restrict them. Either your training positions are missing relevant information, or there is something wrong with the algorithm you use to optimize the PSQT's.

It's been a long time since I last used logistic regression with gradient descent to optimize my HCE, the values I found for the king PSQT are:

Code: Select all

int psqKingMG[64] =
{
61,   89,   61,   24,   24,   61,   89,   61,
64,   77,   42,   15,   15,   42,   77,   64,
23,   54,   10,  -15,  -15,   10,   54,   23,
7,   20,   -6,  -26,  -26,   -6,   20,    7,
2,   15,  -22,  -40,  -40,  -22,   15,    2,
-13,   -2,  -34,  -59,  -59,  -34,   -2,  -13,
-31,  -15,  -42,  -58,  -58,  -42,  -15,  -31,
-45,  -30,  -52,  -75,  -75,  -52,  -30,  -45,
};

int psqKingEG[64] =
{
-58,  -36,  -16,  -20,  -20,  -16,  -36,  -58,
-32,   -8,    8,    9,    9,    8,   -8,  -32,
-14,    7,   26,   29,   29,   26,    7,  -14,
-7,   20,   28,   28,   28,   28,   20,   -7,
-10,   25,   41,   41,   41,   41,   25,  -10,
-12,   28,   34,   37,   37,   34,   28,  -12,
-35,    2,    0,    7,    7,    0,    2,  -35,
-53,  -29,  -22,  -19,  -19,  -22,  -29,  -53,
};

I trained these PSQT's horizontally mirrored, e.g. A1..D1 is the same as H1..E1, without mirroring these values would be different. It all depends very much upon the dataset you use for training, if there is too little information about these king-positions in your dataset you will get weird values.

I did find I have plenty of positions in the dataset, however, in the middle-game specifically I had none where the king was out in the middle. The endgame king table actually looks quite normal:

Code: Select all

    -55, -15, -10, -10, -5, 0, -5, -35, 
    -20, 15, 10, 5, 5, 25, 20, -5, 
    -20, 15, 10, 10, 10, 25, 30, 5, 
    -35, -5, 10, 10, 5, 15, 10, -10, 
    -35, -10, 5, 10, 10, 10, 0, -15, 
    -30, -5, 5, 10, 10, 10, 5, -10, 
    -25, -5, 5, 10, 10, 15, 10, 0, 
    -30, -5, 0, -20, -10, -10, -5, -35, 

I wonder what methods did you use to get such stable values for the king in the middle game?

[adityachandra]

I think I have the answer, I will try my assumption out first:
The way my program weights between middle and endgame is that the weight reaches zero once there is less than 26 points of material (excluding pawns) on the board. But most programs I see have weights for queen, rook, bishop and knight as 4, 2, 2, 1, and simply divide by 24. It never reaches zero until there is nothing on the board except pawns. So this may be why my middle game king eval is so messed up, majority of the time it is simply not factored in, and hence can't use the data when material is less than 26! However, with most common scheme that's not the case.

[Joost Buijs]

I didn't use a special method to get these values, it is just logistic regression with gradient descent or "Texel tuning" as you may call it. It is at least 5 years ago since I last used it, I don't remember all the details but the dataset I used was a mix of the Ethereal and the Zurichess training positions. The Zurichess quiet-labeled-v7 gave me reliable results, some of the Ethereal datasets gave me weird results, but not all. I think that the Zurichess dataset is a very good dataset to start with, later on you can always build your own dataset.

The PSQT's were normalized in such a way that the sum of all the values are exactly zero, of course this is not necessary. You can also incorporate the piece values into the PSQT's, in fact it is a bit weird to train the piece values as a separate entity.

[JVMerlino]

I didn't use a special method to get these values, it is just logistic regression with gradient descent or "Texel tuning" as you may call it. It is at least 5 years ago since I last used it, I don't remember all the details but the dataset I used was a mix of the Ethereal and the Zurichess training positions. The Zurichess quiet-labeled-v7 gave me reliable results, some of the Ethereal datasets gave me weird results, but not all. I think that the Zurichess dataset is a very good dataset to start with, later on you can always build your own dataset.

Indeed, I used the "quiet-labeled" set to start off and it gave very good initial results. Then I decided to use a larger set, in this case the "lichess-big3-resolved" set, and it gave even better results (although not as much of an elo gain as with the first Texel tuning attempt, obviously). Here are my king PSTs:

Code: Select all

// King MG
{
	-26,  42,  12,   6, -19,  -4,  30,  50,
	  1,  49,  20,  34,  23,  39,  31, -13,
	 11,  58,  21,   4,  17,  77,  43,  14,
	-22, -19, -21, -115, -86, -44, -31, -80,
	-22, -13, -57, -130, -132, -70, -60, -91,
	 -2,   5, -50, -87, -84, -59, -19, -38,
	 60,  26,   0, -41, -44, -19,  24,  32,
	 30,  59,  42, -62,   1, -31,  31,  38,
}

// King EG
{
	-76, -46, -37, -17, -15,   1,   2, -84,
	-18,  11,   8,   8,  18,  36,  37,  11,
	 -7,  17,  25,  30,  34,  35,  40,   9,
	-11,  21,  35,  44,  43,  43,  34,  14,
	-22,   7,  29,  45,  44,  35,  21,   9,
	-25,   2,  20,  29,  30,  24,   7,  -2,
	-31,  -8,  13,  11,  15,   9,  -6, -21,
	-55, -44, -19, -10, -32,  -9, -35, -58,
}