Push a patch

[Lyudmil Tsvetkov]

Lyudmil, do you wish a single patch to tune the pieces values+psqt tables?
Or 1 patch for the pieces values + 1 patch for the psqt, etc?
I ask this because Joerg is currently trying your values for the piece values but nothing about your psqt values for king middle game nor rook middle game-end game.

Hi Isaak.

Thanks for asking.

Of course, I would like separate patches for the rook psqt and the king psqt.

I would appreciate it very much, if you could push one of those, as volunteers nowadays seem to be a rare phenomenon.

But please, if you do so, do not mention my name.

[lantonov]

And here my long-thought rook psqt values.

I made non-flat both the mg and eg values, hopefully this passes.

S(-10, -10), S(-7, -7), S(-2, -2), S(0, 0), S(0, 0), S(-2, -2), S(-7, -7), S(-10, -10),
S(-7, -9), S( -4, -6), S(-1, -1), S(3, 3), S(3, 3), S(-1, -1), S( -4, -6), S(-7, -9),
S(0, -7), S( 3, -5), S( 6, 1), S(8, 4), S(8, 4), S( 6, 1), S( 3, -5), S(0, -7),
S(-5, -5), S( -1, -1), S( 2, 2), S(5, 5), S(5, 5), S( 2, 2), S( -1, -1), S(-5, -5),
S(-3, -3), S( 2, 2), S( 4, 4), S(6, 6), S(6, 6), S( 4, 4), S( 2, 2), S(-3, -3),
S( 0, 0), S( 3, 3), S( 6, 6), S(8, 8), S(8, 8), S( 6, 6), S( 3, 3), S( 0, 0),
S( 3, 3), S( 7, 7), S( 11, 11), S(15,15), S(15,15), S( 11, 11), S( 7, 7), S( 3, 3),
S( 1, 1), S( 5, 5), S( 9, 9), S(13, 13), S(13, 13), S( 9, 9), S( 5, 5), S( 1, 1)

So far not a single patch has passed when I wanted it to be so, but just occasionally, maybe this will be the first one.

Lyudmil, are you still around?

I still look in Talkchess from time to time albeit less often than before. Without your presence, this forum moved to the duller side (no emoticon because I am serious).

I have not given up pushing patches, quite the opposite, I look for good ideas. I will try to push all of the patches that you propose, since I am sure that those arise from experience and sound reasoning.

After the SPSA test with the rook psqt, I became disappointed with the slow convergence of SPSA and looked for other ways to tune psqts. I pushed 32 tests for rook psqt a and h files (2000 games each) to see what kinds of effects are at play here. It turned out that the picture is quite complicated with many interactions and second-order effects in addition to the usual first-order effects. These results are described in more detail in https://groups.google.com/d/topic/fishc ... discussion.

It is difficult to optimise the psqts with the usual DoE methods (steepest gradient descent and ridge regression) because of the many parameters to tune -- each value is a parameter. I looked for methods that tune many parameters more efficiently than SPSA, and one of those, ROCK*, attracted my attention. It is able to tune as many as 500 parameters in less than 1000 iterations, using Gaussian kernel regression.

Unfortunately, the implementations of ROCK* (in Matlab and C++) are only for robotics, and adapting these algorithms to chess will be difficult with my very feeble (almost non-existing) programming skills. My professional field is statistics, and I am doing only my first steps in programming.

In the moment I am trying to translate the SPSA program which is written in Perl by Joona into Python because the math programming in Python is closer to what I know from Matlab and Mathematica. This first step would be the more difficult one. Substituting the SPSA calculations with ROCK* ones will be easier.

I was able to lend my computer to Fishtest which is too low in resources these days. I am waiting to finish 1000 games and go to bed in the next 15 min or so. I will try to push your patches tomorrow.

[Lyudmil Tsvetkov]

And here my long-thought rook psqt values.

I made non-flat both the mg and eg values, hopefully this passes.

S(-10, -10), S(-7, -7), S(-2, -2), S(0, 0), S(0, 0), S(-2, -2), S(-7, -7), S(-10, -10),
S(-7, -9), S( -4, -6), S(-1, -1), S(3, 3), S(3, 3), S(-1, -1), S( -4, -6), S(-7, -9),
S(0, -7), S( 3, -5), S( 6, 1), S(8, 4), S(8, 4), S( 6, 1), S( 3, -5), S(0, -7),
S(-5, -5), S( -1, -1), S( 2, 2), S(5, 5), S(5, 5), S( 2, 2), S( -1, -1), S(-5, -5),
S(-3, -3), S( 2, 2), S( 4, 4), S(6, 6), S(6, 6), S( 4, 4), S( 2, 2), S(-3, -3),
S( 0, 0), S( 3, 3), S( 6, 6), S(8, 8), S(8, 8), S( 6, 6), S( 3, 3), S( 0, 0),
S( 3, 3), S( 7, 7), S( 11, 11), S(15,15), S(15,15), S( 11, 11), S( 7, 7), S( 3, 3),
S( 1, 1), S( 5, 5), S( 9, 9), S(13, 13), S(13, 13), S( 9, 9), S( 5, 5), S( 1, 1)

So far not a single patch has passed when I wanted it to be so, but just occasionally, maybe this will be the first one.

Lyudmil, are you still around?

I still look in Talkchess from time to time albeit less often than before. Without your presence, this forum moved to the duller side (no emoticon because I am serious).

I have not given up pushing patches, quite the opposite, I look for good ideas. I will try to push all of the patches that you propose, since I am sure that those arise from experience and sound reasoning.

After the SPSA test with the rook psqt, I became disappointed with the slow convergence of SPSA and looked for other ways to tune psqts. I pushed 32 tests for rook psqt a and h files (2000 games each) to see what kinds of effects are at play here. It turned out that the picture is quite complicated with many interactions and second-order effects in addition to the usual first-order effects. These results are described in more detail in https://groups.google.com/d/topic/fishc ... discussion.

It is difficult to optimise the psqts with the usual DoE methods (steepest gradient descent and ridge regression) because of the many parameters to tune -- each value is a parameter. I looked for methods that tune many parameters more efficiently than SPSA, and one of those, ROCK*, attracted my attention. It is able to tune as many as 500 parameters in less than 1000 iterations, using Gaussian kernel regression.

Unfortunately, the implementations of ROCK* (in Matlab and C++) are only for robotics, and adapting these algorithms to chess will be difficult with my very feeble (almost non-existing) programming skills. My professional field is statistics, and I am doing only my first steps in programming.

In the moment I am trying to translate the SPSA program which is written in Perl by Joona into Python because the math programming in Python is closer to what I know from Matlab and Mathematica. This first step would be the more difficult one. Substituting the SPSA calculations with ROCK* ones will be easier.

I was able to lend my computer to Fishtest which is too low in resources these days. I am waiting to finish 1000 games and go to bed in the next 15 min or so. I will try to push your patches tomorrow.

Many thanks Lyudmil.

I am glad you contribute to SF framework after Velislav left.

Joerg already pushed the piece values patch, so if you are able to push just the rook psqt, I would be very grateful.

Then, maybe Isaac will push the king psqt, we will see later.
But please, do not mention my name.

Many thanks again!

[Lyudmil Tsvetkov]

Now, the most salient SF problem currently is the very badly tuned bonus for storming pawns on the 4th rank.

Sf definitely needs to increase the bonus for the 4th rank, maybe by at least 10%. SF is so bad at starting pushing forward its storming pawns to the 3rd and 4th ranks, that it generally misses every 3 out of 4 existing oportunities to do so. This frequently also leads to early draws, or undesired losses.

So, from white's perspective, storming pawns on f4,g4,h4 are due larger bonus, but also storming pawns on f3,g3,h3, if considered by SF, are also due a bit larger value.
The most significant problem however are storming pawns on the 4th rank.

Now, SF recently tuned its king safety, including the storming pawns bonus, but that has affected mainly the distinction in terms of files. Also, quite probably increasing the bonus for some storming pawns on the 6th and 5th ranks might have lead to insufficient bonus for storming pawns on the 4th rank.

As said, this is vital, and costs SF a lot of elo.

If I were someone of the SF team, I would simply increase the bonus for the 4th rank ad-hoc, manually, by some 10%, but maybe this task could even be entrusted to SPSA or some other tuner with proper indications.

In any case, bonus for the 4th rank should be urgently increased.

I am not quite certain if this does not have some bearing also on pawn shelter, quite probably so, Lucas recently tried to tune pawn shelter, in any case, either the pawn shelter penalties, or the storming pawns bonus for the 3rd and 4th ranks should be changed.

With more advanced ranks, I already do not notice obvious problems as in the past, although in a very wide range of closed and semi-closed positions SF is still very reluctant to advance with storming pawns even on the 5th rank.

[Lyudmil Tsvetkov]

[d]6k1/8/8/8/5P2/8/6PP/6K1 w - - 0 1

f4 is due higher bonus above

pushing white g2 pawn to g3 and g4 is due higher bonus, and also pushing white h2 pawn to h3 and h4.

SF sees such pushes, but only in specific positions, when such pawns attack something, create chain pawns, etc. Otherwise, it simply neglects such pushes.

Again, stroming pawns are a very major feature and extremely elo-sensitive, so this should be urgently addressed, I think.

[Lyudmil Tsvetkov]

Again, everyone knows SF draws too many games very early on.

Once I thought the main reason is eval, and that is partly true, but actually now understand the main reason is not eval, but search.

Good, calibrated eval would of course decrease the draw percentage, as more positions would be considered with different scores, but the main reason for the high SF draw rate is its search, being very selective, meaning a lot of good and reasonable lines are pruned early on, or do not reach sufficient depth, meaning the engine has fewer options at its disposal to find and pick up moves that avoid the draw outcome.

Quite often I observe the following with SF: SF goes for the 3-fold very early on in the mg, you show it a different move, it searches a bit and agrees this is already not a draw, but actually a better move. Then you repeat the same thing again: SF goes for the 3-fold, you show it a different move, and after a short while the engine agrees this does not lead to a draw, but is instead the better move.

And so on, and so forth, you might repeat this endlessly.

So, it is mainly search that increases SF draw rate, very selective SF search, preventing it to look at a wider range of move/line options.

Whether this could be fixed in a reasonable way without breaking the whole search, I have absolutely no clue, maybe this is just an unavoidable selective search consequence. People much wiser than me in search questions and SF idiosyncracies might advise, and even suggest a solution, I just felt the need to share my observations.

Any clue how SF draw rate could be lowered in a natural way, without contempt, while keeping the selectivity of the search and with current eval?

[Lyudmil Tsvetkov]

Just to add that such early search draws are actually much more frequent than I thought before, maybe 3 out of every 4 draws in the mg, less conspicuous in the eg.

So only about 1 out of every 4 early draws is due to unavoidable forced lines.

Is it possible to widen the tree, when a 0.0 score is reached early on?

[Joerg Oster]

Again, everyone knows SF draws too many games very early on.

Once I thought the main reason is eval, and that is partly true, but actually now understand the main reason is not eval, but search.

Good, calibrated eval would of course decrease the draw percentage, as more positions would be considered with different scores, but the main reason for the high SF draw rate is its search, being very selective, meaning a lot of good and reasonable lines are pruned early on, or do not reach sufficient depth, meaning the engine has fewer options at its disposal to find and pick up moves that avoid the draw outcome.

Quite often I observe the following with SF: SF goes for the 3-fold very early on in the mg, you show it a different move, it searches a bit and agrees this is already not a draw, but actually a better move. Then you repeat the same thing again: SF goes for the 3-fold, you show it a different move, and after a short while the engine agrees this does not lead to a draw, but is instead the better move.

And so on, and so forth, you might repeat this endlessly.

So, it is mainly search that increases SF draw rate, very selective SF search, preventing it to look at a wider range of move/line options.

Whether this could be fixed in a reasonable way without breaking the whole search, I have absolutely no clue, maybe this is just an unavoidable selective search consequence. People much wiser than me in search questions and SF idiosyncracies might advise, and even suggest a solution, I just felt the need to share my observations.

Any clue how SF draw rate could be lowered in a natural way, without contempt, while keeping the selectivity of the search and with current eval?

This has been addressed by me with following patch:

https://github.com/joergoster/Stockfish ... d1fec0e551

It's of course nothing else than a dynamic form of contempt, but it lowered the draw rate of those early draws by repetition significantly, without affecting playing strength.
Unfortunately, it has been dismissed very quickly because it showed no elo gain. Which was never been advertized by me to do so!

[Lyudmil Tsvetkov]

Again, everyone knows SF draws too many games very early on.

Once I thought the main reason is eval, and that is partly true, but actually now understand the main reason is not eval, but search.

Good, calibrated eval would of course decrease the draw percentage, as more positions would be considered with different scores, but the main reason for the high SF draw rate is its search, being very selective, meaning a lot of good and reasonable lines are pruned early on, or do not reach sufficient depth, meaning the engine has fewer options at its disposal to find and pick up moves that avoid the draw outcome.

Quite often I observe the following with SF: SF goes for the 3-fold very early on in the mg, you show it a different move, it searches a bit and agrees this is already not a draw, but actually a better move. Then you repeat the same thing again: SF goes for the 3-fold, you show it a different move, and after a short while the engine agrees this does not lead to a draw, but is instead the better move.

And so on, and so forth, you might repeat this endlessly.

So, it is mainly search that increases SF draw rate, very selective SF search, preventing it to look at a wider range of move/line options.

Whether this could be fixed in a reasonable way without breaking the whole search, I have absolutely no clue, maybe this is just an unavoidable selective search consequence. People much wiser than me in search questions and SF idiosyncracies might advise, and even suggest a solution, I just felt the need to share my observations.

Any clue how SF draw rate could be lowered in a natural way, without contempt, while keeping the selectivity of the search and with current eval?

This has been addressed by me with following patch:

https://github.com/joergoster/Stockfish ... d1fec0e551

It's of course nothing else than a dynamic form of contempt, but it lowered the draw rate of those early draws by repetition significantly, without affecting playing strength.
Unfortunately, it has been dismissed very quickly because it showed no elo gain. Which was never been advertized by me to do so!

Joerg, is it possible to widen the tree somehow, when a 0.0 score is reached in search. Only in that case?

This will involve no contempt, but will avoid a fair portion of early draws, might even gain some elo?

Sorry for being so obtuse, you know I am a non-specialist.

[cdani]

Joerg, is it possible to widen the tree somehow, when a 0.0 score is reached in search. Only in that case?

I have done this on Andscacs long ago, and it was good. Of course the testing field was a gauntlet of different opponents, not selftest.