Learning piece-square table

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
mathmoi
Posts: 267
Joined: Mon Mar 13, 2006 4:23 pm
Location: Québec
Contact:

Re: Learning piece-square table

Post by mathmoi » Wed Feb 14, 2018 2:15 am

jorose wrote: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.

User avatar
Evert
Posts: 2929
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: Learning piece-square table

Post by Evert » Wed Feb 14, 2018 6:10 am

mathmoi wrote:
jorose wrote: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
Posts: 300
Joined: Thu Jan 22, 2015 2:21 pm
Location: Zurich, Switzerland
Full name: Jonathan Rosenthal

Re: Learning piece-square table

Post by jorose » Wed Feb 14, 2018 11:43 am

Dann Corbit wrote: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.

Post Reply