Define end game

Discussion of chess software programming and technical issues.

Moderators: Harvey Williamson, bob, hgm

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
lauriet
Posts: 198
Joined: Sun Nov 03, 2013 8:32 am
Contact:

Define end game

Post by lauriet » Wed Nov 16, 2016 4:29 am

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
Posts: 3883
Joined: Thu May 15, 2008 7:57 pm
Location: Berlin, Germany
Full name: Sven Schüle
Contact:

Re: Define end game

Post by Sven » Wed Nov 16, 2016 7:41 am

lauriet wrote: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
Posts: 705
Joined: Fri Jan 04, 2013 3:55 pm
Location: Nice

Re: Define end game

Post by Daniel Anulliero » Wed Nov 16, 2016 12:33 pm

Sven Schüle wrote:
lauriet wrote: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 :wink:

Henk
Posts: 6554
Joined: Mon May 27, 2013 8:31 am

Re: Define end game

Post by Henk » Wed Nov 16, 2016 10:54 pm

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

User avatar
phhnguyen
Posts: 849
Joined: Wed Apr 21, 2010 2:58 am
Location: Australia
Full name: Nguyen Hong Pham
Contact:

Re: Define end game

Post by phhnguyen » Thu Nov 17, 2016 8:04 am

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)

User avatar
cdani
Posts: 2175
Joined: Sat Jan 18, 2014 9:24 am
Location: Andorra
Contact:

Re: Define end game

Post by cdani » Thu Nov 17, 2016 8:47 am

Henk wrote: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
Posts: 3883
Joined: Thu May 15, 2008 7:57 pm
Location: Berlin, Germany
Full name: Sven Schüle
Contact:

Re: Define end game

Post by Sven » Thu Nov 17, 2016 8:47 am

phhnguyen wrote: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.

User avatar
phhnguyen
Posts: 849
Joined: Wed Apr 21, 2010 2:58 am
Location: Australia
Full name: Nguyen Hong Pham
Contact:

Re: Define end game

Post by phhnguyen » Thu Nov 17, 2016 10:28 am

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.

User avatar
hgm
Posts: 25044
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Define end game

Post by hgm » Thu Nov 17, 2016 11:19 am

cdani wrote:
Henk wrote: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
Posts: 3883
Joined: Thu May 15, 2008 7:57 pm
Location: Berlin, Germany
Full name: Sven Schüle
Contact:

Re: Define end game

Post by Sven » Thu Nov 17, 2016 1:00 pm

phhnguyen wrote: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.

Post Reply