Define end game

[lauriet]

Any tips on the things to consider for my function 'endgame'.
Should I just look at material left ?
Number of moves played ?

Thanks
Laurie.

[Sven]

Any tips on the things to consider for my function 'endgame'.
Should I just look at material left ?
Number of moves played ?

Thanks
Laurie.

Better consider tapered eval instead. That allows a smooth transition from opening/middlegame into endgame without suffering from a sudden scoring jump triggered by one (capture) move that changes the "isEndgame" condition from "false" into "true".

[Daniel Anulliero]

Any tips on the things to consider for my function 'endgame'.
Should I just look at material left ?
Number of moves played ?

Thanks
Laurie.

Better consider tapered eval instead. That allows a smooth transition from opening/middlegame into endgame without suffering from a sudden scoring jump triggered by one (capture) move that changes the "isEndgame" condition from "false" into "true".

True!
Tapered eval is the best way to have a Smooth variation of the eval during the game .in my first (old) engines , I tried to implement "game phases" dependant of material AND queens or not , but it never worked very well .
My engine Jars (1850 elo) had 4 phases , openning , middle game , end game , late end game but not very well tuned and surely very buggy

[Henk]

Don't understand. Nothing smooth about a queen exchange.

[phhnguyen]

Good answer!

But... I think before being able to "taper", we should have endgame eval first!

(Sorry I can't answer the main question since I have just been back to chess)

[cdani]

Don't understand. Nothing smooth about a queen exchange.

Sure, but this does not change the idea behind tapered eval.

Unless for example when there is some big ongoing attack that is stopped by the queen exchange, the static evaluation should not change a lot.

[Sven]

I think before being able to "taper", we should have endgame eval first!

Not necessarily. I would start by creating the infrastructure that is required for tapered eval (e.g. maintaining two score parts for each single feature, game phase calculation, interpolation), and initially use 1:1 identical scores for MG and EG. That would be wrong at least for king PST (and certainly for a few other terms) but that way it would be possible to check whether the infrastructure works correctly and the evaluation delivers the same scores as before, assuming that the current version makes no difference between MG and EG (if it does then the very first step while transforming to tapered eval could be to let the "isEndgame()" function return false). The final step would then be to adjust the EG scores as far as necessary.

[phhnguyen]

I think we may have different "defines" about MG and EG. For me, EG is the place I implement special knowledge about known EGs such as KRK, KPK... Otherwise it is still in MG even the board has only few pieces left. I have implemented somewhat similar to tapered eval when scores are not fixed but changed based on number of pieces. That is why I always need to detect and evaluate EG.

[hgm]

Don't understand. Nothing smooth about a queen exchange.

Sure, but this does not change the idea behind tapered eval.

Unless for example when there is some big ongoing attack that is stopped by the queen exchange, the static evaluation should not change a lot.

I always have considered this a very unconvincing argument, and I doubt it has really been investigated. The main reason gradually tapered eval works better than a sudden transition might very well be that it biases an engine that is behind in material against trading anything. With a sudden eval jump it would happily simplify until just above the jump,only to realize slightly later that it is impossible to prevent simplification to just below the boundary, and after that again would not resist further simplification at all.

It is important that the engine is biased against equal trades when behind in all stages of the game. Tapered evalis one way to achieve that, when material values go up in the end-game.

[Sven]

I think we may have different "defines" about MG and EG. For me, EG is the place I implement special knowledge about known EGs such as KRK, KPK... Otherwise it is still in MG even the board has only few pieces left. I have implemented somewhat similar to tapered eval when scores are not fixed but changed based on number of pieces. That is why I always need to detect and evaluate EG.

Tapered eval is not about special endgame knowledge for cases like KPK, it is about interpolating scores between MG and EG depending on the game phase, for eval features that exist in MG as well as EG. KPK evaluation simply makes no sense in MG.

Also special endgame knowledge is often "absolute" knowledge that will not need any scaling or interpolation.

So tapered eval and special endgame knowledge are kind of orthogonal to each other.