Fruit bug?

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Rebel, chrisw

JohnWoe
Posts: 491
Joined: Sat Mar 02, 2013 11:31 pm

Fruit bug?

Post by JohnWoe »

This position seems difficult for Fruit 2.1

Only underpromotion to knight wins.

[d]2n5/kP6/8/K7/4B3/8/8/8 w - - 0

Fruit 2.1 analysis: =B and +8

Code: Select all

26	+8,09 	137,1M	0:42.62	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6f5 Ke5 Kc5 Kf6 Kd6 Kf7 Ke5 Ke8 Kd5 Kd8 Kd6 Ke8 Bd7+ Kd8 Be6 Ke8 B4f5 Kd8 Bd5 Ke8 Ke5
 25	+8,09 	106,1M	0:32.99	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6f5 Ke5 Kc5 Kf6 Kd6 Kf7 Ke5 Ke8 Kd5 Kd8 Be6 Kc7 Kc5 Kd8 Kd6 Ke8 Kd5 Kd8 Kd4
 24	+8,09 	81,5M  	0:25.32	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6f5 Ke5 Kc5 Kf6 Kd6 Kf7 Ke5 Ke8 Kd5 Kd8 Kd6 Ke8 Bd7+ Kd8 Be6 Ke8 Kd5 Kd8 Kd4
 23	+8,09 	63,5M  	0:19.66	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6f5 Ke5 Kc5 Kf6 Kd6 Kf7 Ke5 Ke8 Kd5 Kd8 Be6 Kc7 Kc5 Kd8 Kd6 Ke8 Ke5
 22	+8,09 	47,9M  	0:14.76	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6f5 Ke5 Kc5 Kf6 Kd6 Kf7 Ke5 Ke8 Kd5 Kd8 Kd6 Ke8 Bd7+ Kd8 Be6 Ke8 Ke5
 21	+8,09 	37,3M  	0:11.49	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6f5 Ke5 Kc5 Kf6 Kd6 Kf7 Ke5 Ke8 Kd5 Kf7 Kd6 Ke8 Bd5 Kd8 Ke5
 20	+8,02 	29,2M  	0:08.99	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6f5 Ke5 Kc5 Kf4 Kd4 Kg5 Ke5 Kh5 Bd7 Kh4 Kf4 Kh5 Be6 Kh4
 19	+8,09 	16,4M  	0:05.09	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6f5 Ke5 Kc5 Kf4 Kd4 Kg5 Ke5 Kh5 Be6 Kg5 B4f5 Kh5 Bd5
 18	+7,98 	11,4M  	0:03.57	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6f5 Ke5 Kc5 Kf4 Kd4 Kg5 Ke5 Kh5 Kf4 Kh6 Bd5 Kg7
 17	+7,96 	8,48M  	0:02.67	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6f5 Ke5 Kc5 Kf6 Kd4 Ke7 Ke5 Kf7 Bd5+ Ke7 Bg4 Kd8
 16	+7,87 	5,64M  	0:01.77	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6d5 Ke5 Kc5 Kf4 Kd4 Kg3 Bf5 Kf4 Bd3 Kg5
 15	+7,87 	3,50M  	0:01.11	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6d5 Ke5 Kc5 Kf4 Kd4 Kg3 Ke5 Kg4 Bf5+ Kg5
 14	+7,79 	1,82M  	0:00.58	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6d5 Ke5 Kc5 Kf4 Kd4 Kg3 Be6 Kf4
 13	+7,87 	1,01M  	0:00.32	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6d5 Ke5 Kc5 Kf4 Kd4 Kg5 Be6
 12	+7,61 	525604	0:00.17	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6d5 Ke5 Kc5 Kf4 Kd4 Kg5
 11	+7,69 	264065	0:00.09	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6d5 Ke5 Kc5 Kf4 Bd3
 10	+7,42 	139479	0:00.05	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 B6d5 Ke5 Kc5 Kf4
  9	+7,34 	67250  	0:00.02	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 Bc4 Ke5 Bf3
  8	+7,50 	29383  	0:00.01	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 Bc4 Ke5
  7	+7,60 	15557  	0:00.00	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6 Bc4
  6	+7,60 	5772    	0:00.00	bxc8=B Kb8 Be6 Kc7 Kb4 Kd6
  5	+7,79 	2284    	0:00.00	bxc8=B Kb8 Be6 Kc7 Kb4
  4	+7,55 	919      	0:00.00	bxc8=B Kb8 Be6 Kc7
  3	+7,86 	352      	0:00.00	bxc8=B Kb8 Be6
  2	+7,54 	142      	0:00.00	bxc8=B Kb8
  2	  0.00 	137      	0:00.00	bxc8=Q
  1	+14,14 	2          	0:00.00	bxc8=Q
  0	#
[pgn][Event "Computer Chess Game"]
[Site "pc"]
[Date "2021.02.09"]
[Round "-"]
[White "Fruit 2.1"]
[Black "Stockfish 12"]
[Result "1/2-1/2"]
[TimeControl "60+3"]
[FEN "2n5/kP6/8/K7/4B3/8/8/8 w - - 0 1"]
[SetUp "1"]

{--------------
. . n . . . . .
k P . . . . . .
. . . . . . . .
K . . . . . . .
. . . . B . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
white to play
--------------}
1. bxc8=B {+7,83/14}
{Xboard adjudication: Insufficient mating material} 1/2-1/2

[/pgn]

Mayhem:

Code: Select all

 21	+14,28 	522,5M	1:05.47	bxc8=N+
 20	+14,26 	245,3M	0:30.74	bxc8=N+
 19	+13,79 	101,8M	0:12.76	bxc8=N+
 18	+13,79 	54,7M  	0:06.78	bxc8=N+
 17	+14,26 	15,6M  	0:02.00	bxc8=N+
 16	+14,07 	7,65M  	0:00.99	bxc8=N+
 15	+13,79 	3,05M  	0:00.40	bxc8=N+
 14	+13,79 	1,81M  	0:00.25	bxc8=N+
 13	+14,26 	871909	0:00.12	bxc8=N+
 12	+13,73 	503846	0:00.07	bxc8=N+
 11	+13,53 	154883	0:00.03	bxc8=N+
 10	+13,53 	69272  	0:00.01	bxc8=N+
  9	+13,82 	28133  	0:00.01	bxc8=N+
  8	+13,82 	12062  	0:00.00	bxc8=N+
  7	+14,37 	7075    	0:00.00	bxc8=N+
  6	+14,12 	3857    	0:00.00	bxc8=N+
  5	+14,23 	1148    	0:00.00	bxc8=N+
  4	+14,09 	855      	0:00.00	bxc8=N+
  3	+16,57 	452      	0:00.00	bxc8=N+
  2	+16,47 	122      	0:00.00	bxc8=N+
  1	+20,45 	44        	0:00.00	bxc8=Q
  0	#
Fairymax struggles also:

Code: Select all

mover viewpoint		fewer / Multi-PV margin = 0 / more
exclude: none best +tail                                          
dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
 20	+0,35 	10,8M  	0:10.11	a5b5 c8d6 b5c6 d6b7 e4f5 b7a5 c6b5 a5b7 f5d3 b7d8 b5c5 a7b7 c5d6 b7b6 d3e4 d8f7 d6d5 f7g5 e4f5 b6b5 
 19	+0,34 	3,96M  	0:03.65	a5b5 c8d6 b5c6 d6b7 e4d5 b7a5 c6b5 a5b7 d5f3 b7d8 f3g4 a7b7 b5c5 b7c7 c5d5 d8b7 g4f5 b7d6 f5e6 
 18	+0,36 	1,23M  	0:01.11	a5b5 c8d6 b5c6 d6b7 e4d5 b7a5 c6b5 a5b7 d5f3 a7b8 b5c6 b7a5 c6d6 
 17	+0,36 	249829	0:00.24	a5b5 
 16	+0,36 	136949	0:00.13	a5b5 
 15	+0,36 	76609  	0:00.07	a5b5 
 14	+0,36 	51258  	0:00.04	a5b5 
 13	+0,36 	38700  	0:00.03	a5b5 
 12	+0,36 	38698  	0:00.03	a5b5 
 12	+0,34 	16842  	0:00.01	e4d5 c8d6 a5b4 d6b7 b4b5 b7d6 b5c6 d6f5 d5e4 f5e3 c6c5 a7a6 
 11	+0,37 	7848    	0:00.00	e4d5 c8d6 a5b4 d6b7 b4b5 b7d6 b5c5 d6b7 c5c4 a7b6 d5f3 
 10	+0,38 	6650    	0:00.00	e4d5 c8d6 a5b4 d6b7 b4b5 
 10	+0,37 	5999    	0:00.00	e4f3 c8d6 f3d5 d6b7 a5b5 b7d6 b5c5 d6b7 c5c4 a7b6 
  9	+0,36 	2494    	0:00.00	e4f3 c8d6 a5b4 d6b7 b4b5 b7d8 f3d5 d8b7 
  8	+0,38 	1981    	0:00.00	e4f3 c8d6 a5b4 d6b7 b4b5 b7d6 b5c5 d6f7 
  7	+0,36 	508      	0:00.00	e4f3 c8d6 a5b4 d6b7 b4c4 a7b6 f3g4 
  6	+0,36 	305      	0:00.00	e4f3 c8d6 a5b4 d6b7 b4c4 a7b6 
  5	+0,39 	174      	0:00.00	e4f3 c8d6 a5b4 d6b7 f3e2 
  4	+0,41 	103      	0:00.00	e4f3 c8d6 a5b4 d6b7 
  3	+0,41 	89        	0:00.00	e4f3 c8d6 a5b4 d6b7 
  3	+0,36 	77        	0:00.00	e4d5 c8d6 a5a4 d6b7 
  2	+2,25 	36        	0:00.00	e4d5 c8d6 
  2	+2,23 	29        	0:00.00	e4f3 c8d6 
  2	+0,37 	14        	0:00.00	b7b8 a7b8 
  2	  0.00 	9          	0:00.00	b7c8 
  1	+11,53 	7          	0:00.00	b7c8 
mar
Posts: 2555
Joined: Fri Nov 26, 2010 2:00 pm
Location: Czech Republic
Full name: Martin Sedlak

Re: Fruit bug?

Post by mar »

What bug? Fruit simply lacks knowledge that multiple bishops on same-colored squares are worthless and cannot deliver a checkmate.
Piece of cake for bitboard engines.

Not what I'd call a bug, simply missing knowledge.
Were it a true bishop pair then it would win this type of endgame much faster than a knight+bishop.

Not to mention that this position seems artificial to me - did it happen in a real game?
Martin Sedlak
User avatar
hgm
Posts: 27796
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Fruit bug?

Post by hgm »

Piece of cake for mailbox engines too. Just make light and dark Bishops different piece types, so they give different contributions to the material key.

In KingSlayer-CwDA I don't do that, btw, because there can be other color-bound pieces than Bishops, and there can be even entirely different types of 'area binding' (such as to odd vs even files). So I use a more general method there, which is not entirely free, but still very cheap: rather than having a material key that is the sum of all the matKey[piece], KingSlayer-CwDA uses matKey[piece][sqr] like for the main hash key. (Except that it is an additive key rather than an XOR key, to allow multiple contributions from a same piece type without these cancelling each other.)

This can handle any type of area binding: you just fill each area entirely with the same random key. For most pieces that means the value for every square is the same, but for Bishops you use two keys, one for the light squares, the other for the dark. You could also use one key for the even files, another for the odd files, etc. For Pawns you could use a different key for the a- and h-file, so that your material signature automatically distinguishes Rook Pawns from other Pawns.

Since for color or file binding the fill pattern is a repetitive tiling, it would be enough to only use the least-significant bits of file and rank number from the square number, to reduce the required number of keys per piece to 2x2. For most numbering systems these bits would be easy to extract; e.g. with 0-63 numbering you would AND with 9, for 0x88 numbering with 17. That would probe only 4 elements of the key tables for each piece, which are not contiguous, but could be interleaved for the various piece types, so that there still is no wasting of cache space. The Rook-Pawn trick would then not work anymore, though(unless you pass all bits of the file number, and only the LSB of the rank number).
Colin-G
Posts: 191
Joined: Mon Oct 31, 2016 6:30 pm
Location: England

Re: Fruit bug?

Post by Colin-G »

Just use the later Fruit 3.2.1 instead.
Version 3.2.1 uses Tablebases and has no problem with the position shown.
User avatar
CMCanavessi
Posts: 1142
Joined: Thu Dec 28, 2017 4:06 pm
Location: Argentina

Re: Fruit bug?

Post by CMCanavessi »

Colin-G wrote: Tue Feb 09, 2021 2:05 pm Just use the later Fruit 3.2.1 instead.
Version 3.2.1 uses Tablebases and has no problem with the position shown.
Fruit 2.3.1 doesn't solve it either
Fruit reloaded 3.2.1 does solve it instantly, even without TBs
Follow my tournament and some Leela gauntlets live at http://twitch.tv/ccls
User avatar
Ajedrecista
Posts: 1969
Joined: Wed Jul 13, 2011 9:04 pm
Location: Madrid, Spain.

Re: Fruit bug?

Post by Ajedrecista »

Hello Martin:
mar wrote: Tue Feb 09, 2021 8:49 am[...]

Not to mention that this position seems artificial to me - did it happen in a real game?
This position is from an old test suite. Searching in order to answer you, I first found the position here:

Other Misc. Combinations UskiEG.26

The TalkChess member Jouni posted it at old CCC at least in 1998:

Subject: 24 interesting endgame positions

Then I found other extended versions:

http://www.geocities.ws/lyapko/uski.htm
Download EPD

I think that there are tools like pgn-extract that can search certain FEN strings and patterns in a PGN. These kind of positions can be more difficult to find in engine-engine games if there are EGTB adjudications.

Regards from Spain.

Ajedrecista.
JohnWoe
Posts: 491
Joined: Sat Mar 02, 2013 11:31 pm

Re: Fruit bug?

Post by JohnWoe »

I called this bug. Lacking a better word...

Because Fruit has underpromoted to knight and saved a draw vs Mayhem.
When Mayhem was buggy...
Ajedrecista wrote: Tue Feb 09, 2021 6:32 pm Hello Martin:
mar wrote: Tue Feb 09, 2021 8:49 am[...]

Not to mention that this position seems artificial to me - did it happen in a real game?
This position is from an old test suite. Searching in order to answer you, I first found the position here:

Other Misc. Combinations UskiEG.26

The TalkChess member Jouni posted it at old CCC at least in 1998:

Subject: 24 interesting endgame positions

Then I found other extended versions:

http://www.geocities.ws/lyapko/uski.htm
Download EPD

I think that there are tools like pgn-extract that can search certain FEN strings and patterns in a PGN. These kind of positions can be more difficult to find in engine-engine games if there are EGTB adjudications.

Regards from Spain.

Ajedrecista.
Exactly! It's from CPW -> test positions -> what you pasted.
I use this as test position. Underpromotion to a knight which checks is the only underpromo I care about.
hgm wrote: Tue Feb 09, 2021 10:19 am Piece of cake for mailbox engines too. Just make light and dark Bishops different piece types, so they give different contributions to the material key.

In KingSlayer-CwDA I don't do that, btw, because there can be other color-bound pieces than Bishops, and there can be even entirely different types of 'area binding' (such as to odd vs even files). So I use a more general method there, which is not entirely free, but still very cheap: rather than having a material key that is the sum of all the matKey[piece], KingSlayer-CwDA uses matKey[piece][sqr] like for the main hash key. (Except that it is an additive key rather than an XOR key, to allow multiple contributions from a same piece type without these cancelling each other.)

This can handle any type of area binding: you just fill each area entirely with the same random key. For most pieces that means the value for every square is the same, but for Bishops you use two keys, one for the light squares, the other for the dark. You could also use one key for the even files, another for the odd files, etc. For Pawns you could use a different key for the a- and h-file, so that your material signature automatically distinguishes Rook Pawns from other Pawns.

Since for color or file binding the fill pattern is a repetitive tiling, it would be enough to only use the least-significant bits of file and rank number from the square number, to reduce the required number of keys per piece to 2x2. For most numbering systems these bits would be easy to extract; e.g. with 0-63 numbering you would AND with 9, for 0x88 numbering with 17. That would probe only 4 elements of the key tables for each piece, which are not contiguous, but could be interleaved for the various piece types, so that there still is no wasting of cache space. The Rook-Pawn trick would then not work anymore, though(unless you pass all bits of the file number, and only the LSB of the rank number).
Thanks.
This is a good trick: color-bound pieces handled as different pieces.
User avatar
Ajedrecista
Posts: 1969
Joined: Wed Jul 13, 2011 9:04 pm
Location: Madrid, Spain.

Re: Fruit bug?

Post by Ajedrecista »

Hello again:
JohnWoe wrote: Tue Feb 09, 2021 6:57 pm[...] Underpromotion to a knight which checks is the only underpromo I care about. [...]
Widely known, but Lasker Trap is perfect for you.

[d]rnbqk1nr/ppp2ppp/8/4P3/1BP5/8/PP2KpPP/RN1Q1BNR b kq - 1 7

28 pieces on the chessboard to test your engine.

Regards from Spain.

Ajedrecista.