Math question

[Rebel]

I am working on a Polyglot book with a 32-bit WDL extension for a 1) better weight calculation, 2) better learn calculation and 3) maintain an opening repertoire. From the start position:

Code: Select all

Opening Book : books\elo2700.bin
Positions    : 716.101

Book Weight Score Depth Learn   Total     Won    Draw    Loss     Perc      WD      WDL
e2e4  41.93%     0    0     0    6456    1833    3415    1208    54.84%   41.92%   30.27%
d2d4  37.19%     0    0     0    5727    1607    3067    1053    54.83%   37.19%   27.09%
g1f3  12.23%     0    0     0    1899     567     932     400    54.39%   12.23%    8.22%
c2c4   7.00%     0    0     0    1092     314     555     223    54.16%    7.00%    4.78%
b2b3   0.78%     0    0     0     120      45      40      35    54.16%    0.77%    0.39%
g2g3   0.56%     0    0     0      72      35      25      12    65.97%    0.56%    0.46%
f2f4   0.11%     0    0     0      14       7       5       2    67.85%    0.11%    0.09%
b1c3   0.10%     0    0     0      19       5       6       8    42.10%    0.09%    0.00%
d2d3   0.03%     0    0     0       3       3       0       0   100.00%    0.03%    0.03%
b2b4   0.02%     0    0     0       3       2       0       1    66.66%    0.02%    0.01%
a2a3   0.01%     0    0     0       3       1       1       1    50.00%    0.01%    0.00%
a2a4   0.01%     0    0     0       1       1       0       0   100.00%    0.01%    0.01%
Totals                          15409    4420    8046    2943

The tradional Polyglot weight calculation works as follows: (2*won+draw)*100 / (2*total_win+total_draw)
We then for e2e4 get (1833*2+3415)*100 / (4420*2+8046) = 708.100 / 16.886 = 41.93% (see Weight & WD)

While this works reasonable well in practice the numbers of losses is not part of the calculation and actually it should. I have been trying various formulas (see WDL) including the number of losses but nothing is satisfying so far.

Also, the moves c4,Nf3 both score 54% equal to e4 and d4 with a considerable number of games played and yet their weight percentage is poorly (12.23%, 7.00%). 1.g3 (72 games and 65.97%) is reduced to 0.56%. While this is not a problem on the first move I wouldn't like to see a move with 65% reduced that way on the 5th move. The weight formula strongly relies on the number of games, perhaps too much.

For a better weight formula the extra ingredient percentage (maybe) could help.

I wonder if there is something better else I leave things as they are.

[jdart]

You can view move selection as an example of the "multi-armed bandit" problem. You have a prior distribution of outcomes (win/loss/draw) and you are trying to optimize the future "payout" (score).

There is a very large literature on this but one approach is called Thompson Sampling (https://en.wikipedia.org/wiki/Thompson_sampling). Basically it builds a model of the distribution of outcomes (a gamma distribution in this case) for each option (move) and then does a random sample from it and calculates the score based on that random sample. Repeat for all the moves. Then choose the one with the highest score.

The idea is that you tend to pick the best scoring choice but will occasionally sample other choices.

This is mathematically sound. However, when you have a big set of W/D/L statistics for each move, this approach will basically always choose the one with the best historical score, even if that is very close to the score of other moves, because with large numbers of prior scores, the standard deviation of the distributions you are sampling from become very small. Once it is "sure" it has the best scoring move, this algorithm will always pick it.

Arasan's book addresses this by adding a normally distributed random value to the score from each sample. The standard deviation of this is configurable. There is also some support for manually tuning weights, and there is a configurable penalty for moves that are relatively very rare. This is further explained in the Programmer's Guide (https://arasanchess.org/programr.shtml).

[MikeB]

I am working on a Polyglot book with a 32-bit WDL extension for a 1) better weight calculation, 2) better learn calculation and 3) maintain an opening repertoire. From the start position:

Code: Select all

Opening Book : books\elo2700.bin
Positions    : 716.101

Book Weight Score Depth Learn   Total     Won    Draw    Loss     Perc      WD      WDL
e2e4  41.93%     0    0     0    6456    1833    3415    1208    54.84%   41.92%   30.27%
d2d4  37.19%     0    0     0    5727    1607    3067    1053    54.83%   37.19%   27.09%
g1f3  12.23%     0    0     0    1899     567     932     400    54.39%   12.23%    8.22%
c2c4   7.00%     0    0     0    1092     314     555     223    54.16%    7.00%    4.78%
b2b3   0.78%     0    0     0     120      45      40      35    54.16%    0.77%    0.39%
g2g3   0.56%     0    0     0      72      35      25      12    65.97%    0.56%    0.46%
f2f4   0.11%     0    0     0      14       7       5       2    67.85%    0.11%    0.09%
b1c3   0.10%     0    0     0      19       5       6       8    42.10%    0.09%    0.00%
d2d3   0.03%     0    0     0       3       3       0       0   100.00%    0.03%    0.03%
b2b4   0.02%     0    0     0       3       2       0       1    66.66%    0.02%    0.01%
a2a3   0.01%     0    0     0       3       1       1       1    50.00%    0.01%    0.00%
a2a4   0.01%     0    0     0       1       1       0       0   100.00%    0.01%    0.01%
Totals                          15409    4420    8046    2943

The tradional Polyglot weight calculation works as follows: (2*won+draw)*100 / (2*total_win+total_draw)
We then for e2e4 get (1833*2+3415)*100 / (4420*2+8046) = 708.100 / 16.886 = 41.93% (see Weight & WD)

While this works reasonable well in practice the numbers of losses is not part of the calculation and actually it should. I have been trying various formulas (see WDL) including the number of losses but nothing is satisfying so far.

Also, the moves c4,Nf3 both score 54% equal to e4 and d4 with a considerable number of games played and yet their weight percentage is poorly (12.23%, 7.00%). 1.g3 (72 games and 65.97%) is reduced to 0.56%. While this is not a problem on the first move I wouldn't like to see a move with 65% reduced that way on the 5th move. The weight formula strongly relies on the number of games, perhaps too much.

For a better weight formula the extra ingredient percentage (maybe) could help.

I wonder if there is something better else I leave things as they are.

Maybe this: Games played is weighted 3x times score (abbreviated display to show the common moves and with the less played g2g3 with the high score)

Code: Select all

columns ->B	C	D	E	F	G	H	I	J
									
rows									
4	move	games	wins	draws	losses	Sco %	%Play	%Scr	Weighting Pct
5	e4	6456	1833	3415	1208	54.84%	42.35%	19.30%	36.58%
6	d4	5727	1607	3067	1053	54.84%	37.56%	19.29%	33.00%
7	g1f3	1899	567	932	400	54.40%	12.46%	19.14%	14.13%
8	c2c4	1092	314	555	223	54.17%	7.16%	19.06%	10.14%
9	g2g3	72	35	25	12	65.97%	0.47%	23.21%	6.16%
10		----	----	----	----	----	----	----	----
11		15246	4356	7994	2896	284.21%			100.00%

Code: Select all

columns ->		G			H		I		J
Formulas in row 5	=(2*D5+E5)/2/C5		=C5/$C$11	=G5/$G$11	=(3*H5+I5)/4

[MikeB]

I am working on a Polyglot book with a 32-bit WDL extension for a 1) better weight calculation, 2) better learn calculation and 3) maintain an opening repertoire. From the start position:

Code: Select all

Opening Book : books\elo2700.bin
Positions    : 716.101

Book Weight Score Depth Learn   Total     Won    Draw    Loss     Perc      WD      WDL
e2e4  41.93%     0    0     0    6456    1833    3415    1208    54.84%   41.92%   30.27%
d2d4  37.19%     0    0     0    5727    1607    3067    1053    54.83%   37.19%   27.09%
g1f3  12.23%     0    0     0    1899     567     932     400    54.39%   12.23%    8.22%
c2c4   7.00%     0    0     0    1092     314     555     223    54.16%    7.00%    4.78%
b2b3   0.78%     0    0     0     120      45      40      35    54.16%    0.77%    0.39%
g2g3   0.56%     0    0     0      72      35      25      12    65.97%    0.56%    0.46%
f2f4   0.11%     0    0     0      14       7       5       2    67.85%    0.11%    0.09%
b1c3   0.10%     0    0     0      19       5       6       8    42.10%    0.09%    0.00%
d2d3   0.03%     0    0     0       3       3       0       0   100.00%    0.03%    0.03%
b2b4   0.02%     0    0     0       3       2       0       1    66.66%    0.02%    0.01%
a2a3   0.01%     0    0     0       3       1       1       1    50.00%    0.01%    0.00%
a2a4   0.01%     0    0     0       1       1       0       0   100.00%    0.01%    0.01%
Totals                          15409    4420    8046    2943

The tradional Polyglot weight calculation works as follows: (2*won+draw)*100 / (2*total_win+total_draw)
We then for e2e4 get (1833*2+3415)*100 / (4420*2+8046) = 708.100 / 16.886 = 41.93% (see Weight & WD)

While this works reasonable well in practice the numbers of losses is not part of the calculation and actually it should. I have been trying various formulas (see WDL) including the number of losses but nothing is satisfying so far.

Also, the moves c4,Nf3 both score 54% equal to e4 and d4 with a considerable number of games played and yet their weight percentage is poorly (12.23%, 7.00%). 1.g3 (72 games and 65.97%) is reduced to 0.56%. While this is not a problem on the first move I wouldn't like to see a move with 65% reduced that way on the 5th move. The weight formula strongly relies on the number of games, perhaps too much.

For a better weight formula the extra ingredient percentage (maybe) could help.

I wonder if there is something better else I leave things as they are.

Maybe this: Games played is weighted 3x times score (abbreviated display to show the common moves and with the less played g2g3 with the high score)

Code: Select all

columns ->B	C	D	E	F	G	H	I	J
									
rows									
4	move	games	wins	draws	losses	Sco %	%Play	%Scr	Weighting Pct
5	e4	6456	1833	3415	1208	54.84%	42.35%	19.30%	36.58%
6	d4	5727	1607	3067	1053	54.84%	37.56%	19.29%	33.00%
7	g1f3	1899	567	932	400	54.40%	12.46%	19.14%	14.13%
8	c2c4	1092	314	555	223	54.17%	7.16%	19.06%	10.14%
9	g2g3	72	35	25	12	65.97%	0.47%	23.21%	6.16%
10		----	----	----	----	----	----	----	----
11		15246	4356	7994	2896	284.21%			100.00%

Code: Select all

columns ->		G			H		I		J
Formulas in row 5	=(2*D5+E5)/2/C5		=C5/$C$11	=G5/$G$11	=(3*H5+I5)/4

using the full set presented:

Code: Select all

move	games	wins	draws	losses	Sco %	%Play	%Scr	Weighting Pct
e2e4	6456	1833	3415	1208	54.84%	41.96%	14.41%	35.08%
d2d4	5727	1607	3067	1053	54.84%	37.22%	14.41%	31.52%
g1f3	1899	567	932	400	54.40%	12.34%	14.30%	12.83%
c2c4	1092	314	555	223	54.17%	7.10%	14.24%	8.88%
b2b3	120	45	40	35	54.17%	0.78%	14.24%	4.14%
g2g3	72	35	25	12	65.97%	0.47%	17.34%	4.69%
f2f4	14	7	5	2	67.86%	0.09%	17.83%	4.53%
b1c3	19	5	6	8	42.11%	0.12%	11.07%	2.86%
d2d3	3	3	0	0	100.00%	0.02%	26.28%	6.59%
b2b4	3	2	0	1	66.67%	0.02%	17.52%	4.39%
a2a3	3	1	1	1	50.00%	0.02%	13.14%	3.30%
a2a4	1	1	0	0	100.00%	0.01%	26.28%	6.58%

I would exclude moves that are played less than xx% - let's try 0.1% , or exclude moves that are played less than once every thousand games.

Code: Select all

move	games	wins	draws	losses	Sco %	%Play	%Scr	Weighting Pct
e2e4	6456	1833	3415	1208	54.84%	41.96%	14.41%	35.08%
d2d4	5727	1607	3067	1053	54.84%	37.22%	14.41%	31.52%
g1f3	1899	567	932	400	54.40%	12.34%	14.30%	12.83%
c2c4	1092	314	555	223	54.17%	7.10%	14.24%	8.88%
b2b3	120	45	40	35	54.17%	0.78%	14.24%	4.14%
g2g3	72	35	25	12	65.97%	0.47%	17.34%	4.69%
b1c3	19	5	6	8	42.11%	0.12%	11.07%	2.86%

[Ajedrecista]

Hello Ed:

While this works reasonable well in practice the numbers of losses is not part of the calculation and actually it should.

I think that the number of loses is hidden in (2*won+draw)*100 / (2*total_win+total_draw). Let me explain. Try the following:

Code: Select all

For each i-th opening move:
n_i = w_i + d_i + l_i
µ_i = (w_i + 0.5*d_i)/(w_i + d_i + l_i)

N = SUM(n_i)          // For all i.

r_i = n_i * µ_i / N

R = SUM(r_i)          // For all i.

p_i = r_i / R          // To ensure SUM(p_i) = 100% for all i.

I get exactly the same results with p_i than with (2*won+draw)*100 / (2*total_win+total_draw). In short, p_i is proportional to (n_i / N)*µ_i, where loses take effect into µ_i = (w_i + 0.5*d_i)/(w_i + d_i + l_i), then weighting with the percentage of played games in the database.

------------------------

You could try the lower bound of Wilson score interval:

Code: Select all

z ~ 1.959963985 (95% confidence in a normal distribution; you can change z)

[1]: lower bound of the Wilson score interval.
[2]: lower bound of the Wilson score interval (with continuity correction).

Move       n        w        d        l           µ              [1]        Weight [1]         [2]        Weight [2]
====================================================================================================================
e2e4     6456     1833     3415     1208     0.548404585     0.536240132      11.33%       0.536162548      12.64%
d2d4     5727     1607     3067     1053     0.548367383     0.535450427      11.32%       0.535362960      12.62%
g1f3     1899      567      932      400     0.543970511     0.521503069      11.02%       0.521239265      12.29%
c2c4     1092      314      555      223     0.541666667     0.512019633      10.82%       0.511561116      12.06%
b2b3      120       45       40       35     0.541666667     0.452609691       9.56%       0.448515804      10.58%
g2g3       72       35       25       12     0.659722222     0.544692535      11.51%       0.537613038      12.68%
f2f4       14       7         5        2     0.678571429     0.420031729       8.88%       0.387644231       9.14%
b1c3       19       5         6        8     0.421052632     0.231418913       4.89%       0.211206911       4.98%
d2d3        3       3         0        0     1.000000000     0.438502968       9.27%       0.309988106       7.31%
b2b4        3       2         0        1     0.666666667     0.207659601       4.39%       0.125334472       2.96%
a2a3        3       1         1        1     0.500000000     0.125334472       2.65%       0.061491945       1.45%
a3a4        1       1         0        0     1.000000000     0.206549314       4.36%       0.054620756       1.29%
------------------------------------------------------------------------------------------------------------------
SUM     15409     4420     8046     2943                     4.732012484     100.00%       4.240741152     100.00%

I hope no typos. It gives higher frequencies for g3 than for e4, d4, Nf3 and c4 due to the very high µ with not so few games; d3 and f4 high frequencies are similar cases, not mentioning b3.

You might try lower bounds of other binomial approaches (Clopper-Pearson, Agresti-Coull...). But it will depend on your expectations (25%-20%-20%-20% for e4-d4-Nf3-c4 or what?).

------------------------

I stay tuned because I find this topic interesting. Good luck!

Regards from Spain.

Ajedrecista.

[Ferdy]

I am working on a Polyglot book with a 32-bit WDL extension for a 1) better weight calculation, 2) better learn calculation and 3) maintain an opening repertoire. From the start position:

I think it is interesting to try the multiple linear regression method. Our independent variables will be win, loss, draw and our dependent variable is the score rate or win+draw/2. This is suitable for regression because win vs score rate, loss vs score rate and draw vs score rate have linear relationships. But with multiple regression we try to find the best coefficients of win, loss, draw simultaneously.
rate = a + b*win + c*loss + d*draw
we try to find the best a, b, c and d to get a high rate.

Our input data could be a csv file with columns win, loss, draw, srate.
where:
win = number of wins
loss = number of loses
draw = number of draws
srate = win+draw/2

These info can be extracted from pgn.

Example csv could be.

fen, move, win, loss, draw, srate

fen1 = startpos

fen1, e4, 200, 180, 500, 0.51136
fen1, d4, 180, 160, ..., ...
and so on.

fen2 = startpos moves e2e4 e7e5

fen2, Nf3, ..., ..., ..., ...
fen2, Bc4, ..., ..., ..., ...
and so on.

fen3 = startpos moves d2d4 g8f6 c2c4

fen3, e6, ..., ..., ..., ...
and so on.

But columns win, loss, draw, srate are enough, there is no need to inlude the fen, and move columns.

Started writing the script, if you are interested you may send your csv later. In the meantime I will try to get some data from a small sample pgn. I am interested to see how this method would perform.

[Zenmastur]

I am working on a Polyglot book with a 32-bit WDL extension for a 1) better weight calculation, 2) better learn calculation and 3) maintain an opening repertoire. From the start position:

Code: Select all

Opening Book : books\elo2700.bin
Positions    : 716.101

Book Weight Score Depth Learn   Total     Won    Draw    Loss     Perc      WD      WDL
e2e4  41.93%     0    0     0    6456    1833    3415    1208    54.84%   41.92%   30.27%
d2d4  37.19%     0    0     0    5727    1607    3067    1053    54.83%   37.19%   27.09%
g1f3  12.23%     0    0     0    1899     567     932     400    54.39%   12.23%    8.22%
c2c4   7.00%     0    0     0    1092     314     555     223    54.16%    7.00%    4.78%
b2b3   0.78%     0    0     0     120      45      40      35    54.16%    0.77%    0.39%
g2g3   0.56%     0    0     0      72      35      25      12    65.97%    0.56%    0.46%
f2f4   0.11%     0    0     0      14       7       5       2    67.85%    0.11%    0.09%
b1c3   0.10%     0    0     0      19       5       6       8    42.10%    0.09%    0.00%
d2d3   0.03%     0    0     0       3       3       0       0   100.00%    0.03%    0.03%
b2b4   0.02%     0    0     0       3       2       0       1    66.66%    0.02%    0.01%
a2a3   0.01%     0    0     0       3       1       1       1    50.00%    0.01%    0.00%
a2a4   0.01%     0    0     0       1       1       0       0   100.00%    0.01%    0.01%
Totals                          15409    4420    8046    2943

The tradional Polyglot weight calculation works as follows: (2*won+draw)*100 / (2*total_win+total_draw)
We then for e2e4 get (1833*2+3415)*100 / (4420*2+8046) = 708.100 / 16.886 = 41.93% (see Weight & WD)

While this works reasonable well in practice the numbers of losses is not part of the calculation and actually it should. I have been trying various formulas (see WDL) including the number of losses but nothing is satisfying so far.

Also, the moves c4,Nf3 both score 54% equal to e4 and d4 with a considerable number of games played and yet their weight percentage is poorly (12.23%, 7.00%). 1.g3 (72 games and 65.97%) is reduced to 0.56%. While this is not a problem on the first move I wouldn't like to see a move with 65% reduced that way on the 5th move. The weight formula strongly relies on the number of games, perhaps too much.

For a better weight formula the extra ingredient percentage (maybe) could help.

I wonder if there is something better else I leave things as they are.

You can view move selection as an example of the "multi-armed bandit" problem. You have a prior distribution of outcomes (win/loss/draw) and you are trying to optimize the future "payout" (score).

There is a very large literature on this but one approach is called Thompson Sampling (https://en.wikipedia.org/wiki/Thompson_sampling). Basically it builds a model of the distribution of outcomes (a gamma distribution in this case) for each option (move) and then does a random sample from it and calculates the score based on that random sample. Repeat for all the moves. Then choose the one with the highest score.

The idea is that you tend to pick the best scoring choice but will occasionally sample other choices.

Well, if your keeping the book statistics up to date as new games are played then the highest scoring move should be played next. But, this isn't the best move AND it's not meant to be the best move. There are two consideration involved, one is the best scoring move and the other is the move that the book will learn the most information from. These are balanced, or can be balanced depending on the type of play. If you are using the book in a testing frame work then I would think the balance should be in favor of book learning speed. When used in a tournament setting the best move(s) should be favored somewhat over learning and certain moves should be avoided all together. Even if this will leave the book unbalanced at the end of the tournament. Further, if the book is going to be used in a tournament it should be artificially balanced before the tournament starts otherwise the book algorithm WILL try to balance the book during the tournament possibly with bad results.

This is mathematically sound. However, when you have a big set of W/D/L statistics for each move, this approach will basically always choose the one with the best historical score, even if that is very close to the score of other moves, because with large numbers of prior scores, the standard deviation of the distributions you are sampling from become very small. Once it is "sure" it has the best scoring move, this algorithm will always pick it.

I didn't read through the reference you provided but that's not my understanding of proper operation of the book. It shouldn't be selecting the move with the highest average game score. It should select the move with the highest ranking score. Which if the book is set up right should be the move that has seen the greatest deficit between it's optimal number of trials and the number of times it's actually been played (I.e Actual times played – optimal number of plays = deficit if less than zero ) considering it's average game score. That is definitely not the same thing as picking the best move. And it does depend on the scoring function used, which can be modified to change the algorithms behavior to a certain extent.

Which might look some thing like this:

Move ranking Score = (Average game score for this move) + SQRT(Constant1*LOG(Total number of games played from this position)/number of times this move has been played).

If I recall properly. It's been a while since I looked at this in depth and my memory isn't that good so for the time being take this with a grain of salt. I have a spread sheet somewhere with all the pertinent information in it along with several modified equation for fast learning, optimal play, tournament play etc. But I'm busy right now so it may take a while before I can locate and re-familiarize myself with it. IIRC there are some non-obvious ways that the main scoring equation can be rearranged and modified for various purposes. Also there are ways that a chess specific MAB can be modified using chess specific knowledge to greatly enhance it's utility that is generally not available to “standard” MAB algorithms.

Edit: I think the formula above is a modified version of the standard formula used. But I'm not at all sure what the purpose of this modification was. I'll have to look for the spreadsheet to determine that.

Regards,

Zenmastur

[Rebel]

Which might look some thing like this:

Move ranking Score = (Average game score for this move) + SQRT(Constant1*LOG(Total number of games played from this position)/number of times this move has been played).

Looks as something to try, what initial number to feed "Constant1" with?

[Rebel]

I am working on a Polyglot book with a 32-bit WDL extension for a 1) better weight calculation, 2) better learn calculation and 3) maintain an opening repertoire. From the start position:

I think it is interesting to try the multiple linear regression method. Our independent variables will be win, loss, draw and our dependent variable is the score rate or win+draw/2. This is suitable for regression because win vs score rate, loss vs score rate and draw vs score rate have linear relationships. But with multiple regression we try to find the best coefficients of win, loss, draw simultaneously.
rate = a + b*win + c*loss + d*draw
we try to find the best a, b, c and d to get a high rate.

Our input data could be a csv file with columns win, loss, draw, srate.
where:
win = number of wins
loss = number of loses
draw = number of draws
srate = win+draw/2

These info can be extracted from pgn.

Example csv could be.

fen, move, win, loss, draw, srate

fen1 = startpos

fen1, e4, 200, 180, 500, 0.51136
fen1, d4, 180, 160, ..., ...
and so on.

fen2 = startpos moves e2e4 e7e5

fen2, Nf3, ..., ..., ..., ...
fen2, Bc4, ..., ..., ..., ...
and so on.

fen3 = startpos moves d2d4 g8f6 c2c4

fen3, e6, ..., ..., ..., ...
and so on.

But columns win, loss, draw, srate are enough, there is no need to inlude the fen, and move columns.

Started writing the script, if you are interested you may send your csv later. In the meantime I will try to get some data from a small sample pgn. I am interested to see how this method would perform.

Interesting....

Will provide a csv when you are ready.

[Ferdy]

I am working on a Polyglot book with a 32-bit WDL extension for a 1) better weight calculation, 2) better learn calculation and 3) maintain an opening repertoire. From the start position:

I think it is interesting to try the multiple linear regression method. Our independent variables will be win, loss, draw and our dependent variable is the score rate or win+draw/2. This is suitable for regression because win vs score rate, loss vs score rate and draw vs score rate have linear relationships. But with multiple regression we try to find the best coefficients of win, loss, draw simultaneously.
rate = a + b*win + c*loss + d*draw
we try to find the best a, b, c and d to get a high rate.

Our input data could be a csv file with columns win, loss, draw, srate.
where:
win = number of wins
loss = number of loses
draw = number of draws
srate = win+draw/2

These info can be extracted from pgn.

Example csv could be.

fen, move, win, loss, draw, srate

fen1 = startpos

fen1, e4, 200, 180, 500, 0.51136
fen1, d4, 180, 160, ..., ...
and so on.

fen2 = startpos moves e2e4 e7e5

fen2, Nf3, ..., ..., ..., ...
fen2, Bc4, ..., ..., ..., ...
and so on.

fen3 = startpos moves d2d4 g8f6 c2c4

fen3, e6, ..., ..., ..., ...
and so on.

But columns win, loss, draw, srate are enough, there is no need to inlude the fen, and move columns.

Started writing the script, if you are interested you may send your csv later. In the meantime I will try to get some data from a small sample pgn. I am interested to see how this method would perform.

Interesting....

Will provide a csv when you are ready.

I got some results, using positions from FGRL games.
Plots of actual data points for srate vs W/T and srate vs L/T. srate is (W+D/2)/T, winrate is W/T and lossrate is L/T. There is not much to optimize, it just maximizes the winrate and then minimizes the lossrate.



The drawrate has no effect as both get half point. So I tried srate vs D/L or ratio of draw/loss, better to have draws and less losses.
As D/L increases the srate increases.


It comes up with

Code: Select all

Intercept: 0.41464514110130124
Coefficients: [ 6.52168714e-01 -5.75505449e-01  1.30984117e-06]

perf = 0.41464514110130124 + 6.52168714e-01 * W + (-5.75505449e-01) * L + 1.30984117e-06 * D

Example:
W: 187, L: 134, D: 418
perf: 45.25%

The coefficients are dominated by W and L and D is neglible.

Don't bother sending that csv.