Learning piece-square table

[Kotlov]

In my engine, I use only two tunable parameters for centralization tables.

part of my code:

Code: Select all

for(i=64;i--;)
        {
            x=3.5-i/8;
            y=3.5-i%8;
            knight_pst[i]=100-sqrt(x*x+y*y)*42;
            king_end_game_pst[i]=160-sqrt(x*x+y*y)*60;
        }

[Dann Corbit]

I have found from empirical studies that none of the piece square tables should be perfectly symmetrical.

[AlvaroBegue]

I have found from empirical studies that none of the piece square tables should be perfectly symmetrical.

Not even the ones for pawnless endgames?

[Dann Corbit]

I have found from empirical studies that none of the piece square tables should be perfectly symmetrical.

Not even the ones for pawnless endgames?

None of them. But they are derived from collections of a few hundred thousand computer games + correspondence GMs and not derived from first principles. I only studied what performed well, and did not try to derive anything from first principles.

My friend Les Fernandez made a tool that creates something like baseball heat maps for pitching. I can divide it into piece type, color to move and layers of depth from the start.

I actually did not spend nearly so much time in the endgame since TBs decide the game by that point, so it would not surprise me if KRR krr was perfectly symmetrical for rook placement, for instance.

[Robert Pope]

I have found from empirical studies that none of the piece square tables should be perfectly symmetrical.

Not even the ones for pawnless endgames?

Do you have pawnless endgame-specific piece square tables?

[AlvaroBegue]

I have found from empirical studies that none of the piece square tables should be perfectly symmetrical.

Not even the ones for pawnless endgames?

Do you have pawnless endgame-specific piece square tables?

I did in some versions of my old Ruy-López, precisely because I couldn't justify any asymmetries in that case.

[mathmoi]

Trying to reinvent the wheel?

I'm not sure I understand...

[mathmoi]

I am not sure what the current standard way to approach this is. In Winter I only use PSTs for knight and king position evaluations. I assume the board is completely symmetric with respect to rotation and reflection, which is not actually the case due to pawns as well as castling rules. Under this assumption you can take a look at the a1-d4 diagonal as well as the squares below that. Every other square on the board can be reached by some combination of rotations and reflections from these squares. This gives just 10 values per piece so you should be working with the much more manageable number of 50 for non pawn pieces.

In Winter I have the following array which saves the transformation:

Code: Select all

const int kPSTindex[64] = {
    0, 1, 2, 3, 3, 2, 1, 0,
    1, 4, 5, 6, 6, 5, 4, 1,
    2, 5, 7, 8, 8, 7, 5, 2,
    3, 6, 8, 9, 9, 8, 6, 3,
    3, 6, 8, 9, 9, 8, 6, 3,
    2, 5, 7, 8, 8, 7, 5, 2,
    1, 4, 5, 6, 6, 5, 4, 1,
    0, 1, 2, 3, 3, 2, 1, 0
};

For pawns you could have a bonus for each file (so 4 values utilizing symmetry) and for how advanced the pawn is (another 6 values) which should also give you 10 parameters for pawns. In total this would give you 60 parameters for PSTs of the pieces and pawns.

In Winter I don't do that for pawns at all, instead I just give pawns a constant base value (not dependent on where they are) and passed pawns a bonus based on how far advanced they are.

I like the idea of using the a1-d1-d4 triangle to represent the whole board. I will probably use that instead of my center/corners zones. However, I feel that if used exclusively there is some "features" that it could not express because they are not symetric. Rook on 7th is an example.

[Evert]

I am not sure what the current standard way to approach this is. In Winter I only use PSTs for knight and king position evaluations. I assume the board is completely symmetric with respect to rotation and reflection, which is not actually the case due to pawns as well as castling rules. Under this assumption you can take a look at the a1-d4 diagonal as well as the squares below that. Every other square on the board can be reached by some combination of rotations and reflections from these squares. This gives just 10 values per piece so you should be working with the much more manageable number of 50 for non pawn pieces.

In Winter I have the following array which saves the transformation:

Code: Select all

const int kPSTindex[64] = {
    0, 1, 2, 3, 3, 2, 1, 0,
    1, 4, 5, 6, 6, 5, 4, 1,
    2, 5, 7, 8, 8, 7, 5, 2,
    3, 6, 8, 9, 9, 8, 6, 3,
    3, 6, 8, 9, 9, 8, 6, 3,
    2, 5, 7, 8, 8, 7, 5, 2,
    1, 4, 5, 6, 6, 5, 4, 1,
    0, 1, 2, 3, 3, 2, 1, 0
};

For pawns you could have a bonus for each file (so 4 values utilizing symmetry) and for how advanced the pawn is (another 6 values) which should also give you 10 parameters for pawns. In total this would give you 60 parameters for PSTs of the pieces and pawns.

In Winter I don't do that for pawns at all, instead I just give pawns a constant base value (not dependent on where they are) and passed pawns a bonus based on how far advanced they are.

I like the idea of using the a1-d1-d4 triangle to represent the whole board. I will probably use that instead of my center/corners zones. However, I feel that if used exclusively there is some "features" that it could not express because they are not symetric. Rook on 7th is an example.

Rook on the 7th is not really a PST term though, it is situational depending on the base of the enemy pawn structure and the location of the king.

As a first order term, the symmetry is fine, but the symmetry is broken by the way pawns move and the location of the kings. It's good to have those as additional terms.

[jorose]

I have found from empirical studies that none of the piece square tables should be perfectly symmetrical.

I guess to a degree the question is why you use PSTs. To me it is to encode information about a piece's value based on its position, which is independent of any other direct piece influence. On an empty board non pawn piece values are trivially symmetric with respect to rotation and reflection, thus any asymmetry in those values is encoding further information which may certainly improve strength in the short run. I worry that doing so however may hide missing features, which might be better encoded in some other way, as well as there being a price to having a greater number of features, so I am not sure it is wise to rely on an asymmetric (at least left right) PST encoding in the long run.