The QS root might not be quiet. It would introduce a lot of noise, and possibly bias, to include nonquiet positions in your test set. E.g. if you were tuning a 'sidetomove bonus', it would get very large, indicating how much hanging material you can gobble up on the average in the test set.Sven Schüle wrote:I understand that. But what is the advantage of doing a search, then, instead of directly calling static eval for each (root) position and calculating the gradient of the corresponding error function, based on initially gathering reference eval scores?
Texel tuning method question
Moderators: Harvey Williamson, Dann Corbit, hgm
Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
 hgm
 Posts: 25448
 Joined: Fri Mar 10, 2006 9:06 am
 Location: Amsterdam
 Full name: H G Muller
 Contact:
Re: Texel tuning method question

 Posts: 4037
 Joined: Fri Mar 10, 2006 4:23 am
 Location: http://www.arasanchess.org
Re: Texel tuning method question
It isn't. But after obtaining the PV in the first iteration I don't then actually do another search after adjusting the parameters. Each gradient descent step just does a static eval for each position and assumes the PV does not change. (I don't take credit for this idea: it was used in the related MMTO optimization method by Hoki and Kaneko). I have the option of periodically recalculating the PV after some number of iterations.So at first glance i don't know in what way the "eval at the end of the pv" is different to the search result score.
Jon
Last edited by jdart on Wed Jun 07, 2017 2:53 pm, edited 1 time in total.

 Posts: 4037
 Joined: Fri Mar 10, 2006 4:23 am
 Location: http://www.arasanchess.org
Re: Texel tuning method question
Gradient descent is fast and 400 parameters is not a problem for that.
Jon
Jon
Re: Texel tuning method question
Again and very simple !hgm wrote:The QS root might not be quiet. It would introduce a lot of noise, and possibly bias, to include nonquiet positions in your test set. E.g. if you were tuning a 'sidetomove bonus', it would get very large, indicating how much hanging material you can gobble up on the average in the test set.Sven Schüle wrote:I understand that. But what is the advantage of doing a search, then, instead of directly calling static eval for each (root) position and calculating the gradient of the corresponding error function, based on initially gathering reference eval scores?
I simply asked for the terminologie "endofPV evals" which is a nonsense term imho because any normal search will produce a "search result score" that is the value of a pv leaf node
(is this the crux at this point ? are we talking of qs value of the leaf node or a static eval score of the leaf node).
And what has it to do with the Texel algorihm itself? I ask again because if you have blackbox which provides the score, the algorithm will work exactly the same.
If i come close with my understanding which would mean a static score from the pv leaf, i bet it provides the same noise as any other static score you compute in any other situation.
Last edited by Desperado on Wed Jun 07, 2017 3:02 pm, edited 1 time in total.

 Posts: 523
 Joined: Sat Mar 25, 2006 7:27 pm
Re: Texel tuning method question
What I think about are the situations where you have a series of exchanges in the PV. If you minimize error on the root, then you have several extra pieces on the board that will have their values affecting the score when they shouldn't, adding noise and misfitting.Sven Schüle wrote: I understand that. But what is the advantage of doing a search, then, instead of directly calling static eval for each (root) position and calculating the gradient of the corresponding error function, based on initially gathering reference eval scores?

 Posts: 925
 Joined: Tue Mar 09, 2010 2:46 pm
 Location: New York
 Full name: Álvaro Begué (RuyDos)
Re: Texel tuning method question
I don't know if I can explain it any clearer than it has been explained already, but I'll give it another try.Desperado wrote:Again and very simple !hgm wrote:The QS root might not be quiet. It would introduce a lot of noise, and possibly bias, to include nonquiet positions in your test set. E.g. if you were tuning a 'sidetomove bonus', it would get very large, indicating how much hanging material you can gobble up on the average in the test set.Sven Schüle wrote:I understand that. But what is the advantage of doing a search, then, instead of directly calling static eval for each (root) position and calculating the gradient of the corresponding error function, based on initially gathering reference eval scores?
I simply asked for the term "endofPV evals" which is a nonsense term imho because any normal search will produce a "search result score" that is the value of a pv leaf node (is this the crux at this point ? are we talking of qs value of the leaf node or a static eval score of the leaf node).
And what has it to do with the Texel algorihm itself? I ask again because if you have blackbox which provides the score, the algorithm will work exactly the same.
If i come close with my understanding which would mean a static score from the pv leaf, i bet i provides the same noise as any other static score you compute in any other situation.
In Texel's tuning method you are trying to minimize a function E, which is the average value of the square of the difference between the result of a game and the sigmoid of the QS score (with infinite alphabeta window) of a position that happened during the game, with the average taken over a large number of training pairs.
In order to do this minimization, we'll use the gradient of E with respect to the parameters we are trying to tune. By linearity of the derivative, this is the average of the gradients of the functions that compute the square error for a single position.
OK, now that the stage has been set: The gradient computation is done by performing the QS search on the position, recovering the leaf of the QS search tree whose score was propagated to the root of the QS search, and then computing the gradient on that position.
Yes, the endofPV static evaluation will be the same as the result of the QS search, but thinking of it as the endofPV static evaluation allows you to compute the gradient more easily.
I'll be happy to explain technical details about how the gradient can be computed, if that might help.
Re: Texel tuning method question
Hello Jon,jdart wrote:It isn't. But after obtaining the PV in the first iteration I don't then actually do another search after adjusting the parameters. Each gradient descent step just does a static eval for each position and assumes the PV does not change. (I don't take credit for this idea: it was used in the related MMTO optimization method by Hoki and Kaneko). I have the option of periodically recalculating the PV after some number of iterations.So at first glance i don't know in what way the "eval at the end of the pv" is different to the search result score.
Jon
this assumption can always be done, even if you do not compute the pv but retrieve the score from a blackbox. I don't see the clue. But thx for some more clarification that helped at least a little bit.
Re: Texel tuning method question
Sorry HG, but this isn't a matter of the tuning algorithm, but a matter of the raw data. If you build a database that already satisfies the qualitiy requierments you can simply perform direct calls an the static eval for the root.hgm wrote:The QS root might not be quiet. It would introduce a lot of noise, and possibly bias, to include nonquiet positions in your test set. E.g. if you were tuning a 'sidetomove bonus', it would get very large, indicating how much hanging material you can gobble up on the average in the test set.Sven Schüle wrote:I understand that. But what is the advantage of doing a search, then, instead of directly calling static eval for each (root) position and calculating the gradient of the corresponding error function, based on initially gathering reference eval scores?
The algorithm is not affected and the choice of the raw data is a different matter. Finally the term "endofPV evals" is a redundant vocabulary that does not introduce some special meaning.
Well, imho a good preparation of the raw data allows fast computing of the gradient because the of the assumption that a pv does not change and the assumption that we have a collection of positions with minimal noise.
Now, imho the Texel algorithm is not effected and no special terminology is needed.
Thx to all of you.
Re: Texel tuning method question
Hi Alvaro,
Of course , thx for your patience.... 'll be happy to explain technical details about how the gradient can be computed, if that might help...
 hgm
 Posts: 25448
 Joined: Fri Mar 10, 2006 9:06 am
 Location: Amsterdam
 Full name: H G Muller
 Contact:
Re: Texel tuning method question
What you seem to miss is that the tuning method doesn't use only the score, but also the gradient of the score, i.e. the direction in parameter space in which the score increases fastest. It needs this to know the relative magnitude of the changes it has to apply to all the parameters to get closer to the optimum.Desperado wrote:If i come close with my understanding which would mean a static score from the pv leaf, i bet it provides the same noise as any other static score you compute in any other situation.
To know this, you have to know how the score of the individual test cases will change as a result of a change in each parameter. But you cannot see how much each parameter contributes to the score in the root. E.g. the root could have a Rook for the opponent, and none for you. Then the Root score would get worse for you if the Rook value increases. But the PV might be NxR, PxN, so that the position at the end of the PV does not contain any Rooks at all, and the static eval of that position (and thus the root score )would be insensitive to the Rook value.