test position tablebase bug

[Uri Blass]

Fruit2.3.1 failed to implement tablebases correctly and cannot see that Rxb2 is losing against 0-0-0+

Same is for many other programs.

New game - Movei00_8_438, Friend mode
[d]8/8/8/8/8/8/1Nr3P1/R3K1k1 b Q - 0 1

Analysis by Fruit 2.3.1:

1...Rc2xb2
= (0.00) Depth: 1 00:00:01
1...Rc2xb2
= (0.00) Depth: 3 00:00:01
1...Rc2xb2
= (0.00) Depth: 3 00:00:01
1...Rc2xb2
= (0.00) Depth: 4 00:00:01
1...Rc2xb2
= (0.00) Depth: 5 00:00:01
1...Rc2xb2
= (0.00) Depth: 6 00:00:01 1kN
1...Rc2xb2
= (0.00) Depth: 7 00:00:01 1kN, tb=152
1...Rc2xb2
= (0.00) Depth: 8 00:00:01 1kN, tb=153
1...Rc2xb2
= (0.00) Depth: 9 00:00:01 1kN, tb=154
1...Rc2xb2
= (0.00) Depth: 10 00:00:01 2kN, tb=157
1...Rc2xb2
= (0.00) Depth: 11 00:00:01 3kN, tb=160
1...Rc2xb2
= (0.00) Depth: 12 00:00:01 5kN, tb=164
1...Rc2xb2
= (0.00) Depth: 13 00:00:01 7kN, tb=168
1...Rc2xb2
= (0.00) Depth: 14 00:00:01 10kN, tb=172
1...Rc2xb2
= (0.00) Depth: 15 00:00:01 14kN, tb=187
1...Rc2xb2
= (0.00) Depth: 16 00:00:01 20kN, tb=207
1...Rc2xb2
= (0.00) Depth: 17 00:00:01 26kN, tb=237
1...Rc2xb2
= (0.00) Depth: 18 00:00:01 33kN, tb=280
1...Rc2xb2
= (0.00) Depth: 19 00:00:01 43kN, tb=318
1...Rc2xb2
= (0.00) Depth: 20 00:00:01 54kN, tb=365
1...Rc2xb2
= (0.00) Depth: 21 00:00:01 71kN, tb=417
1...Rc2xb2
= (0.00) Depth: 22 00:00:02 89kN, tb=510
1...Rc2xb2
= (0.00) Depth: 23 00:00:02 113kN, tb=623
1...Rc2xb2
= (0.00) Depth: 24 00:00:02 136kN, tb=760
1...Rc2xb2
= (0.00) Depth: 25 00:00:02 164kN, tb=920
1...Rc2xb2
= (0.00) Depth: 26 00:00:02 193kN, tb=1080
1...Rc2xb2
= (0.00) Depth: 27 00:00:02 226kN, tb=1273
1...Rc2xb2
= (0.00) Depth: 28 00:00:02 270kN, tb=1477
1...Rc2xb2
= (0.00) Depth: 29 00:00:02 322kN, tb=1743
1...Rc2xb2
= (0.00) Depth: 30 00:00:02 379kN, tb=2022
1...Rc2xb2
= (0.00) Depth: 31 00:00:03 443kN, tb=2396
1...Rc2xb2
= (0.00) Depth: 32 00:00:03 537kN, tb=2919
1...Rc2xb2
= (0.00) Depth: 33 00:00:03 642kN, tb=3482
1...Rc2xb2
= (0.00) Depth: 34 00:00:03 781kN, tb=4173
1...Rc2xb2
= (0.00) Depth: 35 00:00:04 952kN, tb=4977
1...Rc2xb2
= (0.00) Depth: 36 00:00:04 1140kN, tb=5912
1...Rc2xb2
= (0.00) Depth: 37 00:00:05 1348kN, tb=7016
1...Rc2xb2
= (0.00) Depth: 38 00:00:05 1598kN, tb=8143
1...Rc2xb2
= (0.00) Depth: 39 00:00:05 1834kN, tb=9348
1...Rc2xb2
= (0.00) Depth: 40 00:00:05 2155kN, tb=10743
1...Rc2xb2
= (0.00) Depth: 41 00:00:06 2575kN, tb=12497
1...Rc2xb2
= (0.00) Depth: 42 00:00:07 3050kN, tb=14316
1...Rc2xb2
= (0.00) Depth: 43 00:00:07 3629kN, tb=16351
1...Rc2xb2
= (0.00) Depth: 44 00:00:08 4286kN, tb=18787
1...Rc2xb2
= (0.00) Depth: 45 00:00:08 5019kN, tb=21407
1...Rc2xb2
= (0.00) Depth: 46 00:00:09 5776kN, tb=24154
1...Rc2xb2
= (0.00) Depth: 47 00:00:10 6733kN, tb=27541
1...Rc2xb2
= (0.00) Depth: 48 00:00:11 7830kN, tb=31417
1...Rc2xb2
= (0.00) Depth: 49 00:00:11 9009kN, tb=34970
1...Rc2xb2
= (0.00) Depth: 50 00:00:13 10829kN, tb=40549
1...Rc2xb2
= (0.00) Depth: 51 00:00:14 12857kN, tb=46538
1...Rc2xb2
= (0.00) Depth: 52 00:00:16 14613kN, tb=52308
1...Rc2xb2
= (0.00) Depth: 53 00:00:18 17668kN, tb=60824
1...Rc2xb2
= (0.00) Depth: 54 00:00:20 20403kN, tb=68839
1...Rc2xb2
= (0.00) Depth: 55 00:00:22 23235kN, tb=76941
1...Rc2xb2
= (0.00) Depth: 56 00:00:24 26929kN, tb=87135
1...Rc2xb2
= (0.00) Depth: 57 00:00:27 31416kN, tb=99253
1...Rc2xb2
= (0.00) Depth: 58 00:00:30 35717kN, tb=110668
1...Rc2xb2
= (0.00) Depth: 59 00:00:35 41512kN, tb=125657
1...Rc2xb2
= (0.00) Depth: 60 00:00:39 46666kN, tb=140450
1...Rc2xb2
= (0.00) Depth: 61 00:00:44 53129kN, tb=158129
1...Rc2xb2
= (0.00) Depth: 62 00:00:49 61066kN, tb=178554
1...Rc2xb2
= (0.00) Depth: 63 00:00:56 70778kN, tb=203239

(, 13.09.2007)

[BBauer]

Yes,
and after you play Rc2xb2 it sees immediately that it is mated!
Minor bug, but yace, frencee, zappa see the draw.

regards
Bernhard

[ernest]

Fruit2.3.1 failed to implement tablebases correctly and cannot see that Rxb2 is losing against 0-0-0+

Same is for many other programs.

Indeed same for Rybka 2.3.2a (with Nalimov all 5)

[genorb]

Hi Uri,

is this only a problem with 5-men tablebases? Because I paste your FEN into the Shredder GUI (256Mb for the Hash and 3 and 4-men tablebases only) and I get those results (analysis are in french so R=Roi=King)

I use default setting for all engines

Fruit 2.3.1

5.00 0:00 +0.35 1...Rxg2 2.Cd3 Rf3 3.Rd1 Te2 4.Ta4 (2.140) TB:84
6.00 0:00 +0.38 1...Rxg2 2.Cd3 Rf3 3.Rd1 Th2 4.Ta4 Re3 (3.224) TB:86
7.00 0:00 +0.36 1...Rxg2 2.Cd3 Rf3 3.Rd1 Th2 4.Ta4 Re3 5.Ce5 (5.438) TB:105
8.00 0:00 +0.36 1...Rxg2 2.Cd3 Rf3 3.Rd1 Th2 4.Ta4 Re3 5.Ce5 Td2+ 6.Re1 (9.397) TB:108
9.00 0:00 +0.36 1...Rxg2 2.Cd3 Rf3 3.Rd1 Th2 4.Ta4 Re3 5.Ce5 Td2+ 6.Re1 Te2+ 7.Rf1 Tf2+ 8.Re1 (15.710) TB:112
10.00 0:00 +0.37 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Re4 4.Ce3 Th2 5.Cg4 Tb2 6.Ta4+ Rd5 7.Ce3+ Rc5 8.Tc4+ Rd6 (32.428) TB:115
11.00 0:00 +0.38 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Rg4 5.Ta4+ Rg5 6.Cd5 Th2 7.Ta3 Tb2 8.Tg3+ Rf5 (77.393) TB:218
12.00 0:00 +0.41 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Rg4 5.Ce2 Tc4 6.Rf2 Te4 7.Ta5 Te6 8.Ta4+ Rg5 (148.887) TB:303
13.00 0:00 +0.41 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Rg4 5.Ce2 Tc4 6.Rf2 Te4 7.Ta5 Te6 8.Cc3 Tf6+ 9.Re3 (230.508) TB:440
14.00 0:00 +0.41 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Rf3 5.Ce2+ Re4 6.Rf2 Tc4 7.Te3+ Rf5 8.Te8 Rf6 9.Re3 Tc7 10.Cf4 (368.072) TB:504
15.00 0:00 +0.41 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Re5 5.Ce2 Tb2 6.Rf2 Td2 7.Re3 Td1 8.Ta5+ Td5 9.Ta4 Td1 10.Te4+ Rf6 (577.440) TB:708
16.00 0:00 +0.41 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Tb2 5.Ce2+ Re4 6.Rf2 Tb4 7.Ta6 Tb2 8.Ta4+ Re5 9.Ta3 Re4 10.Th3 Td2 11.Th4+ Re5 12.Th5+ Re4 (892.737) TB:943
17.00 0:00 +0.41 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Tb2 5.Ce2+ Re4 6.Rf2 Tb4 7.Ta6 Tb2 8.Ta4+ Re5 9.Ta3 Re4 10.Te3+ Rf5 11.Rf3 Td2 12.Cg3+ Rg6 (1.284.301) TB:1.178
18.00 0:01 +0.42 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Tb2 5.Ce2+ Re4 6.Rf2 Tb4 7.Ta6 Tb2 8.Ta4+ Re5 9.Ta3 Re4 10.Te3+ Rf5 11.Rf3 Td2 12.Cg3+ Rg6 13.Te6+ Rf7 (2.088.106) 1590 TB:1.496
19.01 0:01 +0.42 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Tb2 5.Ce2+ Re4 6.Rf2 Tb4 7.Te3+ Rf5 8.Rf3 Rf6 9.Cf4 Rf5 10.Cd3 Tb5 11.Re2 Tb1 12.Tf3+ Rg5 13.Tg3+ Rf5 (3.169.707) 1639 TB:1.644
20.01 0:02 +0.42 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Tb2 5.Ce2+ Re4 6.Rf2 Tb4 7.Te3+ Rf5 8.Rf3 Th4 9.Cg3+ Rf6 10.Te1 Td4 11.Ce4+ Rf5 12.Cc5 Tc4 13.Th1 Tc3+ 14.Re2 Tc2+ (4.498.710) 1674 TB:1.974
21.01 0:05 +0.43 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Tb2 5.Ce2+ Re4 6.Rf2 Tb4 7.Te3+ Rf5 8.Rf3 Th4 9.Te8 Ta4 10.Tf8+ Re6 11.Cc3 Ta3 12.Tc8 Rd7 13.Tc5 Re6 14.Tc6+ Re5 (9.062.129) 1736 TB:3.225
22.01 0:07 +0.43 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Tb2 5.Ce2+ Re4 6.Rf2 Tb4 7.Te3+ Rd5 8.Rf3 Rc5 9.Cf4 Tb8 10.Td3 Rc4 11.Td6 Rc5 12.Td5+ Rc4 13.Ta5 Te8 14.Ta6 Rc5 (13.648.223) 1744 TB:4.092
23.01 0:11 +0.43 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Tb2 5.Ce2+ Re4 6.Rf2 Tb8 7.Te3+ Rf5 8.Cd4+ Rf4 9.Re2 Ta8 10.Te7 Ta2+ 11.Rd3 Ta3+ 12.Rc4 Ta4+ 13.Rc3 Ta1 14.Rb4 Ta6 (20.938.685) 1761 TB:6.212
24.01 0:22 +0.43 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Th2 5.Ce2+ Re5 6.Rd2 Rd5 7.Tg3 Rc4 8.Re3 Th8 9.Tg4+ Rc5 10.Cf4 Te8+ 11.Rd2 Rd6 12.Tg6+ Re5 13.Cd3+ Rd5 14.Tg5+ Rd6 (40.559.314) 1781 TB:11.764
25.01 0:27 +0.43 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Th2 5.Ce2+ Re5 6.Rd2 Rd5 7.Tg3 Th1 8.Re3 Te1 9.Tg8 Re5 10.Te8+ Rd6 11.Td8+ Re5 12.Tc8 Th1 13.Cf4 Te1+ 14.Rd2 Th1 (49.746.461) 1791 TB:15.267

Rybka 2.3.2a

UCI_AnalyseMode set to true
5.00 0:00 +0.04 1...Rxg2 2.Ta3 (1.227) 1256
6.00 0:00 +0.04 1...Rxg2 2.Ta3 Txb2 (1.663) 100
7.00 0:00 +0.04 1...Rxg2 2.Ta3 Txb2 3.Td3 (2.922) 176
8.00 0:00 0.00 1...Rxg2 2.Ta3 Txb2 3.Td3 (4.785) 102
9.00 0:00 0.00 1...Rxg2 2.Ta3 Txb2 3.Td3 (7.354) 95 TB:1
10.00 0:00 +0.01 1...Rxg2 2.Cd3 Rf3 3.Rd1 Th2 4.Ta4 Re3 (12.396) 100 TB:3
11.00 0:00 0.00 1...Rxg2 2.Cd3 Rf3 3.Rd1 Th2 4.Ta4 Re3 5.Cc5 (20.129) 109 TB:7
12.00 0:00 0.00 1...Rxg2 2.Cd3 Rf3 3.Rd1 Th2 4.Ta4 Re3 5.Cc5 Td2+ 6.Rc1 (30.866) 112 TB:14
13.00 0:00 +0.01 1...Rxg2 2.Cd3 Rf3 3.Rd1 Th2 4.Ta4 Re3 5.Cc5 Td2+ 6.Rc1 Th2 (53.060) 115 TB:30
14.00 0:01 +0.08 1...Rxg2 2.Cd3 Rf3 3.Rf1 Th2 4.Ce1+ Re3 5.Cg2+ Rf3 6.Ta3+ Re4 7.Rg1 Th8 8.Ta4+ (134.852) 103 TB:66
15.01 0:02 +0.10 1...Rxg2 2.Cd3 Rf3 3.Rf1 Re4 4.Cf2+ Re3 5.Ta3+ Rd4 6.Rg2 Tc3 7.Ta4+ Tc4 8.Ta8 (255.232) 102 TB:128
16.01 0:04 +0.11 1...Rxg2 2.Cd3 Rf3 3.Rf1 Re4 4.Cf2+ Re3 5.Ta3+ Rd4 6.Rg2 Tc3 7.Ta4+ Tc4 8.Ta8 (387.360) 97 TB:262
17.01 0:05 +0.11 1...Rxg2 2.Cd3 Rf3 3.Rf1 Re4 4.Cf2+ Re3 5.Ta3+ Rd4 6.Rg2 Tc3 7.Ta4+ Tc4 8.Ta8 (481.805) 97 TB:423
18.01 0:14 +0.18 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Th2 5.Ce2+ Re4 6.Rd2 Rd5 7.Tg3 Rc4 8.Re3 (1.374.678) 99 TB:1.294
19.01 0:17 +0.18 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Th2 5.Ce2+ Re4 6.Rd2 Rd5 7.Tg3 Rc4 8.Re3 (1.684.207) 101 TB:1.806
20.01 0:19 +0.18 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cc3 Th2 5.Ce2+ Re4 6.Rd2 Rd5 7.Tg3 Rc4 8.Re3 (1.989.480) 102 TB:2.539

Hiarcs 11.2

13/28 0:00 +0.27 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Rf1 Th2 5.Cf2 (386.483) 747 TB:2.970
13/28 0:00 +0.34 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Rf1 Th2 5.Cf2 Th6 6.Ch3+ Re4 7.Re2 Re5 8.Ta5+ Rd4 9.Cf2 Te6+ (449.217) 735 TB:3.397
14/30 0:00 +0.35 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Rf1 Th2 5.Cf2 Th7 6.Ch3+ Re5 7.Rg2 Rf5 8.Tf3+ Re5 9.Te3+ Rf5 10.Tf3+ (691.606) 762 TB:4.983
15/33 0:02 +0.32 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Rf1 Tc1 5.Re2 Tc2+ 6.Rd3 Tc8 7.Ce3 Rf3 8.Rd4 Td8+ 9.Cd5+ Rg4 10.Td3 Rf5 (2.050.621) 785 TB:13.602
16/34 0:03 +0.39 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cf2 Tc8 5.Rf1 Tb8 6.Cd3+ Rf3 7.Ce1+ Rg4 8.Rf2 (3.190.373) 806 TB:20.989
17/34 0:08 +0.41 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cf2 Tc8 5.Ch3+ Rg4 6.Rf1 Tg8 7.Rg2 Rh5+ 8.Rh2 Rg6 9.Tg3+ Rf7 10.Cg5+ Re7 11.Rg2 Tc8 (6.579.748) 812 TB:43.488
18/37 0:13 +0.41 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cf2 Tc8 5.Ch3+ Rg4 6.Rf1 Tg8 7.Re2 Te8+ 8.Rf2 Tb8 9.Rg2 Tb4 10.Tf3 Tc4 11.Cf2+ (10.763.656) 796 TB:74.035
19/39 0:20 +0.43 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cf2 Tc6 5.Cd3+ Re4 6.Rf2 (17.035.292) 817 TB:119.514
20/40 0:33 +0.44 1...Rxg2 2.Cd1 Rf3 3.Ta3+ Rf4 4.Cf2 Tc6 5.Cd3+ Re4 6.Rf2 Tc8 7.Ce1 Td8 8.Te3+ Rf5 9.Cd3 Td4 10.Rf3 Rg5 11.Rg3 Tg4+ 12.Rf2 (27.952.873) 827 TB:198.305

[hgm]

is this only a problem with 5-men tablebases?

Of course. Nalimov table-bases do not take castling into account (i.e., they tabulate only positions where no castling rights exist, even if the pieces on the board are positioned such that castling rights conceivably might exist). So the KRPKR EGTB lists the position after Rxb2 as a draw, which would have been correct if there were no castling rights. Getting the TB hit makes it not look any deeper.

So when castling rights exist, one should refrain from probing TBs, as you know for sure the position is not in there. Apparently Fruit probes TBs regardless of castling rights. This is the bug Uri refers to.

One might also argue that the bug is Nalimov's, for failing to take castling into account. Only a very minor fraction of the KRPKR positions can have castling rights, as you have to fix 2 of the 5 pieces. So to tabulate all positions with castling rights in KRPKR only takes the space of some four 3-men EGTB, i.e. completely negligible compared to the original 5-men EGTB. So there is no real excuse for not doing it, other than laziness.

One could of cause easily build such "3-other-men" EGTBs as separate TBs, each in a K, Q, k or q flavour, (depending on which castling is on the board in addition to the other 3 men), and then probe the appropriate one for the castling rights in existence. And similarly "2-other-man" for KQ and kq, and "1-other-man" for Kk, Kq, Qk and Qq, to supplement the"set of 5-men TBs (and with the number of other men correspondingly lowered to supplement 4-men and 3-men sets).

[Zach Wegner]

Woudn't you need eight extra TBs, for the cases when both sides could castle? Though, for these cases they are equivalent in size to a 1 man TB...

[hgm]

Well, I guess that as supplement for the 5-men EGTBs KRRKR and KRKRR one indeed would have four 0-other-men EGTBs where three castlings are possible: KQk, KQq, Kkq and Qkq. Each of thos would contain only a sinle position.

Kkq would actually be won for the side with only one Rook, if he had the move. (And not by castling... )

[bob]

is this only a problem with 5-men tablebases?

Of course. Nalimov table-bases do not take castling into account (i.e., they tabulate only positions where no castling rights exist, even if the pieces on the board are positioned such that castling rights conceivably might exist). So the KRPKR EGTB lists the position after Rxb2 as a draw, which would have been correct if there were no castling rights. Getting the TB hit makes it not look any deeper.

So when castling rights exist, one should refrain from probing TBs, as you know for sure the position is not in there. Apparently Fruit probes TBs regardless of castling rights. This is the bug Uri refers to.

One might also argue that the bug is Nalimov's, for failing to take castling into account. Only a very minor fraction of the KRPKR positions can have castling rights, as you have to fix 2 of the 5 pieces. So to tabulate all positions with castling rights in KRPKR only takes the space of some four 3-men EGTB, i.e. completely negligible compared to the original 5-men EGTB. So there is no real excuse for not doing it, other than laziness.

One could of cause easily build such "3-other-men" EGTBs as separate TBs, each in a K, Q, k or q flavour, (depending on which castling is on the board in addition to the other 3 men), and then probe the appropriate one for the castling rights in existence. And similarly "2-other-man" for KQ and kq, and "1-other-man" for Kk, Kq, Qk and Qq, to supplement the"set of 5-men TBs (and with the number of other men correspondingly lowered to supplement 4-men and 3-men sets).

Or, one can just not probe if you have KRPKR, and one side still has castling rights left. If you just delay probing for a couple of plies only, in such cases, the problem goes away.

But realistically, I have _never_ seen a game where this was an issue. In fact, I have never seen a real game where 5 pieces were left (KRP vs KR) where one side could still castle...

[Jim Walker]

Exactly ! People who worry about this kind of thing need to get a life.
Jim

[nczempin]

Exactly ! People who worry about this kind of thing need to get a life.
Jim

But that could be said about the whole of computer chess.