[d] 8/8/6k1/6pp/4nn2/4R2P/6P1/7K b - - 1 50
Is it a good idea to try to make static positional evaluation on positions such as this something close to a draw score?
Going through self play games in my engines I see things like this all the time. The engine happily plays into an engame like this thinking it's about 2 pawns up.
The trouble is, sometimes 2 minors for a rook IS winning but I don't have enough chess knowledge to make the program know the difference between a winning and a drawn R vs 2-minor ending.
STC
Rook vs 2 minor pieces with pawns on the board
Moderator: Ras
-
zd3nik
- Posts: 193
- Joined: Wed Mar 11, 2015 3:34 am
- Location: United States
-
Dann Corbit
- Posts: 12828
- Joined: Wed Mar 08, 2006 8:57 pm
- Location: Redmond, WA USA
-
kbhearn
- Posts: 411
- Joined: Thu Dec 30, 2010 4:48 am
Re: Rook vs 2 minor pieces with pawns on the board
In a word, no... attempts to make drawn endgames report draw scores is usually a loser except for the most trivial of cases.zd3nik wrote:[d] 8/8/6k1/6pp/4nn2/4R2P/6P1/7K b - - 1 50
Is it a good idea to try to make static positional evaluation on positions such as this something close to a draw score?
Going through self play games in my engines I see things like this all the time. The engine happily plays into an engame like this thinking it's about 2 pawns up.
The trouble is, sometimes 2 minors for a rook IS winning but I don't have enough chess knowledge to make the program know the difference between a winning and a drawn R vs 2-minor ending.
STC
Often going to the presumed drawn ending is the best that can be tried - if you don't try it you still wind up with a draw when it is drawn. But you also wind up with a draw by refusal to progress when there's a win or a chance to swindle one.
You can try to scale the score down a bit for drawishness (say based on number of pawns remaining with low material difference you could apply a multiplier of say 1.0~0.5 as more pawns come off), but taking it down to a level where a human thinks of it as an endgame draw score is a bad idea. Also, the transition shouldn't be sharp (it should be conceivable that it will trade off a pair of pawns if it detects some other form of progress)
-
hgm
- Posts: 28461
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Rook vs 2 minor pieces with pawns on the board
The score should already be close to drawish (2 Knights versus a Rook + open-file bonus) ~+1. To fine-tune it you could give a small penalty for having a pair of Knights as only pieces (for no mating potential in the pieces), and a bonus for the weak side when all his Pawns are near his King.zd3nik wrote:Is it a good idea to try to make static positional evaluation on positions such as this something close to a draw score?
-
zd3nik
- Posts: 193
- Joined: Wed Mar 11, 2015 3:34 am
- Location: United States
Re: Rook vs 2 minor pieces with pawns on the board
Thanks for the excellent feedback everyone, I really appreciate it! 
STC
STC
-
zd3nik
- Posts: 193
- Joined: Wed Mar 11, 2015 3:34 am
- Location: United States
Re: Rook vs 2 minor pieces with pawns on the board
Last night I made some simple tweaks based on the information provided in this article (and a few other minor tweaks based on my observations of it's actual play). I haven't done extensive testing yet, but the short round robin and short gauntlet tests I ran overnight seem to indicate these minor tweaks made a big difference! Here's the short round robin result:Dann Corbit wrote:http://danheisman.home.comcast.net/~dan ... alance.htm
Code: Select all
Engine Score Cl Cl Fa S-B
1: Clubfoot (New) 31.0/40 ···················· 101=1==0111====11=1= 11110=11111=1111=111 435.50
2: Clubfoot (Old) 18.0/40 010=0==1000====00=0= ···················· 0101100=011011001111 328.00
3: Fairy Max 11.0/40 00001=00000=0000=000 1010011=100100110000 ···················· 230.50The changes are very straight forward. See commit https://github.com/zd3nik/Clubfoot/comm ... a4f54e8d74
The Pawn Square values changes (Clubfoot.h lines 74 - 89) are based on the advice that rook pawns are generally worth less.
The main Evaluate() function changes (Clubfoot.h lines 2110 - 2178) constitute the bulk of the change. The code should speak for itself.
The PieceValue changes (Types.h) should also speak for itself.
I've made the new builds available for download. Here are the old and new binaries if anyone is interested in seeing the difference for themselves:
NEW:
Linux: https://drive.google.com/open?id=0B3Bl0 ... authuser=0
Windows: https://drive.google.com/open?id=0B3Bl0 ... authuser=0
OLD:
Linux: https://drive.google.com/open?id=0B3Bl0 ... authuser=0
Windows: https://drive.google.com/open?id=0B3Bl0 ... authuser=0