generate all PSQ tables with 16 numbers

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Post Reply
User avatar
lucasart
Posts: 2953
Joined: Mon May 31, 2010 11:29 am
Contact:

generate all PSQ tables with 16 numbers

Post by lucasart » Fri Oct 14, 2011 5:22 pm

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)

Code: Select all

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 &#40;int phase = Opening; phase <= EndGame; phase++)
	for &#40;int sq = A1; sq <= H8; sq++) &#123;
		const int r = rank&#40;sq&#41;, f = file&#40;sq&#41;;
		
		if &#40;phase == Opening&#41; &#123;
			PSQTable&#91;phase&#93;&#91;Pawn&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Pawn&#93; + pawn_file_op*center&#91;f&#93;/100;
			PSQTable&#91;phase&#93;&#91;Rook&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Rook&#93; + rook_file_op*center&#91;f&#93;/100;
			PSQTable&#91;phase&#93;&#91;King&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;King&#93; + king_rank_op*r
				+ king_file_op*center&#91;min&#40;FileG,max&#40;FileB,f&#41;)&#93;/100;		// HACK&#58; A and H files are forced to the same values as B and G
		&#125; else &#123;
			PSQTable&#91;phase&#93;&#91;Queen&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Queen&#93; + queen_center_eg * &#40;center&#91;r&#93; + center&#91;f&#93;) / 100;
			PSQTable&#91;phase&#93;&#91;King&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;King&#93; + king_center_eg * &#40;center&#91;r&#93; + center&#91;f&#93;) / 100;
		&#125;
		
		PSQTable&#91;phase&#93;&#91;Knight&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Knight&#93; + knight_center * &#40;center&#91;r&#93; + center&#91;f&#93;)/100;
		PSQTable&#91;phase&#93;&#91;Bishop&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Bishop&#93; + bishop_center * &#40;center&#91;r&#93; + center&#91;f&#93;)/100;
	&#125;
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?

User avatar
ilari
Posts: 748
Joined: Mon Mar 27, 2006 5:45 pm
Location: Finland
Contact:

Re: generate all PSQ tables with 16 numbers

Post by ilari » Fri Oct 14, 2011 6:25 pm

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.

User avatar
michiguel
Posts: 6242
Joined: Thu Mar 09, 2006 7:30 pm
Location: Chicago, Illinois, USA
Contact:

Re: generate all PSQ tables with 16 numbers

Post by michiguel » Fri Oct 14, 2011 6:27 pm

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)

Code: Select all

static const int center&#91;8&#93;		= &#123;-10,  -5,  +0,  +5,  +5,  +0,  -5, -10&#125;;
// in percent of center&#91;&#93;
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 &#40;int phase = Opening; phase <= EndGame; phase++)
	for &#40;int sq = A1; sq <= H8; sq++) &#123;
		const int r = rank&#40;sq&#41;, f = file&#40;sq&#41;;
		
		if &#40;phase == Opening&#41; &#123;
			PSQTable&#91;phase&#93;&#91;Pawn&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Pawn&#93; + pawn_file_op*center&#91;f&#93;/100;
			PSQTable&#91;phase&#93;&#91;Rook&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Rook&#93; + rook_file_op*center&#91;f&#93;/100;
			PSQTable&#91;phase&#93;&#91;King&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;King&#93; + king_rank_op*r
				+ king_file_op*center&#91;min&#40;FileG,max&#40;FileB,f&#41;)&#93;/100;		// HACK&#58; A and H files are forced to the same values as B and G
		&#125; else &#123;
			PSQTable&#91;phase&#93;&#91;Queen&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Queen&#93; + queen_center_eg * &#40;center&#91;r&#93; + center&#91;f&#93;) / 100;
			PSQTable&#91;phase&#93;&#91;King&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;King&#93; + king_center_eg * &#40;center&#91;r&#93; + center&#91;f&#93;) / 100;
		&#125;
		
		PSQTable&#91;phase&#93;&#91;Knight&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Knight&#93; + knight_center * &#40;center&#91;r&#93; + center&#91;f&#93;)/100;
		PSQTable&#91;phase&#93;&#91;Bishop&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Bishop&#93; + bishop_center * &#40;center&#91;r&#93; + center&#91;f&#93;)/100;
	&#125;
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

User avatar
lucasart
Posts: 2953
Joined: Mon May 31, 2010 11:29 am
Contact:

Re: generate all PSQ tables with 16 numbers

Post by lucasart » Fri Oct 14, 2011 6:29 pm

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)

bob
Posts: 20340
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: generate all PSQ tables with 16 numbers

Post by bob » Sat Oct 15, 2011 2:52 am

michiguel wrote:
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)

Code: Select all

static const int center&#91;8&#93;		= &#123;-10,  -5,  +0,  +5,  +5,  +0,  -5, -10&#125;;
// in percent of center&#91;&#93;
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 &#40;int phase = Opening; phase <= EndGame; phase++)
	for &#40;int sq = A1; sq <= H8; sq++) &#123;
		const int r = rank&#40;sq&#41;, f = file&#40;sq&#41;;
		
		if &#40;phase == Opening&#41; &#123;
			PSQTable&#91;phase&#93;&#91;Pawn&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Pawn&#93; + pawn_file_op*center&#91;f&#93;/100;
			PSQTable&#91;phase&#93;&#91;Rook&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Rook&#93; + rook_file_op*center&#91;f&#93;/100;
			PSQTable&#91;phase&#93;&#91;King&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;King&#93; + king_rank_op*r
				+ king_file_op*center&#91;min&#40;FileG,max&#40;FileB,f&#41;)&#93;/100;		// HACK&#58; A and H files are forced to the same values as B and G
		&#125; else &#123;
			PSQTable&#91;phase&#93;&#91;Queen&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Queen&#93; + queen_center_eg * &#40;center&#91;r&#93; + center&#91;f&#93;) / 100;
			PSQTable&#91;phase&#93;&#91;King&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;King&#93; + king_center_eg * &#40;center&#91;r&#93; + center&#91;f&#93;) / 100;
		&#125;
		
		PSQTable&#91;phase&#93;&#91;Knight&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Knight&#93; + knight_center * &#40;center&#91;r&#93; + center&#91;f&#93;)/100;
		PSQTable&#91;phase&#93;&#91;Bishop&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Bishop&#93; + bishop_center * &#40;center&#91;r&#93; + center&#91;f&#93;)/100;
	&#125;
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...

User avatar
michiguel
Posts: 6242
Joined: Thu Mar 09, 2006 7:30 pm
Location: Chicago, Illinois, USA
Contact:

Re: generate all PSQ tables with 16 numbers

Post by michiguel » Sat Oct 15, 2011 3:48 am

bob wrote:
michiguel wrote:
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)

Code: Select all

static const int center&#91;8&#93;		= &#123;-10,  -5,  +0,  +5,  +5,  +0,  -5, -10&#125;;
// in percent of center&#91;&#93;
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 &#40;int phase = Opening; phase <= EndGame; phase++)
	for &#40;int sq = A1; sq <= H8; sq++) &#123;
		const int r = rank&#40;sq&#41;, f = file&#40;sq&#41;;
		
		if &#40;phase == Opening&#41; &#123;
			PSQTable&#91;phase&#93;&#91;Pawn&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Pawn&#93; + pawn_file_op*center&#91;f&#93;/100;
			PSQTable&#91;phase&#93;&#91;Rook&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Rook&#93; + rook_file_op*center&#91;f&#93;/100;
			PSQTable&#91;phase&#93;&#91;King&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;King&#93; + king_rank_op*r
				+ king_file_op*center&#91;min&#40;FileG,max&#40;FileB,f&#41;)&#93;/100;		// HACK&#58; A and H files are forced to the same values as B and G
		&#125; else &#123;
			PSQTable&#91;phase&#93;&#91;Queen&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Queen&#93; + queen_center_eg * &#40;center&#91;r&#93; + center&#91;f&#93;) / 100;
			PSQTable&#91;phase&#93;&#91;King&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;King&#93; + king_center_eg * &#40;center&#91;r&#93; + center&#91;f&#93;) / 100;
		&#125;
		
		PSQTable&#91;phase&#93;&#91;Knight&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Knight&#93; + knight_center * &#40;center&#91;r&#93; + center&#91;f&#93;)/100;
		PSQTable&#91;phase&#93;&#91;Bishop&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Bishop&#93; + bishop_center * &#40;center&#91;r&#93; + center&#91;f&#93;)/100;
	&#125;
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

bob
Posts: 20340
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: generate all PSQ tables with 16 numbers

Post by bob » Sat Oct 15, 2011 3:29 pm

michiguel wrote:
bob wrote:
michiguel wrote:
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)

Code: Select all

static const int center&#91;8&#93;		= &#123;-10,  -5,  +0,  +5,  +5,  +0,  -5, -10&#125;;
// in percent of center&#91;&#93;
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 &#40;int phase = Opening; phase <= EndGame; phase++)
	for &#40;int sq = A1; sq <= H8; sq++) &#123;
		const int r = rank&#40;sq&#41;, f = file&#40;sq&#41;;
		
		if &#40;phase == Opening&#41; &#123;
			PSQTable&#91;phase&#93;&#91;Pawn&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Pawn&#93; + pawn_file_op*center&#91;f&#93;/100;
			PSQTable&#91;phase&#93;&#91;Rook&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Rook&#93; + rook_file_op*center&#91;f&#93;/100;
			PSQTable&#91;phase&#93;&#91;King&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;King&#93; + king_rank_op*r
				+ king_file_op*center&#91;min&#40;FileG,max&#40;FileB,f&#41;)&#93;/100;		// HACK&#58; A and H files are forced to the same values as B and G
		&#125; else &#123;
			PSQTable&#91;phase&#93;&#91;Queen&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Queen&#93; + queen_center_eg * &#40;center&#91;r&#93; + center&#91;f&#93;) / 100;
			PSQTable&#91;phase&#93;&#91;King&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;King&#93; + king_center_eg * &#40;center&#91;r&#93; + center&#91;f&#93;) / 100;
		&#125;
		
		PSQTable&#91;phase&#93;&#91;Knight&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Knight&#93; + knight_center * &#40;center&#91;r&#93; + center&#91;f&#93;)/100;
		PSQTable&#91;phase&#93;&#91;Bishop&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Bishop&#93; + bishop_center * &#40;center&#91;r&#93; + center&#91;f&#93;)/100;
	&#125;
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.

zamar
Posts: 613
Joined: Sun Jan 18, 2009 6:03 am

Re: generate all PSQ tables with 16 numbers

Post by zamar » Sat Oct 15, 2011 5:12 pm

bob wrote:
michiguel wrote:
bob wrote:
michiguel wrote:
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)

Code: Select all

static const int center&#91;8&#93;		= &#123;-10,  -5,  +0,  +5,  +5,  +0,  -5, -10&#125;;
// in percent of center&#91;&#93;
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 &#40;int phase = Opening; phase <= EndGame; phase++)
	for &#40;int sq = A1; sq <= H8; sq++) &#123;
		const int r = rank&#40;sq&#41;, f = file&#40;sq&#41;;
		
		if &#40;phase == Opening&#41; &#123;
			PSQTable&#91;phase&#93;&#91;Pawn&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Pawn&#93; + pawn_file_op*center&#91;f&#93;/100;
			PSQTable&#91;phase&#93;&#91;Rook&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Rook&#93; + rook_file_op*center&#91;f&#93;/100;
			PSQTable&#91;phase&#93;&#91;King&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;King&#93; + king_rank_op*r
				+ king_file_op*center&#91;min&#40;FileG,max&#40;FileB,f&#41;)&#93;/100;		// HACK&#58; A and H files are forced to the same values as B and G
		&#125; else &#123;
			PSQTable&#91;phase&#93;&#91;Queen&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Queen&#93; + queen_center_eg * &#40;center&#91;r&#93; + center&#91;f&#93;) / 100;
			PSQTable&#91;phase&#93;&#91;King&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;King&#93; + king_center_eg * &#40;center&#91;r&#93; + center&#91;f&#93;) / 100;
		&#125;
		
		PSQTable&#91;phase&#93;&#91;Knight&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Knight&#93; + knight_center * &#40;center&#91;r&#93; + center&#91;f&#93;)/100;
		PSQTable&#91;phase&#93;&#91;Bishop&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Bishop&#93; + bishop_center * &#40;center&#91;r&#93; + center&#91;f&#93;)/100;
	&#125;
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.
Joona Kiiski

User avatar
marcelk
Posts: 348
Joined: Fri Feb 26, 2010 11:21 pm
Contact:

Re: generate all PSQ tables with 16 numbers

Post by marcelk » Sat Oct 15, 2011 9:37 pm

michiguel wrote:
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)

Code: Select all

static const int center&#91;8&#93;		= &#123;-10,  -5,  +0,  +5,  +5,  +0,  -5, -10&#125;;
// in percent of center&#91;&#93;
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 &#40;int phase = Opening; phase <= EndGame; phase++)
	for &#40;int sq = A1; sq <= H8; sq++) &#123;
		const int r = rank&#40;sq&#41;, f = file&#40;sq&#41;;
		
		if &#40;phase == Opening&#41; &#123;
			PSQTable&#91;phase&#93;&#91;Pawn&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Pawn&#93; + pawn_file_op*center&#91;f&#93;/100;
			PSQTable&#91;phase&#93;&#91;Rook&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Rook&#93; + rook_file_op*center&#91;f&#93;/100;
			PSQTable&#91;phase&#93;&#91;King&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;King&#93; + king_rank_op*r
				+ king_file_op*center&#91;min&#40;FileG,max&#40;FileB,f&#41;)&#93;/100;		// HACK&#58; A and H files are forced to the same values as B and G
		&#125; else &#123;
			PSQTable&#91;phase&#93;&#91;Queen&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Queen&#93; + queen_center_eg * &#40;center&#91;r&#93; + center&#91;f&#93;) / 100;
			PSQTable&#91;phase&#93;&#91;King&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;King&#93; + king_center_eg * &#40;center&#91;r&#93; + center&#91;f&#93;) / 100;
		&#125;
		
		PSQTable&#91;phase&#93;&#91;Knight&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Knight&#93; + knight_center * &#40;center&#91;r&#93; + center&#91;f&#93;)/100;
		PSQTable&#91;phase&#93;&#91;Bishop&#93;&#91;sq&#93; = Material&#91;phase&#93;&#91;Bishop&#93; + bishop_center * &#40;center&#91;r&#93; + center&#91;f&#93;)/100;
	&#125;
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.

User avatar
marcelk
Posts: 348
Joined: Fri Feb 26, 2010 11:21 pm
Contact:

Re: generate all PSQ tables with 16 numbers

Post by marcelk » Sat Oct 15, 2011 11:02 pm

marcelk wrote:
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.)

Post Reply