Request for engines with modified stalemate values

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Steamhammer
Posts: 31
Joined: Sat Jun 21, 2014 5:00 pm

Request for engines with modified stalemate values

Post by Steamhammer » Thu Apr 16, 2015 2:26 pm

Hello,

I am looking for strong modified chess engines (may be counting to the 20 best) in order to experiment with changed stalemate values.

Background is my concept for "Lasker Chess". It's already years back, when I first discussed and recommended Emanuel Lasker's idea of (re-introducing) a different score for stalemate than 0,5 points. Others like Réti followed Lasker too, but there was never a strong tournament with the new rule.

The idea is to encourage players to stalemating their opponents, if they have a clearly better, but unwinnable position, like happens quite often in endgames, where you face problems converting material advantage and your opponent is happy to save a draw by stalemate. In my view, stalemating should be counted as 3/4 points, while the stalemated player should get 1/4 points.

Such change might have an interesting and stimulating effect in all chess competitions, where the draw rate is rather high, like particularly in top correspondence chess and also in top computer chess including freestyle chess.

The engine should try to avoid a draw and look for stalemating the opponent, if that's the best possible result to achieve.
Vice versa, if the engine's position is worse, it should go for a draw rather than being stalemated, if that's the best possible result.


Draws can happen on various ways: move repetition, perpetual check, 50-moves rule, insufficient material (Like K vs K or K+B vs K, K+N vs K etc.; but be careful: NOT K+P vs K and NOT K+2N vs K; means various so-called drawn endings have to be checked, whether a stalemate is possible or not and whether it is forcable or not. May be, for getting started, we should leave aside the EGTB, as they would have to be revised.

Anyone, who might be able to provide a (modified) engine for such experiments (playing E vs E and H vs E), please contact me.

mailto: arno@infinitychess.com

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

Re: Request for engines with modified stalemate values

Post by hgm » Thu Apr 16, 2015 8:14 pm

I predict you that altering the stalemate score will have very little effect. KNNK hardly ever occurs, so the only practical difference is that some KPK positions that otherwise would be draws now are worth 3/4 point. Perhaps this would lower the draw rate by some 2 percent points.

As stalemates in practice only occur in the very-late end-game, it would probably be more effective to investigate this with tablebases than with engines.

AlvaroBegue
Posts: 912
Joined: Tue Mar 09, 2010 2:46 pm
Location: New York
Full name: Álvaro Begué (RuyDos)

Re: Request for engines with modified stalemate values

Post by AlvaroBegue » Fri Apr 17, 2015 12:04 am

It should be trivial to modify a chess engine to change the value of stalemate. In my RuyDos, for instance, I have this, after the loop over moves in the search function:

Code: Select all

  if (legal_moves == 0)
    alpha = in_check ? -7999 + from_root: 0;
Then alpha is returned just a bit after that. Change that last 0 to something like -200 (centipawns) and you are done.

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

Re: Request for engines with modified stalemate values

Post by hgm » Fri Apr 17, 2015 6:16 am

The problem is that this alone will not really be enough to make the engine fully exploit this rule change. Because the actual stalemate will usually not be within the horizon at the time when the engine commits itself.

You don't want the stalemate score to be higher than the draw margin, or the engine would go for an immediate stalemate in winning positions where the checkmate is still beyond the horizon. And if it is lower than the draw margin the engine would only consider it attractive when the 50-move or rep-draw get within the horizon in al alternative branches.

To sensibly affect its choices for converting to end-games where it can stalemate or be stalemated, there should be recognizers for those, affecting the heuristic evaluation. Otherwise you will get similar problems as in engines that do not evaluate KBK and KNK as draws.

User avatar
Ozymandias
Posts: 1001
Joined: Sun Oct 25, 2009 12:30 am

Re: Request for engines with modified stalemate values

Post by Ozymandias » Fri Apr 17, 2015 7:40 am

hgm wrote:Perhaps this would lower the draw rate by some 2 percent points.
2% still has some practical usefulness, for tie-breaking.
hgm wrote:As stalemates in practice only occur in the very-late end-game, it would probably be more effective to investigate this with table bases than with engines.
More effective and engine independent, once you're in a TB position. We would only need for moves leading to a draw, being segregated, this could be done by eliminating the difference between mate and stalemate. The IC GUI would then adjust the score, once the stalemate occurs (provided the "losing" engine didn't have auto-resign "on"). Search is way more tricky, the engine has to recognize what types of endings, are more prone to a stalemate, so it can choose or avoid them, depending on the actual chances (without the stalemate), of drawing the position.

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

Re: Request for engines with modified stalemate values

Post by hgm » Fri Apr 17, 2015 8:06 am

My suspicion is that when you build '5-way' tablebases (distingushing not only checkmate, draw, checkmated, but also stalemate and stalemated), and work your way back to more complex material combinations, the stalemate/stalemated sector would quickly dry up. It is not really more difficult to force a stalemate upon the opponent than a checkmate; it is just a tactical coincidence whether you might be able to deliver the fnal check or not (e.g. that KNNK cannot do it, and KBNK only in the right corner). But you need a similar advantage to force the opponent to the location where he can be mated. So when you have that advantage, and the game is still complex enough, the leading side should still be able to choose whether he is going to stalemate or checkmate you. Only when the game has simplified so much that by this rather rare tactical coincidence the final check is not possible, you would need the stalemate as a backup plan.

So it could very well be that in 6-men tablebases virtually no positions would be left that would be labeled as stalemate(d). Pawn endings would be the most likely candidates where stalemate outcomes would remain upto a large number of pieces, as stalemates there are common even without first baring the losing King, and driving a King to a location where he can be stalemated is made easy by the condition that the defender must try to stop promotion. So even in KPK you can force stalemate, even though your tactical superiority is almost non-existent.

AlvaroBegue
Posts: 912
Joined: Tue Mar 09, 2010 2:46 pm
Location: New York
Full name: Álvaro Begué (RuyDos)

Re: Request for engines with modified stalemate values

Post by AlvaroBegue » Fri Apr 17, 2015 8:34 am

I was just reading the Wikipedia page on stalemate, and it turns out this "stalemate counts as half a victory" is actually one of the rules that has been used in the past, apparently in games played for money in Spain.

http://en.wikipedia.org/wiki/Stalemate# ... emate_rule

I happen to prefer the "stalemate is a win" rule. Perhaps I'll implement it as an option in my engine, but hgm is correct in pointing out that the evaluation for many endgames would have to change. The Wikipedia article mentions that material advantage would become more important with the rule change, but I don't think that would be a practical concern until pretty late in the game.

User avatar
Ozymandias
Posts: 1001
Joined: Sun Oct 25, 2009 12:30 am

Re: Request for engines with modified stalemate values

Post by Ozymandias » Fri Apr 17, 2015 8:39 am

hgm wrote:My suspicion is that when you build '5-way' table bases (distinguishing not only checkmate, draw, checkmated, but also stalemate and stalemated), and work your way back to more complex material combinations, the stalemate/stalemated sector would quickly dry up.
How quickly, could be influenced by a "stalemate contempt" parameter.

Steamhammer
Posts: 31
Joined: Sat Jun 21, 2014 5:00 pm

Re: Request for engines with modified stalemate values

Post by Steamhammer » Fri Apr 17, 2015 12:58 pm

Thanks a lot for your feedback. I think, it might be useful to have some test positions, where you can check whether engine modifying for changed stalemate values, as suggested, is working correctly:

1) First a rather simple example (I):

Image
White stalemates Black

Solution: The only way in oder to stalemate Black and aboid a draw is:
1. Bxf8 Kxf8 2. Kg6 Kg8 3. f7+ Kf8 4. Kf6 stalemate.

2) And now a bit tricky example (II):

Study by A.Nickel, SCHACH 10/2013

Image
Black stalemates White

Solution: There is only one way in ordert o convert material advantage in order to avoid the draw and stalemate White:
1... Nxb5! 2. cxb5 a5! (or 2...a6!) 3. bxa6 Bh1 (or any other bishop move on the diagonal h1-c6) 4. a7 (4. Ka7 Kc7! stalemate) 4... Ba8! 5. Kxa8 Kc8! stalemate.

3) And finally a simple example (III), where White avoids getting stalemated, but forces a draw:

Image
White to move, avoids getting stalemated

Solution: 1.Kh7, and if 1...Kf7, so 2.Kh8; but not 1...h7 2.Kf7 stalemate.

Please note that these example are just for testing. I don't want to say, they are rather common in practice, though they might occur in similiar ways.

Finally, I guess, that the general draw rate would decrease more than 5%, if the changed stalemate rule would apply. (BUT: Let's give it a try and found out what it is all about!)
The endgame K+P vs K is a basic endgame, that in practice usually isn’t executed just for one reason: both players much earlier agreeing to a draw or one side resigning.
Most important for changing the stalemate score is, a) that differenciation of performance is more sports like and fairer; b) that players would get more options and the game would become even more complex, while I am sure, it would not become more “materialistic”. I tested the basice rook ending K+R+P vs K+R and found that the Philidor position (defending draw) still works, if the defender has an active rook. Only with a passive rook you might be forced to trade rooks and getting stalemated.

Two years ago I published a detailed essay on the problem of increasing draw rates in correspondence chess and on the Lasker-Réti idea of changing the score(s) for stalemate. I'm sorry it's only available in German: Die Unbesiegbaren - dem Fernschach droht der Remistod
I also posted as "Correspondence GM", if I remember right, on ChessBase, when Nigel Short's demand to abolish (!) stalemate was discussed by various readers. Sorry to say, but almost non of those guys (including Short, it seemed to me) know much about the special history of the stalemate rule and about Lasker's and Réti's contributions.

Ferdy
Posts: 3645
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: Request for engines with modified stalemate values

Post by Ferdy » Fri Apr 17, 2015 5:47 pm

Deuterium has different options to handle draw scores.

Code: Select all

option name RepetitionScore type spin default 0 min -500 max 500
option name InsufficientMaterialScore type spin default 0 min -500 max 500
option name FiftyMoveScore type spin default 0 min -500 max 500
option name StaleMateScore type spin default 0 min -30000 max 30000
Not really that strong.
CCRL 40/40

Code: Select all

30	Deuterium 14.3.34.130 64-bit	2911 (+12)	+23	−23	49.3%	+4.4	47.0%	551
To get the behaviour you want set StalemateScore to -500 for example.

[d]5bk1/8/5P2/6K1/8/B7/8/8 w - - 3 1

Code: Select all

Deuterium v14.3.34.130:
 1/3	00:00	 25	0	+3.10	1.Be7
 2/4	00:00	 86	0	+2.62	1.Bxf8
 2/2	00:00	 104	0	+2.62	1.Bxf8 Kxf8
 3/5	00:00	 212	0	+2.79	1.Bxf8 Kxf8 2.Kg6
 4/6	00:00	 426	426k	+2.68	1.Bxf8 Kxf8 2.Kg6 Ke8
 5/6	00:00	 622	622k	+2.93	1.Bxf8 Kxf8 2.Kg6 Kg8 3.Kf5
 6/8	00:00	 1k	1,041k	+2.80	1.Bxf8 Kxf8 2.Kf5 Kf7 3.Ke5 Ke8
 7/8	00:00	 1k	1,177k	+3.10	1.Bxf8
 7/7	00:00	 1k	596k	+4.10	1.Bxf8
 7/10	00:00	 1k	699k	+5.00	1.Bxf8 Kxf8 2.Kg6 Kg8 3.f7+ Kf8 4.Kf6
 8/10	00:00	 2k	869k	+5.00	1.Bxf8 Kxf8 2.Kg6 Kg8 3.f7+ Kf8 4.Kf6
 9/11	00:00	 2k	1,081k	+5.00	1.Bxf8 Kxf8 2.Kg6 Kg8 3.f7+ Kf8 4.Kf6
 10/11	00:00	 3k	924k	+5.00	1.Bxf8 Kxf8 2.Kg6 Kg8 3.f7+ Kf8 4.Kf6
 11/12	00:00	 3k	1,157k	+5.00	1.Bxf8 Kxf8 2.Kg6 Kg8 3.f7+ Kf8 4.Kf6
 12/11	00:00	 4k	1,105k	+5.00	1.Bxf8 Kxf8 2.Kg6 Kg8 3.f7+ Kf8 4.Kf6
 13/14	00:00	 5k	1,098k	+5.00	1.Bxf8 Kxf8 2.Kg6 Kg8 3.f7+ Kf8 4.Kf6
[d]1K1k4/p7/3n4/1N6/2P5/8/6b1/8 b - - 3 1

Code: Select all

Deuterium v14.3.34.130:
 1/2	00:00	 29	0	+3.51	1. ... Nxb5 2.cxb5
 2/4	00:00	 171	0	+2.37	1. ... Ne4 2.Kxa7
 3/5	00:00	 224	224k	+2.72	1. ... Ne4
 3/5	00:00	 394	394k	+2.78	1. ... Ne4 2.Kxa7 Bf1
 4/6	00:00	 1k	553k	+2.34	1. ... Ne4 2.Kxa7 Bf1 3.Kb6
 5/7	00:00	 1k	697k	+2.62	1. ... Ne4 2.Kxa7 Bf1 3.Kb6 Bd3
 6/9	00:00	 2k	690k	+2.57	1. ... Ne4 2.Kxa7 Bf1 3.Kb6 Kd7 4.c5
 7/11	00:00	 3k	853k	+2.85	1. ... Ne4 2.Kxa7 Bf1 3.Kb6 Kd7 4.c5 Bd3
 8/12	00:00	 10k	805k	+2.50	1. ... Nc8 2.Nxa7 Nb6 3.Nb5 Nd7+ 4.Ka7 Bf1 5.Nd6 Nc5
 9/14	00:00	 13k	828k	+2.37	1. ... Nc8 2.Nxa7 Nb6 3.Nb5 Nd7+ 4.Ka7 Ke7 5.Nd4 Kd6 6.Ka6
 10/14	00:00	 21k	868k	+2.34	1. ... Nc8 2.Nxa7 Nb6 3.Nb5 Nd7+ 4.Ka7 Ke7 5.c5 Bc6 6.Nd4 Be4
 11/16	00:00	 33k	857k	+2.19	1. ... Nc8 2.Nxa7 Nb6 3.Nb5 Nd7+ 4.Ka7 Bf1 5.Ka6 Bd3 6.c5 Ne5 7.Kb6
 12/16+	00:00	 35k	852k	+2.49	1. ... Nc8
 12/18	00:00	 61k	948k	+2.37	1. ... Nc8 2.Nxa7 Nb6 3.Nb5 Nd7+ 4.Ka7 Bf1 5.Kb7 Ke7 6.Nd4 Bg2+ 7.Ka7 Be4 8.c5 Kd8
 13/19	00:00	 100k	946k	+2.17	1. ... Nc8 2.Nxa7 Nb6 3.Nb5 Nd7+ 4.Ka7 Bc6 5.Ka6 Ne5 6.c5 Nd3 7.Nd4 Be4 8.c6
 14/19	00:00	 188k	976k	+2.08	1. ... Nc8 2.Nxa7 Nb6 3.Nb5 Nd7+ 4.Ka7 Bf1 5.Kb7 Ke7 6.Nd4 Bg2+ 7.Ka7 Nc5 8.Kb6 Nd3 9.Kb5
 15/22+	00:00	 255k	1,053k	+2.38	1. ... Nxb5
 15/12+	00:00	 255k	1,053k	+3.38	1. ... Nxb5
 15/21	00:00	 286k	1,085k	+5.00	1. ... Nxb5 2.cxb5 a5 3.bxa6 Kd7 4.a7 Ba8 5.Kxa8 Kc7
 16/18	00:00	 317k	1,111k	+5.00	1. ... Nxb5 2.cxb5 a5 3.bxa6 Kd7 4.a7 Ba8 5.Kxa8 Kc7
 17/19	00:00	 361k	1,147k	+5.00	1. ... Nxb5 2.cxb5 a5 3.bxa6 Kd7 4.a7 Ba8 5.Kxa8 Kc7
 18/19	00:00	 414k	1,192k	+5.00	1. ... Nxb5 2.cxb5 a5 3.bxa6 Kd7 4.a7 Ba8 5.Kxa8 Kc7
[d]5k1K/8/7P/8/8/8/8/8 w - - 3 1

Code: Select all

Deuterium v14.3.34.130:
 1/2	00:00	 7	0	+10.67	1.Kh7
 2/2	00:00	 19	0	+5.17	1.Kh7
 2/2	00:00	 24	0	+5.17	1.Kh7 Ke7
 3/3	00:00	 37	0	+0.70	1.Kh7
 3/3	00:00	 43	0	+0.70	1.Kh7 Kf7 2.Kh8
 4/4	00:00	 71	0	 0.00	1.Kh7
 4/4	00:00	 83	0	 0.00	1.Kh7 Kf7 2.Kh8 Kf8
 5/6	00:00	 124	0	 0.00	1.Kh7 Kf7 2.Kh8 Kf8
 6/6	00:00	 196	0	 0.00	1.Kh7 Kf7 2.Kh8 Kf8
 7/8	00:00	 300	0	 0.00	1.Kh7 Kf7 2.Kh8 Kf8
 8/8	00:00	 439	0	 0.00	1.Kh7 Kf7 2.Kh8 Kf8
 9/10	00:00	 625	0	 0.00	1.Kh7 Kf7 2.Kh8 Kf8
 10/10	00:00	 864	0	 0.00	1.Kh7 Kf7 2.Kh8 Kf8
 11/11	00:00	 1k	0	 0.00	1.Kh7 Kf7 2.Kh8 Kf8
 12/12	00:00	 1k	0	 0.00	1.Kh7 Kf7 2.Kh8 Kf8
 13/13	00:00	 2k	119k	 0.00	1.Kh7 Kf7 2.Kh8 Kf8
 14/14	00:00	 2k	146k	 0.00	1.Kh7 Kf7 2.Kh8 Kf8
 15/15	00:00	 3k	180k	 0.00	1.Kh7 Kf7 2.Kh8 Kf8
 16/16	00:00	 4k	220k	 0.00	1.Kh7 Kf7 2.Kh8 Kf8
 17/17	00:00	 4k	264k	 0.00	1.Kh7 Kf7 2.Kh8 Kf8
 
Download:
https://sites.google.com/site/deuterium ... /deuterium

Post Reply