Pawn-contextual piece square tables

[j.t.]

With Pawn-contextual PSTs you have for each pawn position a PST for knight, bishop, rook, and queen (and king if you don't have king-contextual PSTs). Such a table could look like this:

Code: Select all

array[a1..h8, array[knight..queen, array[a1..h8, Value]]] # The first square index is for the pawn, and the last one for the square of the piece

And since the position of a piece relative to a pawn could mean wildly different things depending on if that is our pawn or not, we will use two such tables, one for enemy pawns, and one for our own pawns.

In the evaluation, this then will look like this:
For each pawn we will loop over all our pieces (knights, bishops, rooks, queens) and add the according entry in the pawn-contextual PST (we choose the right one, depending on if the pawn is ours or not) to the evaluation value.

In Nalwald this gave me a pretty huge improvement (50–100 Elo in selfplay), even though NPS went down by at least 10%.

[lithander]

Thanks for the explanation! Interesting idea!

[Witek]

I tried something similar before I switched to NNUE - I had additional pawn-pawn pair tables. So it was 48x48x2 values. It gave around +80 Elo.

[j.t.]

I tried something similar before I switched to NNUE - I had additional pawn-pawn pair tables. So it was 48x48x2 values. It gave around +80 Elo.

Mmh, that's impressive. I thought that that would be too expensive, looping over all the pawns twice. I probably should've tried that, too. Well doesn't matter, I'm gonna do it now.

[Witek]

I tried something similar before I switched to NNUE - I had additional pawn-pawn pair tables. So it was 48x48x2 values. It gave around +80 Elo.

Mmh, that's impressive. I thought that that would be too expensive, looping over all the pawns twice. I probably should've tried that, too. Well doesn't matter, I'm gonna do it now.

Indeed looping over all the pawns twice was expensive, but the computed term was cached in pawn hash table.

[j.t.]

Indeed looping over all the pawns twice was expensive, but the computed term was cached in pawn hash table.

That may explain to some extent why it didn't work for me.

[hgm]

Pawn structure is known to be very important in Chess, and judging how well other pieces are placed relative to the Pawn structure is the most natural thing to do. So why not put a separate set of PST for, say, Q, R, B and N for each possible Pawn structure in the Pawn hash? That is only 256 extra bytes per entry, and should not be a problem with today's memory and cache sizes. You can use an advanced algorithm for filling the PST when you encounter a new Pawn structure, as the table will have a quite large hit rate. And Pawn moves are not that frequent in the tree, so that you would have to recalculate the PST evaluation from scratch when a Pawn moves is also bearable.

[lithander]

So why not put a separate set of PST for, say, Q, R, B and N for each possible Pawn structure in the Pawn hash? That is only 256 extra bytes per entry, and should not be a problem with today's memory and cache sizes.

The challenge probably is to find good values for all these special-case PSTs.

How would you "tune" values without overfitting just a moderate amount of labeled positions? E.g. the popular Zurichess set has only 725k positions. I have 2.8M positions right now.

[lithander]

My grammar makes no sense. What I mean: Some pawn structures are very exotic. That means only few positions in the training data set will have that specific pawn structure. But to tune PSTs you need many thousands of labeled positions so that all piece-types have been on all of the 64 squares often enough so that gradient descent converges to something generally true instead of just overfitting the data.

I work on king-relativity right now and I already saw (literally, as I visualized my PSTs) a lot of noise in the tables tuned for the more exotic king squares.

[hgm]

Use a hand-crafted algorithm for calculating the PST values with many adaptable parameters, and then tune the parameters. Or look at subsets of the Pawn structure in the area where the piece moves would intersect them to reduce the number of patterns you have to score.