MG | EG experiment

[Rebel]

I created a tool that creates reasonable MG/EG PST's from a PGN database, nothing special so far, except if it splits MG and EG into 2 parts.

Definitions:
MG1 - for the opening and middle game with queens;
MG2 - for the middle game without queens;
EG1 - for the regular endgame
EG2 - for the late endgame (rook endings, bishop / knight endings, pawn endings)

The result - http://rebel13.nl/@pst.txt

An interesting observation is the difference between the king tables of MG1 and MG2, in the midgame without queens it's indeed safe to move the king forwards.

Code: Select all

int wk_mg1[]={                        int wk_mg2[]={                    
 11, 52, 43, 17, -1, 21, 42, 68,        0,  0,  0,  0,  0,  0,  0,  0,  
 23, 25,  4, 22, 21, 32, 53,  4,        0,  0,  0,  0,  0,  0,  0,  0,  
 -2, 11,  2,  3, 40, 25, 23, -1,        0,  0,  0,  0,  0,  0,  0,  0,  
-14,  7,-17,  5, -5, -7, 14,  9,        0,  7,  0,  0,  0,  0, 37,  0,  
 -8,-18,-21,-33,-29,-17,  0,-15,       52, 22,-25, 40, 37, 43, 36, 18,  
 18, 10,-20,-29,-11, -4, 14, -2,       19, 15, 21, 29, 32, 31, 31, 12,  
 36, 32,  4, 10,  1, 13, 25, 22,       -3, 14, 25, 33, 41, 27, 11,-10,  
 17, 33, 34,-13,  0, -4, 16,  8 };     -9, 15, 23, 28,  0, 19,  7,  6 };

[amanjpro]

I created a tool that creates reasonable MG/EG PST's from a PGN database, nothing special so far, except if it splits MG and EG into 2 parts.

Definitions:
MG1 - for the opening and middle game with queens;
MG2 - for the middle game without queens;
EG1 - for the regular endgame
EG2 - for the late endgame (rook endings, bishop / knight endings, pawn endings)

The result - http://rebel13.nl/@pst.txt

An interesting observation is the difference between the king tables of MG1 and MG2, in the midgame without queens it's indeed safe to move the king forwards.

Code: Select all

int wk_mg1[]={                        int wk_mg2[]={                    
 11, 52, 43, 17, -1, 21, 42, 68,        0,  0,  0,  0,  0,  0,  0,  0,  
 23, 25,  4, 22, 21, 32, 53,  4,        0,  0,  0,  0,  0,  0,  0,  0,  
 -2, 11,  2,  3, 40, 25, 23, -1,        0,  0,  0,  0,  0,  0,  0,  0,  
-14,  7,-17,  5, -5, -7, 14,  9,        0,  7,  0,  0,  0,  0, 37,  0,  
 -8,-18,-21,-33,-29,-17,  0,-15,       52, 22,-25, 40, 37, 43, 36, 18,  
 18, 10,-20,-29,-11, -4, 14, -2,       19, 15, 21, 29, 32, 31, 31, 12,  
 36, 32,  4, 10,  1, 13, 25, 22,       -3, 14, 25, 33, 41, 27, 11,-10,  
 17, 33, 34,-13,  0, -4, 16,  8 };     -9, 15, 23, 28,  0, 19,  7,  6 };

That is cool... Not sure how ProDeo's eval function works, but if it is anything like tapered eval (as in chess programming wiki), then you have to come up with a new rule for computing the end result? Because you have four stages instead of 2

[Rebel]

I have not implemented the 4 stages yet, busy with other things. I am just making a point that perhaps there is elo in a 4 stage approach.

[amanjpro]

I have not implemented the 4 stages yet, busy with other things. I am just making a point that perhaps there is elo in a 4 stage approach.

What Jost did (Nalwald's author), is to have 1 PST set per each square that a king can be on (so, he basically have PSTs related to King's position), and he I think gained a lot of elo with this practice. So, I am of believer that there are lots of elo to be gain with different PST structure

[AndrewGrant]

I have not implemented the 4 stages yet, busy with other things. I am just making a point that perhaps there is elo in a 4 stage approach.

What Jost did (Nalwald's author), is to have 1 PST set per each square that a king can be on (so, he basically have PSTs related to King's position), and he I think gained a lot of elo with this practice. So, I am of believer that there are lots of elo to be gain with different PST structure

This gained a few elo for me, explicitly with Pawns, creating a [0][64][64] PST that was indexed by:
pawn_pst_value = PST[0][our_king_sq][our_pawn_sq] + PST[1][their_king_sq][our_pawn_sq];

The downside being a massive array. Which was actually tenable, but ultimately not committed. This was tested maybe a year ago, and instead I went with a small [256x32x2] NN which achieved a similar effect, but with what I consider a more mathematical basis.

[amanjpro]

I have not implemented the 4 stages yet, busy with other things. I am just making a point that perhaps there is elo in a 4 stage approach.

What Jost did (Nalwald's author), is to have 1 PST set per each square that a king can be on (so, he basically have PSTs related to King's position), and he I think gained a lot of elo with this practice. So, I am of believer that there are lots of elo to be gain with different PST structure

This gained a few elo for me, explicitly with Pawns, creating a [0][64][64] PST that was indexed by:
pawn_pst_value = PST[0][our_king_sq][our_pawn_sq] + PST[1][their_king_sq][our_pawn_sq];

The downside being a massive array. Which was actually tenable, but ultimately not committed. This was tested maybe a year ago, and instead I went with a small [256x32x2] NN which achieved a similar effect, but with what I consider a more mathematical basis.

Yup, I agree with you... I too am afraid of the massive array...

I am (at least mentally), preparing to add NN to my engine, mostly to evaluate endgames, as I am not really into strength as much as style, but it still hurts when my engine cannot convert slightly complicated endgames and ends up with a RN vs R and perfectly happy

[Jakob Progsch]

I occasionally think there should be some way to "compress" those big arrays in case you want multiple PSTs. In the simplest case you create all the PSTs for all the king positions and then you do a principal component analysis on the resulting tables. You can then probably single out some "base PSTs" that let you express all the others by weighted sums. Which in a way is just a slightly different approach to arrive at a form of NN. Except maybe that it is more based on first principled instead of it being an incomprehensible pile of magic numbers.