Pawn structure tuning

[xr_a_y]

For a long time now I have this "todo" inside Minic code

Code: Select all

///@todo make this depends on file! (/rank?)
extern CONST_TEXEL_TUNING EvalScore   doublePawnMalus[2]     ;
extern CONST_TEXEL_TUNING EvalScore   isolatedPawnMalus[2]   ;
extern CONST_TEXEL_TUNING EvalScore   backwardPawnMalus[2]   ;

And this recent Alayan commit in Ethereal made me finally try it (https://github.com/AndyGrant/Ethereal/c ... 993843ddc0).

But in fact I wonder if I cannot try a full 64 entry (x2 MG/EG, and x2 semi-open file or not) PST for backward, isolated and doubled pawn.
Because not only rank matters, file also.

Will I have enough tuning samples to optimize this 256x3 new coefficients ??

Another question is, does someone already try to mix zurichess data and the so called lichess-quiet data in order to get a bigger sample size ?

[AndrewGrant]

I would stray from trying a full array setup. I always prefer the minimal approach. If a full array passes testing in the same number of games as only adding an additional dimension for X, you clearly prefer the simpler approach. The limited data is of course prohibitive, but I also feel a sort of arrogance in the engine having a different value for every square. As if my engine is so good that it needs to have a special value for EVERY possible combination.

I do have a larger tuning set, which is a combination of Zurichess, an old Laser set, and about 4m Ethereal positions. In total, its about 7m positions, and also has a depth 10 search eval from Ethereal .... (11.4X). Send me a message on discord or somewhere else if you want a link. I try to keep that dataset somewhat private. Which I think is fair, seeing as my entire dev process is on the internet.

[Fabio Gobbato]

If I can ask, how do you compare the 10 depth search eval from Ethereal with its static evaluation? The two evals can differ a lot.

[AndrewGrant]

If I can ask, how do you compare the 10 depth search eval from Ethereal with its static evaluation? The two evals can differ a lot.

The goal, which may or may not be founded, is to adjust positions where the search() differs greatly from the eval(). Namely, imagine a position where we have taken a pawn with our queen, gaining an advantage. The eval() will give us a positive result. Now suppose that there is a short, but non obvious line of play such that our opponent takes our queen in trade for that pawn. search() will return a very negative score.

Now, if we use (eval() + search()) / 2 as our "real" eval for the tuning process, the tuner will not have to try too hard to make the "real" eval indicate a loss. If we are +100cp, but the position is actually losing, the tuner will try hard and generate a lot of noise trying to adjust that position to have a more "correct" eval. With this addition, that no longer occurs.

Note the "may or may not be founded". I liked the idea when I thought of it. It was cheeky. And It continues to show some use in gaining elo on patches, even with the evals coming from a much older version of Ethereal. However, it has setbacks.