Rook vs 2 minor pieces with pawns on the board

Discussion of chess software programming and technical issues.

Moderator: Ras

zd3nik
Posts: 193
Joined: Wed Mar 11, 2015 3:34 am
Location: United States

Rook vs 2 minor pieces with pawns on the board

Post by zd3nik »

[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
Dann Corbit
Posts: 12828
Joined: Wed Mar 08, 2006 8:57 pm
Location: Redmond, WA USA

Re: Rook vs 2 minor pieces with pawns on the board

Post by Dann Corbit »

kbhearn
Posts: 411
Joined: Thu Dec 30, 2010 4:48 am

Re: Rook vs 2 minor pieces with pawns on the board

Post by kbhearn »

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
In a word, no... attempts to make drawn endgames report draw scores is usually a loser except for the most trivial of cases.

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)
User avatar
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

Post by hgm »

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?
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
Posts: 193
Joined: Wed Mar 11, 2015 3:34 am
Location: United States

Re: Rook vs 2 minor pieces with pawns on the board

Post by zd3nik »

Thanks for the excellent feedback everyone, I really appreciate it! :)

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

Post by zd3nik »

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:

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.50
I'm reasonably certain the material eval tweaks from the article above are mostly responsible for the improvement. So I thought I'd share so everyone can see a real world example of the effectiveness of the advice provided in the article.

The 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