Fruit2.3.1 stalemate bug

Uri Blass · Post by **Uri Blass** » Sun Oct 21, 2007 4:42 pm

Fruit2.3.1 makes a big blunder in a drawn position
Fruit2.3 also suffers from the same problem.

New game - Fruit 2.3.1

8
7
6
5
4
3
2
1
	a	b	c	d	e	f	g	h

4K2k/5r1p/7P/8/8/8/B7/6Q1 b - - 0 1

Analysis by Fruit 2.3.1:

1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 1 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 2 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 3 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 4 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 5 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 6 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 7 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 8 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 9 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 10 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 11 00:00:01 1kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 12 00:00:01 1kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 13 00:00:01 1kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 14 00:00:01 1kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 15 00:00:01 1kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 16 00:00:01 1kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 17 00:00:01 2kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 18 00:00:02 2kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 19 00:00:02 3kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 20 00:00:02 4kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 21 00:00:02 5kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 22 00:00:02 7kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 23 00:00:02 9kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 24 00:00:02 13kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 25 00:00:02 17kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 26 00:00:02 25kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 27 00:00:02 33kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 28 00:00:02 50kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 29 00:00:02 66kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 30 00:00:03 99kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 31 00:00:03 132kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 32 00:00:03 197kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 33 00:00:03 263kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 34 00:00:03 394kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 35 00:00:03 525kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 36 00:00:03 787kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 37 00:00:04 1049kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 38 00:00:04 1574kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 39 00:00:04 2098kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 40 00:00:04 3147kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 41 00:00:04 4195kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 42 00:00:05 6292kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 43 00:00:06 8389kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 44 00:00:06 12584kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 45 00:00:07 16778kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 46 00:00:08 25167kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 47 00:00:10 33555kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 48 00:00:15 50333kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 49 00:00:20 67110kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 50 00:00:30 100664kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 51 00:00:40 134219kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 52 00:00:59 201328kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 53 00:01:19 268436kN

(, 21.10.2007)

nczempin · Post by **nczempin** » Sun Oct 21, 2007 4:47 pm

Uri Blass wrote:Fruit2.3.1 makes a big blunder in a drawn position
Fruit2.3 also suffers from the same problem.

New game - Fruit 2.3.1

8
7
6
5
4
3
2
1
a b c d e f g h

4K2k/5r1p/7P/8/8/8/B7/6Q1 b - - 0 1

Analysis by Fruit 2.3.1:

1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 1 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 2 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 3 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 4 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 5 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 6 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 7 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 8 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 9 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 10 00:00:00
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 11 00:00:01 1kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 12 00:00:01 1kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 13 00:00:01 1kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 14 00:00:01 1kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 15 00:00:01 1kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 16 00:00:01 1kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 17 00:00:01 2kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 18 00:00:02 2kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 19 00:00:02 3kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 20 00:00:02 4kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 21 00:00:02 5kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 22 00:00:02 7kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 23 00:00:02 9kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 24 00:00:02 13kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 25 00:00:02 17kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 26 00:00:02 25kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 27 00:00:02 33kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 28 00:00:02 50kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 29 00:00:02 66kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 30 00:00:03 99kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 31 00:00:03 132kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 32 00:00:03 197kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 33 00:00:03 263kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 34 00:00:03 394kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 35 00:00:03 525kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 36 00:00:03 787kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 37 00:00:04 1049kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 38 00:00:04 1574kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 39 00:00:04 2098kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 40 00:00:04 3147kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 41 00:00:04 4195kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 42 00:00:05 6292kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 43 00:00:06 8389kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 44 00:00:06 12584kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 45 00:00:07 16778kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 46 00:00:08 25167kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 47 00:00:10 33555kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 48 00:00:15 50333kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 49 00:00:20 67110kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 50 00:00:30 100664kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 51 00:00:40 134219kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 52 00:00:59 201328kN
1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 53 00:01:19 268436kN

(, 21.10.2007)

let's see if all the alleged clones also have this bug

Uri Blass · Post by **Uri Blass** » Sun Oct 21, 2007 5:06 pm

The free source of fruit does not have this bug and fruit2.1 or toga can see the draw.

They have big evaluation advantage for stalemate position at small depths but most programs have this problem and the evaluation of most program does not check if the position is a draw by stalemate.

This behaviour is annoying for analysis because you can never know if big score of the program is not based on stalemate position.

It is pity that most programmers prefer small speed improvement by not having stalemate detection inside the evaluation and it is not a question of one ply(it seems that there are drawn positions when glaurung has more than +9 because of that problem because it seems that glaurung evaluates stalemate position as more than +9 and the search always find way to push the stalemate to bigger distance from the root so glaurung cannot see the draw and can make wrong decisions because of it)

Edit:
Note that in the case of glaurung I believe that Tord is going to fix it and add stalemate detection to his evaluation(this is only a guess and I still did not get a reply from him about glaurung wrong evaluation)

I also may be wrong about the reason of programmers not to have stalemate detection inside their evaluation and the reason may be simply that they were lazy to add it and not speed.

Uri

Roman Hartmann · Post by **Roman Hartmann** » Sun Oct 21, 2007 5:33 pm

Roce has no problem with this position:

Code: Select all

roce: setboard 4K2k/5r1p/7P/8/8/8/B7/6Q1 b - - 0 1

roce: analyze

 D.   Time    Score  Best line
  1   0.00   -7.94   ...  rf7-f3 
  2   0.00   -7.84   ...  rf7-e7+ Ke8-d8 re7-e2 
  3   0.00    0.00   ...  rf7-f8+ Ke8-d7 rf8-f7+ Ba2xf7 
  4   0.00    0.00   ...  rf7-f8+ Ke8xf8 
  5   0.00    0.00   ...  rf7-f8+ Ke8xf8 
  6   0.00    0.00   ...  rf7-f8+ Ke8xf8 
  7   0.00    0.00   ...  rf7-f8+ Ke8xf8 
  8   0.01    0.00   ...  rf7-f8+ Ke8xf8 
  9   0.02    0.00   ...  rf7-f8+ Ke8xf8 
 10   0.04    0.00   ...  rf7-f8+ Ke8xf8 
 11   0.13    0.00   ...  rf7-f8+ Ke8xf8 
 12   0.37    0.00   ...  rf7-f8+ Ke8xf8 
 13   0.91    0.00   ...  rf7-f8+ Ke8xf8

GS · Post by GS » Sun Oct 21, 2007 6:27 pm

nczempin wrote:
Uri Blass wrote:Fruit2.3.1 makes a big blunder in a drawn position
Fruit2.3 also suffers from the same problem.

New game - Fruit 2.3.1

8
7
6
5
4
3
2
1
a b c d e f g h

4K2k/5r1p/7P/8/8/8/B7/6Q1 b - - 0 1

Analysis by Fruit 2.3.1:

...

1...Rf7-f1 2.Qg1-g7#
+- (#1) Depth: 53 00:01:19 268436kN

(, 21.10.2007)
let's see if all the alleged clones also have this bug ;-)

Well, AFAIK the sources of the Fruits since it was commercial
were not released. I don't know though how much people received
them from Ryan.

Guenther

Uri Blass · Post by **Uri Blass** » Sun Oct 21, 2007 7:32 pm

I asked Tord about it and detecting stalemate in the evaluation is not planned in glaurung2 but it is possible that he may add it in future version of glaurung.

Uri

Mike S. · Post by **Mike S.** » Tue Oct 23, 2007 3:18 am

It looks like only 1...Re7+ draws, while 1...Rf8+ gives White a #12.

WinCHEST Ver.3.19f+, 01-Feb-2006
Options = -M64 -Z15 -eL -0 -5 -SUr
Input file: STDIN
Reading job:
% created by ChestUCI Ver.4.4
W: Ke8 Qg1 Ba2 Ph6 (4)
B: Kh8 Rf8 Ph7 (3)
FEN: 4Kr1k/7p/7P/8/8/8/B7/6Q1 w - -
analysing (mate in 15 moves):
Solution (in 12 moves):
e8e7
Time (virt) = 1.420 sec

PV= e8e7 f8e8 e7d6 e8d8 d6c5 d8c8 c5d4 c8d8 a2d5 d8d5 d4c4 d5g5 g1e3 g5g4 c4d5 g4g5 d5e6 g5g6 e6f7 g6f6 f7f6 h8g8 e3e8

Or by Fruit 051103, 2 variations mode:

Engine: Fruit 51103
von Fabien Letouzey
14 0:00 0.00 1...Te7+ 2.Kd8 Td7+ 3.Kc8 Tc7+ 4.Kb8 Tb7+ 5.Ka8 Ta7+ 6.Kxa7 (489.531)
LT: 13 0:00 -13.52 1...Tf8+ 2.Ke7 Te8+ 3.Kd6 Td8+ 4.Ke5 Te8+ 5.Kd4 Td8+ 6.Ke4 Te8+ 7.Kd3 Td8+ 8.Kc4 Tc8+ 9.Kb4 Tb8+ 10.Kc5 Tc8+ 11.Kd5 Td8+ 12.Ke6 Te8+ 13.Kd7 Td8+ 14.Kxd8 (487.817)
-----
14 0:00 0.00 1...Te7+ 2.Kd8 Td7+ 3.Kc8 Tc7+ 4.Kb8 Tb7+ 5.Ka8 Ta7+ 6.Kxa7 (489.531) 965.0
14 0:02 -M12 1...Tf8+ 2.Ke7 Te8+ 3.Kd6 Td8+ 4.Kc5 Tc8+ 5.Kd4 Td8+ 6.Ld5 Txd5+ 7.Kc4 Tg5 8.De3 Tg4+ 9.Kd5 Tg5+ 10.Ke6 Tg6+ 11.Kf7 Tf6+ 12.Kxf6 Kg8 13.De8+ (2.162.670) 965.0
(...)
23 0:10 0.00 1...Te7+ 2.Kd8 Td7+ 3.Kc8 Tc7+ 4.Kb8 Tb7+ 5.Ka8 Ta7+ 6.Kxa7 (18.709.134) 1836.9
LT: 22 0:10 -M12 1...Tf8+ 2.Ke7 Te8+ 3.Kd6 Td8+ 4.Kc5 Tc8+ 5.Kd4 Td8+ 6.Ld5 Txd5+ 7.Kc4 Tg5 8.De3 Tg4+ 9.Kd5 Tg5+ 10.Ke6 Tg6+ 11.Kf7 Tf6+ 12.Kxf6 Kg8 13.De8+ (18.685.005) 1836.9
Bester Zug: Tf7-e7 Zeit: 0:11.047 min K/s: 1.922.694 CPU 100.0% Knoten: 21.240.000 TB: 11.618

It is astonishing how quickly it finds the #12 (cpu D945, 3.4 GHz). Tablebases support was with 4-piece tbs., only.

So Fruit 051103 has no problem here, and has produced the same variation Chest has found in the position after Rf8, in self-play:

[Event "?"]
[Site "?"]
[Date "2007.10.23"]
[Round "?"]
[White "Fruit 051103"]
[Black "Fruit 051103"]
[Result "1-0"]
[SetUp "1"]
[FEN "4K2k/5r1p/7P/8/8/8/B7/6Q1 b - -"]

1... Rf8+ {entered manually} 2. Ke7 {+M12/20 14s} Re8+ {-M11/23 5s}
3. Kd6 {+M11/27 5s} Rd8+ {-M10/45 5s} 4. Kc5 {+M10/54 6s}
Rc8+ {-M9/55 6s} 5. Kd4 {+M9/55 6s} Rd8+ {-M8/54 6s} 6. Bd5
{+M8/54 6s} Rxd5+ {-M7/53 5s} 7. Kc4 {+M7/53 5s} Rg5
{-M6/52 5s} 8. Qe3 {+M6/51 6s} Rg4+ {-M5/50 5s} 9. Kd5
{+M5/50 5s} Rg5+ {-M4/49 5s} 10. Ke6 {+M4/49 5s} Rg6+
{-M3/48 6s} 11. Kf7 {+M3/48 5s} Rf6+ {-M2/47 5s} 12. Kxf6
{+M2/45 2s} Kg8 {-M1/4 0s} 13. Qe8# {+M1/45 5s} 1-0

Fruit2.3.1 stalemate bug

Fruit2.3.1 stalemate bug

Re: Fruit2.3.1 stalemate bug

Re: Fruit2.3.1 stalemate bug

Re: Fruit2.3.1 stalemate bug

Re: Fruit2.3.1 stalemate bug

Re: Fruit2.3.1 stalemate bug

Re: Fruit2.3.1 stalemate bug