Definition of "endgame"?

[bob]

Well, it depends how the game-stage is used in your eavaluation. IIRC, for King safety TSCP has a term that is proportional to the opponent material. So that would gradually decrease in importance, rather than all at once. I wonder if this has actually been measured. I would expect that the moment your King has to leave its shelter and join the fight is very sharply defined in most games. Do it too early, and you are toast. Do it too late, and the end-game is hopelessly lost. Trading of a single piece can make the difference if the opponent has quick mating potential against an exposed King, or if he can never do more than pointless chasing with checks. I could well imagine that an abrupt transition approximates reality better than a gradual change.

I am not sure that having different PSTs if middle-game and end-game is useful at all. It seems to me that if PSTs should depend on anything, it would be on Pawn structure. And I guess they could be a very 'discontinuous' function of that: a single Pawn move, permanently opening or closing a line (e.g. trade or push) could have a dramatic effect on if your current piece placement is excellent or disastrous. I think this is a real effect, and should never be smoothened.

One example is for the king. In the middlegame, the king needs to be tucked away safely in its corner. In the endgame it needs to either centralize or go toward the most important pawn mass or passed pawn on the board...

[Tony]

His point was that the difference between positions with 4 rooks as opposed to just two is probably less significant than the difference between positions with 2 rooks vs none. Linearly scaling based on material is not so good there.

Yes that's right
I use a table for the non linear scaling :

Code: Select all

// ------------------------------? K+1+2+3+4+5+6+7 --- space for more pieces...
static int MidGameValueCoef[] = {0,0,0,2,4,5,7,8,8,8,8,8,8,8,8,8,8,8,8};
static int EndGameValueCoef[] = {8,8,8,6,4,2,0,0,0,0,0,0,0,0,0,0,0,0,0};
#define MidGameValue(n,pop)     (((n)*MidGameValueCoef[pop])/8)
#define EndGameValue(n,pop)     (((n)*EndGameValueCoef[pop])/8)

I count 1 for the king and each piece, 2 for the queen, then you can use whatever non linear function to fill the table.

HJ.

While I do like this "being able to put the min.max score at any place" I think it's a bit of an overkill.

First, tuning would be pretty hard and second: I think only the cliff to the endgame is important. Before that, scaling would be ok I gues.

But things like disabling kingsafety, centralise your king, connected passers are stuff that should be thrown in rough.

One can offcoarse still use a small part of the score for "smoothly guiding" the search

Tony

[Tony]

You miss the point.

Since most people do this in a linear way you assume that exchanging from a 4 rook endgame to a 2 rook, has the same effect as going from 2 to 0 rooks.

Tony

I don't know why you say that. You don't know what terms are in the evaluation.
1) you have recognizer for special position or set of position => smoothing is not even used here
2) you have end game terms that handle special positions so they will have more effect the less material you have on the board
3) your rook example : 4 rooks, 2 rook, 0 rooks are different phase number, so obviously the evaluation will be different.

HJ.

His point was that the difference between positions with 4 rooks as opposed to just two is probably less significant than the difference between positions with 2 rooks vs none. Linearly scaling based on material is not so good there.

Correct.

Assume 3 positions. (1) 4 rooks, (2) 2 rooks and (3) no rooks. (all with 4 pawns each)

Now take the score of an outside passed pawn. Do you really want that score linear scaled over these positions ?

For most implementation the score would be

1) 0.66 * score
2) 0.83 * score
3) 1.0 * score

Which doesn't seem correct.

Tony

PS In addition, outside passed pawns are more important in knight endgames than in bishop endgames ( which is lost in this calculation)

[EricLang]

I was wandering about the gamestage too today. I'm trying to implement a decent gamestage function.

I saw this code in Beowulf which looks reasonable to me.
(using 1,3,3,5,9 scale) where tpts is blackpts + whitepts I think.

Code: Select all

int GetGamestage(int tpts) {
  if (tpts>70) return Opening;
  if (tpts>62) return EarlyMid;
  if (tpts>54) return Middle;
  if (tpts>46) return LateMid;
  if (tpts>22) return Endgame;
  return LateEnd;
}

I was wandering too what happens if both sides have a few queens. Doesn't the gamestage go back to EarlyMid or even Opening then?
And is it a relevant question?

[bob]

I was wandering about the gamestage too today. I'm trying to implement a decent gamestage function.

I saw this code in Beowulf which looks reasonable to me.
(using 1,3,3,5,9 scale) where tpts is blackpts + whitepts I think.

Code: Select all

int GetGamestage(int tpts) {
  if (tpts>70) return Opening;
  if (tpts>62) return EarlyMid;
  if (tpts>54) return Middle;
  if (tpts>46) return LateMid;
  if (tpts>22) return Endgame;
  return LateEnd;
}

The problem with the above is subtle, but potentially dangerous. If you try to categorize the phase of the game at a descrete boundary, that suggests that when you reach that boundary, and the new game stage is set, that somehow your evaluation will not use different code to score things differently. This results in a well-known problem where your evaluation becomes discontinuous, and around that discontinuity, strange things can happen. The most common fix today is to compute two scores, one for opening/midgame and one for endgame, as done in Fruit, and then interpolate between them as material is removed. The discontinuity is effectively removed (it is always there in integer evaluations of course, but only to fractions of a pawn).

I'd suggest going that way as the evaluation will now have no serious jumps based on a single capture. For example, if you think Q+R is enough material to not call it an "endgame" and your king safety is bad because of missing pawns, you might trade queens and give up a pawn or to to step over the discontinuity and remove the big king-safety penalty by giving up a pawn or two instead. Probably enough to lose the game even though you were not going to get mated before the trade...


I was wandering too what happens if both sides have a few queens. Doesn't the gamestage go back to EarlyMid or even Opening then?
And is it a relevant question?

[flok]

I was wandering about the gamestage too today. I'm trying to implement a decent gamestage function.

I saw this code in Beowulf which looks reasonable to me.
(using 1,3,3,5,9 scale) where tpts is blackpts + whitepts I think.

Code: Select all

int GetGamestage(int tpts) {
  if (tpts>70) return Opening;
  if (tpts>62) return EarlyMid;
  if (tpts>54) return Middle;
  if (tpts>46) return LateMid;
  if (tpts>22) return Endgame;
  return LateEnd;
}

I was wandering too what happens if both sides have a few queens. Doesn't the gamestage go back to EarlyMid or even Opening then?
And is it a relevant question?

What are blackpts and whitepts?

[Matthias Gemuh]

Simply: how many pieces there can be on board? I remember old
Crafty's had some kind of game phase info: how was it done?

Jouni

there is no "exact solution". The question is, at what point in material do you feel safe to have your king get out into the center of the board as an attacking piece? If you start too early, you get mated. If you start too late, your opponent crushes you in an ending.

That is indeed what the endgame phase is all about.

Matthias.

[Matthias Gemuh]

I was wandering too what happens if both sides have a few queens. Doesn't the gamestage go back to EarlyMid or even Opening then?
And is it a relevant question?

Yes, the gamestage goes back because it becomes more unsafe for his majesty to walk around

Matthias.

[jwes]

The problem with the above is subtle, but potentially dangerous. If you try to categorize the phase of the game at a descrete boundary, that suggests that when you reach that boundary, and the new game stage is set, that somehow your evaluation will not use different code to score things differently. This results in a well-known problem where your evaluation becomes discontinuous, and around that discontinuity, strange things can happen. The most common fix today is to compute two scores, one for opening/midgame and one for endgame, as done in Fruit, and then interpolate between them as material is removed. The discontinuity is effectively removed (it is always there in integer evaluations of course, but only to fractions of a pawn).

Isn't this just hiding the real problem? If there is a discontinuity in the eval, it means either that one or both of the evals is wrong, or that the value of the position changed significantly because of the exchange.

[bob]

I scale as material is removed, not as moves are made.

OK, I see. But let's look at a specific example, Say KQBB+Pawns vs KQBN+Pawns. As black I would not want to come out with my King from behind the Pawn shelter if the opponent still has QBB, as I would be mated very quickly. If the opponent has only KBB, this danger is reduced to about zero, as it is almost impossible to mate with two Bishops (even with King support they can only do it if you are at the board edge).

So wouldn't it be logical to drop King safety completely when Queens are traded? It seems to me this has the character of an all-or-none thing: either the opponent has enough material to mate you in the center of the board, in which case you have to value some protection, or he hasn't.

I don't agree. You have to be aware of the queen and bishops, but if you sit back while your opponent brings his king up, suddenly after he forces the trade of queens, you are dead lost because of king location. However, as pieces are removed, from my own personal chess playing experiences, I get less and less concerned about king safety. The queen coming off is a biggee, although the position helps to determine what to do. If your opponent promotes, you don't want to run your king into a corner and hide, for example...