I was using the PSQ tables from http://chessprogramming.wikispaces.com/ ... n+function. However, this exhaustive representation typically uses 2*6*64=768 parameters: 2 for opening/endgame, 6 for all the pieces, and 64 squares.
So I tried to reduce thie number of parameters as much a possible. Here's my code to generate all PSQ tables (for white)
static const int center[8] = {-10, -5, +0, +5, +5, +0, -5, -10};
// in percent of center[]
static const int pawn_file_op = 100;
static const int knight_center = 200;
static const int bishop_center = 50;
static const int queen_center_eg= 80;
static const int king_center_eg = 100;
static const int rook_file_op = 60;
static const int king_file_op = -400;
// multiplied by rank
static const int king_rank_op = -10;
// PSQ generation
for (int phase = Opening; phase <= EndGame; phase++)
for (int sq = A1; sq <= H8; sq++) {
const int r = rank(sq), f = file(sq);
if (phase == Opening) {
PSQTable[phase][Pawn][sq] = Material[phase][Pawn] + pawn_file_op*center[f]/100;
PSQTable[phase][Rook][sq] = Material[phase][Rook] + rook_file_op*center[f]/100;
PSQTable[phase][King][sq] = Material[phase][King] + king_rank_op*r
+ king_file_op*center[min(FileG,max(FileB,f))]/100; // HACK: A and H files are forced to the same values as B and G
} else {
PSQTable[phase][Queen][sq] = Material[phase][Queen] + queen_center_eg * (center[r] + center[f]) / 100;
PSQTable[phase][King][sq] = Material[phase][King] + king_center_eg * (center[r] + center[f]) / 100;
}
PSQTable[phase][Knight][sq] = Material[phase][Knight] + knight_center * (center[r] + center[f])/100;
PSQTable[phase][Bishop][sq] = Material[phase][Bishop] + bishop_center * (center[r] + center[f])/100;
}
Now that I've massively reduced the number of parameters, there is hope for a brute force optimisation. Has anyone managed to use CLOP+cutechess-cli to optimise eval parameters?
lucasart wrote:Now that I've massively reduced the number of parameters, there is hope for a brute force optimisation. Has anyone managed to use CLOP+cutechess-cli to optimise eval parameters?
There's a thread about it here: http://talkchess.com/forum/viewtopic.php?t=40687
I've done a couple of experiments optimizing Sloppy's eval weights. It definitely works - if you pick a few parameters to optimize and run some tens of thousands of games, the parameters will converge close to their optimal values. Remi mentioned that about 12 parameters is the practical limit that CLOP can optimize. My current experiment has 8 parameters, and it looks like it's going to take about 100,000 games until I get optimal results.
lucasart wrote:I was using the PSQ tables from http://chessprogramming.wikispaces.com/ ... n+function. However, this exhaustive representation typically uses 2*6*64=768 parameters: 2 for opening/endgame, 6 for all the pieces, and 64 squares.
So I tried to reduce thie number of parameters as much a possible. Here's my code to generate all PSQ tables (for white)
static const int center[8] = {-10, -5, +0, +5, +5, +0, -5, -10};
// in percent of center[]
static const int pawn_file_op = 100;
static const int knight_center = 200;
static const int bishop_center = 50;
static const int queen_center_eg= 80;
static const int king_center_eg = 100;
static const int rook_file_op = 60;
static const int king_file_op = -400;
// multiplied by rank
static const int king_rank_op = -10;
// PSQ generation
for (int phase = Opening; phase <= EndGame; phase++)
for (int sq = A1; sq <= H8; sq++) {
const int r = rank(sq), f = file(sq);
if (phase == Opening) {
PSQTable[phase][Pawn][sq] = Material[phase][Pawn] + pawn_file_op*center[f]/100;
PSQTable[phase][Rook][sq] = Material[phase][Rook] + rook_file_op*center[f]/100;
PSQTable[phase][King][sq] = Material[phase][King] + king_rank_op*r
+ king_file_op*center[min(FileG,max(FileB,f))]/100; // HACK: A and H files are forced to the same values as B and G
} else {
PSQTable[phase][Queen][sq] = Material[phase][Queen] + queen_center_eg * (center[r] + center[f]) / 100;
PSQTable[phase][King][sq] = Material[phase][King] + king_center_eg * (center[r] + center[f]) / 100;
}
PSQTable[phase][Knight][sq] = Material[phase][Knight] + knight_center * (center[r] + center[f])/100;
PSQTable[phase][Bishop][sq] = Material[phase][Bishop] + bishop_center * (center[r] + center[f])/100;
}
Now that I've massively reduced the number of parameters, there is hope for a brute force optimisation. Has anyone managed to use CLOP+cutechess-cli to optimise eval parameters?
Actually it is 12. The vector on top is symmetrical.
Another demonstration of how little information content is in the PSTs, in general.
Thank you. I'll have a look. So I'm planning to optimize
- the 8 weight parameters
- then the shape of the bomus, which is only 4 parameters as miguel pointed out (the center[] vector)
lucasart wrote:I was using the PSQ tables from http://chessprogramming.wikispaces.com/ ... n+function. However, this exhaustive representation typically uses 2*6*64=768 parameters: 2 for opening/endgame, 6 for all the pieces, and 64 squares.
So I tried to reduce thie number of parameters as much a possible. Here's my code to generate all PSQ tables (for white)
static const int center[8] = {-10, -5, +0, +5, +5, +0, -5, -10};
// in percent of center[]
static const int pawn_file_op = 100;
static const int knight_center = 200;
static const int bishop_center = 50;
static const int queen_center_eg= 80;
static const int king_center_eg = 100;
static const int rook_file_op = 60;
static const int king_file_op = -400;
// multiplied by rank
static const int king_rank_op = -10;
// PSQ generation
for (int phase = Opening; phase <= EndGame; phase++)
for (int sq = A1; sq <= H8; sq++) {
const int r = rank(sq), f = file(sq);
if (phase == Opening) {
PSQTable[phase][Pawn][sq] = Material[phase][Pawn] + pawn_file_op*center[f]/100;
PSQTable[phase][Rook][sq] = Material[phase][Rook] + rook_file_op*center[f]/100;
PSQTable[phase][King][sq] = Material[phase][King] + king_rank_op*r
+ king_file_op*center[min(FileG,max(FileB,f))]/100; // HACK: A and H files are forced to the same values as B and G
} else {
PSQTable[phase][Queen][sq] = Material[phase][Queen] + queen_center_eg * (center[r] + center[f]) / 100;
PSQTable[phase][King][sq] = Material[phase][King] + king_center_eg * (center[r] + center[f]) / 100;
}
PSQTable[phase][Knight][sq] = Material[phase][Knight] + knight_center * (center[r] + center[f])/100;
PSQTable[phase][Bishop][sq] = Material[phase][Bishop] + bishop_center * (center[r] + center[f])/100;
}
Now that I've massively reduced the number of parameters, there is hope for a brute force optimisation. Has anyone managed to use CLOP+cutechess-cli to optimise eval parameters?
Actually it is 12. The vector on top is symmetrical.
Another demonstration of how little information content is in the PSTs, in general.
lucasart wrote:I was using the PSQ tables from http://chessprogramming.wikispaces.com/ ... n+function. However, this exhaustive representation typically uses 2*6*64=768 parameters: 2 for opening/endgame, 6 for all the pieces, and 64 squares.
So I tried to reduce thie number of parameters as much a possible. Here's my code to generate all PSQ tables (for white)
static const int center[8] = {-10, -5, +0, +5, +5, +0, -5, -10};
// in percent of center[]
static const int pawn_file_op = 100;
static const int knight_center = 200;
static const int bishop_center = 50;
static const int queen_center_eg= 80;
static const int king_center_eg = 100;
static const int rook_file_op = 60;
static const int king_file_op = -400;
// multiplied by rank
static const int king_rank_op = -10;
// PSQ generation
for (int phase = Opening; phase <= EndGame; phase++)
for (int sq = A1; sq <= H8; sq++) {
const int r = rank(sq), f = file(sq);
if (phase == Opening) {
PSQTable[phase][Pawn][sq] = Material[phase][Pawn] + pawn_file_op*center[f]/100;
PSQTable[phase][Rook][sq] = Material[phase][Rook] + rook_file_op*center[f]/100;
PSQTable[phase][King][sq] = Material[phase][King] + king_rank_op*r
+ king_file_op*center[min(FileG,max(FileB,f))]/100; // HACK: A and H files are forced to the same values as B and G
} else {
PSQTable[phase][Queen][sq] = Material[phase][Queen] + queen_center_eg * (center[r] + center[f]) / 100;
PSQTable[phase][King][sq] = Material[phase][King] + king_center_eg * (center[r] + center[f]) / 100;
}
PSQTable[phase][Knight][sq] = Material[phase][Knight] + knight_center * (center[r] + center[f])/100;
PSQTable[phase][Bishop][sq] = Material[phase][Bishop] + bishop_center * (center[r] + center[f])/100;
}
Now that I've massively reduced the number of parameters, there is hope for a brute force optimisation. Has anyone managed to use CLOP+cutechess-cli to optimise eval parameters?
Actually it is 12. The vector on top is symmetrical.
Another demonstration of how little information content is in the PSTs, in general.
Miguel
In general, maybe. Certainly not for everybody...
Because not everybody does it automatically, which is this case.
lucasart wrote:I was using the PSQ tables from http://chessprogramming.wikispaces.com/ ... n+function. However, this exhaustive representation typically uses 2*6*64=768 parameters: 2 for opening/endgame, 6 for all the pieces, and 64 squares.
So I tried to reduce thie number of parameters as much a possible. Here's my code to generate all PSQ tables (for white)
static const int center[8] = {-10, -5, +0, +5, +5, +0, -5, -10};
// in percent of center[]
static const int pawn_file_op = 100;
static const int knight_center = 200;
static const int bishop_center = 50;
static const int queen_center_eg= 80;
static const int king_center_eg = 100;
static const int rook_file_op = 60;
static const int king_file_op = -400;
// multiplied by rank
static const int king_rank_op = -10;
// PSQ generation
for (int phase = Opening; phase <= EndGame; phase++)
for (int sq = A1; sq <= H8; sq++) {
const int r = rank(sq), f = file(sq);
if (phase == Opening) {
PSQTable[phase][Pawn][sq] = Material[phase][Pawn] + pawn_file_op*center[f]/100;
PSQTable[phase][Rook][sq] = Material[phase][Rook] + rook_file_op*center[f]/100;
PSQTable[phase][King][sq] = Material[phase][King] + king_rank_op*r
+ king_file_op*center[min(FileG,max(FileB,f))]/100; // HACK: A and H files are forced to the same values as B and G
} else {
PSQTable[phase][Queen][sq] = Material[phase][Queen] + queen_center_eg * (center[r] + center[f]) / 100;
PSQTable[phase][King][sq] = Material[phase][King] + king_center_eg * (center[r] + center[f]) / 100;
}
PSQTable[phase][Knight][sq] = Material[phase][Knight] + knight_center * (center[r] + center[f])/100;
PSQTable[phase][Bishop][sq] = Material[phase][Bishop] + bishop_center * (center[r] + center[f])/100;
}
Now that I've massively reduced the number of parameters, there is hope for a brute force optimisation. Has anyone managed to use CLOP+cutechess-cli to optimise eval parameters?
Actually it is 12. The vector on top is symmetrical.
Another demonstration of how little information content is in the PSTs, in general.
Miguel
In general, maybe. Certainly not for everybody...
Because not everybody does it automatically, which is this case.
Miguel
I simply said "not all PSTs are so simple." The reason is irrelevant.
lucasart wrote:I was using the PSQ tables from http://chessprogramming.wikispaces.com/ ... n+function. However, this exhaustive representation typically uses 2*6*64=768 parameters: 2 for opening/endgame, 6 for all the pieces, and 64 squares.
So I tried to reduce thie number of parameters as much a possible. Here's my code to generate all PSQ tables (for white)
static const int center[8] = {-10, -5, +0, +5, +5, +0, -5, -10};
// in percent of center[]
static const int pawn_file_op = 100;
static const int knight_center = 200;
static const int bishop_center = 50;
static const int queen_center_eg= 80;
static const int king_center_eg = 100;
static const int rook_file_op = 60;
static const int king_file_op = -400;
// multiplied by rank
static const int king_rank_op = -10;
// PSQ generation
for (int phase = Opening; phase <= EndGame; phase++)
for (int sq = A1; sq <= H8; sq++) {
const int r = rank(sq), f = file(sq);
if (phase == Opening) {
PSQTable[phase][Pawn][sq] = Material[phase][Pawn] + pawn_file_op*center[f]/100;
PSQTable[phase][Rook][sq] = Material[phase][Rook] + rook_file_op*center[f]/100;
PSQTable[phase][King][sq] = Material[phase][King] + king_rank_op*r
+ king_file_op*center[min(FileG,max(FileB,f))]/100; // HACK: A and H files are forced to the same values as B and G
} else {
PSQTable[phase][Queen][sq] = Material[phase][Queen] + queen_center_eg * (center[r] + center[f]) / 100;
PSQTable[phase][King][sq] = Material[phase][King] + king_center_eg * (center[r] + center[f]) / 100;
}
PSQTable[phase][Knight][sq] = Material[phase][Knight] + knight_center * (center[r] + center[f])/100;
PSQTable[phase][Bishop][sq] = Material[phase][Bishop] + bishop_center * (center[r] + center[f])/100;
}
Now that I've massively reduced the number of parameters, there is hope for a brute force optimisation. Has anyone managed to use CLOP+cutechess-cli to optimise eval parameters?
Actually it is 12. The vector on top is symmetrical.
Another demonstration of how little information content is in the PSTs, in general.
Miguel
In general, maybe. Certainly not for everybody...
Because not everybody does it automatically, which is this case.
Miguel
I simply said "not all PSTs are so simple." The reason is irrelevant.
That's why I'd recommend using some existing very strong proven values and optimize correction parameters.
lucasart wrote:I was using the PSQ tables from http://chessprogramming.wikispaces.com/ ... n+function. However, this exhaustive representation typically uses 2*6*64=768 parameters: 2 for opening/endgame, 6 for all the pieces, and 64 squares.
So I tried to reduce thie number of parameters as much a possible. Here's my code to generate all PSQ tables (for white)
static const int center[8] = {-10, -5, +0, +5, +5, +0, -5, -10};
// in percent of center[]
static const int pawn_file_op = 100;
static const int knight_center = 200;
static const int bishop_center = 50;
static const int queen_center_eg= 80;
static const int king_center_eg = 100;
static const int rook_file_op = 60;
static const int king_file_op = -400;
// multiplied by rank
static const int king_rank_op = -10;
// PSQ generation
for (int phase = Opening; phase <= EndGame; phase++)
for (int sq = A1; sq <= H8; sq++) {
const int r = rank(sq), f = file(sq);
if (phase == Opening) {
PSQTable[phase][Pawn][sq] = Material[phase][Pawn] + pawn_file_op*center[f]/100;
PSQTable[phase][Rook][sq] = Material[phase][Rook] + rook_file_op*center[f]/100;
PSQTable[phase][King][sq] = Material[phase][King] + king_rank_op*r
+ king_file_op*center[min(FileG,max(FileB,f))]/100; // HACK: A and H files are forced to the same values as B and G
} else {
PSQTable[phase][Queen][sq] = Material[phase][Queen] + queen_center_eg * (center[r] + center[f]) / 100;
PSQTable[phase][King][sq] = Material[phase][King] + king_center_eg * (center[r] + center[f]) / 100;
}
PSQTable[phase][Knight][sq] = Material[phase][Knight] + knight_center * (center[r] + center[f])/100;
PSQTable[phase][Bishop][sq] = Material[phase][Bishop] + bishop_center * (center[r] + center[f])/100;
}
Now that I've massively reduced the number of parameters, there is hope for a brute force optimisation. Has anyone managed to use CLOP+cutechess-cli to optimise eval parameters?
Actually it is 12. The vector on top is symmetrical.
Another demonstration of how little information content is in the PSTs, in general.
Miguel
It would be 11 if you don't count the 0 in center[]. One has to fixate one element otherwise you overdetermine the vector space (or you can alternatively stuff the piece value in there like SF does).
There is indeed not always a great deal of information in such tables, but much more than the 12 numbers you suggest. There is also information content in the structure of the formula. Why for example reuse center[] and not have center[8] for files and rank[8] for ranks. That nicely deals with rook on 7th and knight on 6th type of knowledge. Why reuse the ramping arrays at all between different pieces and differentiate with a multiplier, when you can give each piece its own ramping. That nicely gets rid of the 'hack' for the king. Why not let the ramping values depend on which flank the kings are. Why construct the bishop PST using a rank/file coordinate system instead of diagonal coordinates? There are countless more variations possible in these tables and they all add to the information content. In my current program for example there are 111 parameters for PSTs that are automatically tuned.
michiguel wrote:
Actually it is 12. The vector on top is symmetrical.
It would be 11 if you don't count the 0 in center[].
I now realize it is 10, since the multiplication of center[] with other tunable parameters introduces extra redundancy. (You can fixate 2 numbers from center[] because of this, one must be zero, leaving only 2 others free.)
