Learning piece-square table

[mathmoi]

Hi,

I'm rewriting my (a new) chess engine from scratch and I'm about to write a basic evaluation function that would at first only consists of material and piece-square table (psqt). For now I'm not gonna do any learning I'm just gonna chooses values that seems sensibles to me, but eventually I'm gonna want to do some automated learning. I'm trying to design my psqt with this in mind.

A psqt traditionally contains 64 (squares) x 6 (pieces) x 2 (phases) -16 (unreachables squares by pawns) = 752 individuals values. This of course is a challenge to learn in an automated way.

To reduce the number of learning parameters I though I would divide the board in a series of overlapping zones and that for each zones I would choose (and later machine-learn) a bonus or a malus to apply to all squares for that zone. This in theory would allow the machine learning algorithm to have less parameters to optimize. I'm guessing this idea isn't new and everyone is doing something like this, but I could not find any reference to this here or on the Chess Programming Wiki.

For my first try I choses the following zones :

• Each row (8);
  Each column (8);
  The center squares;
  The squares off the center;
  The squares off off the center;
  The corners squares;
  The squares off the corners.

This gave me 17 parameters per piece or 204 parameters to learn. This is still a lot I guess, but should be more manageable than 752. However it got more difficult to hand pick values because modifying one weight has effect on multiple squares.

Is this something that is usually done to learn piece-squares tables or do you just learn each squares values independently? If you do something like this what zones do you define?

Thanks.

[Kotlov]

Trying to reinvent the wheel?

[jorose]

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.

[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...