Any tips on the things to consider for my function 'endgame'.
Should I just look at material left ?
Number of moves played ?
Thanks
Laurie.
Define end game
Moderators: hgm, Rebel, chrisw
-
- Posts: 4052
- Joined: Thu May 15, 2008 9:57 pm
- Location: Berlin, Germany
- Full name: Sven Schüle
Re: Define end game
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".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.
-
- Posts: 759
- Joined: Fri Jan 04, 2013 4:55 pm
- Location: Nice
Re: Define end game
True!Sven Schüle wrote: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".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.
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
-
- Posts: 7216
- Joined: Mon May 27, 2013 10:31 am
Re: Define end game
Don't understand. Nothing smooth about a queen exchange.
-
- Posts: 1434
- Joined: Wed Apr 21, 2010 4:58 am
- Location: Australia
- Full name: Nguyen Hong Pham
Re: Define end game
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)
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)
-
- Posts: 2204
- Joined: Sat Jan 18, 2014 10:24 am
- Location: Andorra
Re: Define end game
Sure, but this does not change the idea behind tapered eval.Henk wrote:Don't understand. Nothing smooth about a queen exchange.
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.
Daniel José - http://www.andscacs.com
-
- Posts: 4052
- Joined: Thu May 15, 2008 9:57 pm
- Location: Berlin, Germany
- Full name: Sven Schüle
Re: Define end game
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 wrote:I think before being able to "taper", we should have endgame eval first!
-
- Posts: 1434
- Joined: Wed Apr 21, 2010 4:58 am
- Location: Australia
- Full name: Nguyen Hong Pham
Re: Define end game
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.
-
- Posts: 27790
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Define end game
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.cdani wrote:Sure, but this does not change the idea behind tapered eval.Henk wrote:Don't understand. Nothing smooth about a queen exchange.
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.
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.
-
- Posts: 4052
- Joined: Thu May 15, 2008 9:57 pm
- Location: Berlin, Germany
- Full name: Sven Schüle
Re: Define end game
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.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.
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.