midgame/endgame pcsq

[PK]

hello,

recently I decided to let my engine scale piece/square scores between the middlegame and the endgame. now there are two feasible approaches

1. to scale across the whole spectrum of piece material values, right from the first exchange down to a pawn endgame

2. to scale only in a transition period between middlegame and endgame (which I have defined as "any position in which neither player has more material than a queen and a minor")

now which of those two ways is preferable?

a secondary question is: if You choose the first route, how does it fit together with Larry Kaufman's formulas based on the no. of pawns?

[bob]

hello,

recently I decided to let my engine scale piece/square scores between the middlegame and the endgame. now there are two feasible approaches

1. to scale across the whole spectrum of piece material values, right from the first exchange down to a pawn endgame

2. to scale only in a transition period between middlegame and endgame (which I have defined as "any position in which neither player has more material than a queen and a minor")

now which of those two ways is preferable?

a secondary question is: if You choose the first route, how does it fit together with Larry Kaufman's formulas based on the no. of pawns?

1. An abrupt change, where you cross that mythical middlegame-to-endgame threshold causes issues, because the search can use that discontinuity in the evaluation range to produce some unexpected results. The material-based scaling bypasses this for the most part. Of course, when each pawn or piece is removed, the score jumps or falls by a discreet value so it is still discontinuous, but the jumps are smaller and cause far fewer problems.

2. We've played a lot with Larry's number of pawns idea. None have worked, but then if you do mobility, you are doing that indirectly anyway for pieces like bishops and knights...

[PK]

hi,

perhaps I didn't express myself sufficiently clearly: talking about not scaling across the whole spectrum of material values I didn't mean an abrupt change, but something like in Phalanx: there is middlegame (only middlegame pcsq tables are used), there is endgame (only endgame pcsq are used) and there is a transition phase (roughly 1/3 of material values' spectrum) where values are scaled.

regards

pawel

[bob]

hi,

perhaps I didn't express myself sufficiently clearly: talking about not scaling across the whole spectrum of material values I didn't mean an abrupt change, but something like in Phalanx: there is middlegame (only middlegame pcsq tables are used), there is endgame (only endgame pcsq are used) and there is a transition phase (roughly 1/3 of material values' spectrum) where values are scaled.

regards

pawel

The issue is the two phases, MG and EG, and how wide the transition zone between them is. In a worst-case scenario, the zone is of width zero (0) which means a single capture can drop you from MG to EG and produce a significant score change which is a classic discontinuity (something like a unit step function in mathematics). The best-case scenario would be a floating-point number that scales smoothly from the first move of the game to the last move. Reality is somewhere between, since we are using integer values and that starts off as discrete values to start with and there most definitely is a discontinuity between any two integer values used like that.

The bottom line is that the smaller the discontinuity, the better. Which means it is better to scale from start to finish, rather than scaling just in the middle 1/3 of the material values. That narrow scaling range results in larger score changes (larger discontinuities) which lead to problems.