Possible draw bug in Chessbase Houdini 4 GUI with Syzygy TB

[mwyoung]

I was testing the 6 man Syzygy TB in the Houdini 4 GUI. I had set the TB path for engine use and GUI use in the option menu. This was my first test game with the 6 man Syzygy TB. I have all Syzygy files of .rtbw and .rtbz downloaded.

I did not notice this problem when running with only 5 man Syzygy with both engine and GUI Syzygy TB path active.

I believe the problem is in the GUI path option only, as I could not replicate the draw with the 6 man Syzygy TB when using the TB in the engine only path. The GUI TB path overrides all engine moves when the path is active.

[pgn]

[Event "Blitz, 20m/40+20m/40+(20m+10s)"]
[Site "I7CPU"]
[Date "2014.01.16"]
[Round "1"]
[White "Stockfish 140114 64 SSE4.2"]
[Black "Houdini 4 Pro x64A"]
[Result "1/2-1/2"]
[ECO "D85"]
[Annotator "0.49;0.26"]
[PlyCount "128"]
[TimeControl "40/1200:40/1200:1200+10"]

{Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz 1862 MHz W=29.5 plies; 4,
607kN/s; 2,007,319 TBAs; 2500elo.ctg B=21.8 plies; 4,389kN/s; 1,420,646 TBAs;
2500elo.ctg} 1. d4 {B 0} Nf6 {B 0} 2. c4 {B 0} g6 {B 0} 3. Nc3 {B 0} d5 {B 0}
4. cxd5 {B 0} Nxd5 {B 0} 5. e4 {B 0} Nxc3 {B 0} 6. bxc3 {B 0} Bg7 {B 0} 7. Nf3
{B 0} c5 {B 0} 8. Be3 {B 0} Qa5 {B 0} 9. Qd2 {B 0} O-O {B 0} 10. Rc1 {B 0} Rd8
{B 0} 11. d5 {B 0} e6 {B 0} 12. Bg5 {B 0} Re8 {B 0 Both last book move} 13. d6
{0.49/25 27} Nd7 {0.26/22 129} 14. Bh6 {0.74/26 24 (h4)} Bh8 {0.12/22 37} 15.
h4 {0.77/28 46} Qa4 {0.31/21 55} 16. Be2 {0.48/29 72 (Qe3)} Qxe4 {0.15/20 41}
17. h5 {1.00/29 198} b5 {0.29/22 115 (Bf6)} 18. Kf1 {0.77/24 28 (Be3)} b4 {0.
16/21 39 (Rb8)} 19. Bd3 {1.78/28 79 (cxb4)} Qd5 {0.81/20 52 (bxc3)} 20. Qc2 {
2.04/28 46 (hxg6)} f5 {0.95/21 42 (Bxc3)} 21. cxb4 {2.06/26 19} Bf6 {0.97/20
41 (Rb8)} 22. hxg6 {2.83/26 22 (Bf4)} hxg6 {1.32/21 35} 23. Bg5 {2.83/29 19
(bxc5)} Qxd6 {1.66/21 50} 24. bxc5 {2.84/28 21} Qe7 {1.54/21 37} 25. Bf4 {2.47/
28 133} Rd8 {1.89/23 100 (Nf8)} 26. c6 {3.37/26 29 (Bd6)} Nc5 {2.64/21 113} 27.
Bc4 {3.53/26 17 (Bb5)} Ne4 {2.65/21 84} 28. c7 {3.81/27 16} Re8 {2.84/20 37}
29. g4 {4.27/26 20 (Be5)} Qa3 {3.33/19 52} 30. Rh3 {4.52/27 21} Qb2 {3.84/19 38
} 31. gxf5 {4.92/27 23} Qxc2 {4.55/19 29} 32. Rxc2 {5.17/28 20} Kg7 {3.84/20
10 (gxf5)} 33. Bh6+ {6.19/27 25} Kg8 {3.84/19 0} 34. fxe6 {6.46/30 22 (fxg6)}
Nd6 {3.70/19 10} 35. Bb3 {6.65/31 23 (Rg3)} Bxe6 {5.15/19 8} 36. Rc6 {6.86/31
29} Bxb3 {5.42/20 7} 37. axb3 {7.04/32 30} Ne4 {5.35/21 8 (Be7)} 38. Nd2 {8.00/
33 38} Nxd2+ {5.35/20 0} 39. Bxd2 {8.62/38 54} Be5 {5.52/22 20 (Kg7)} 40. Rxg6+
{11.24/37 80 (Rd3)} Kf7 {5.63/22 7} 41. Rc6 {12.39/38 25} Kg8 {6.56/25 181
(Rac8)} 42. Rf3 {78.11/33 60 (Rd3)} Bg7 {6.30/25 157 (Kh7)} 43. Rd3 {78.11/36
24} Be5 {8.51/26 137} 44. Rd7 {99.16/36 24} Rac8 {9.35/23 26 (Kh8)} 45. Rg6+ {
133.93/33 219 (f4)} Kh8 {6.77/22 5} 46. Ba5 {150.83/28 65 (f4)} Bb2 {10.02/26
117 (Ba1)} 47. Rd3 {150.84/27 38 (f4)} Rxc7 {15.46/26 102 (Kh7)} 48. Bxc7 {150.
91/26 21} Re7 {24.97/27 87} 49. Bf4 {150.92/26 22 (Rh3+)} Rf7 {21.41/22 17} 50.
Rg5 {150.95/27 31 (Rh3+)} Rg7 {#18/25 7 (Bg7)} 51. Be5 {150.96/27 19} Bxe5 {
#17/27 11} 52. Rxg7 {150.97/28 23 (Rxe5)} Kxg7 {6.56/20 3} 53. Rd7+ {150.98/36
19} Kf6 {14.76/21 33} 54. Rxa7 {151.00/39 17} Bd4 {2/0 0} 55. Rb7 {1/0 0} Kf5 {
1/0 0} 56. b4 {1/0 0} Ke4 {1/0 0} 57. b5 {1/0 0} Kd5 {1/0 0} 58. f4 {1/0 0} Bf6
{1/0 0} 59. Kg2 {1/0 0} Kc5 {1/0 0} 60. Rb8 {1/0 0} Be7 {1/0 0} 61. Rb7 {1/0 0}
Bf6 {1/0 0} 62. Rb8 {1/0 0} Be7 {1/0 0} 63. Rb7 {1/0 0} Bh4 {1/0 0} 64. Rb8 {
1/0 0} Be7 {1/0 0 Draw accepted} 1/2-1/2

[/pgn]

[bnculp]

Yes this sounds familiar. Houdart recommends removal of the GUI Syszgy path and use only the engine path.

http://rybkaforum.net/cgi-bin/rybkaforu ... ?tid=28221

[AdminX]

Yes this sounds familiar. Houdart recommends removal of the GUI Syszgy path and use only the engine path.

http://rybkaforum.net/cgi-bin/rybkaforu ... ?tid=28221

Do you know if this affects Houdini as well as Stockfish? What I am trying to get at is should I make this the norm or should I change depending on the engine I am using. Any ideas?

[Matthias Gemuh]

Yes this sounds familiar. Houdart recommends removal of the GUI Syszgy path and use only the engine path.

http://rybkaforum.net/cgi-bin/rybkaforu ... ?tid=28221

Do you know if this affects Houdini as well as Stockfish? What I am trying to get at is should I make this the norm or should I change depending on the engine I am using. Any ideas?

A GUI should not use the de Man bases. They are "engine-only" bases.
A GUI should only give the TB path to engine.

Matthias.

[AdminX]

Yes this sounds familiar. Houdart recommends removal of the GUI Syszgy path and use only the engine path.

http://rybkaforum.net/cgi-bin/rybkaforu ... ?tid=28221

Do you know if this affects Houdini as well as Stockfish? What I am trying to get at is should I make this the norm or should I change depending on the engine I am using. Any ideas?

A GUI should not use the de Man bases. They are "engine-only" bases.
A GUI should only give the TB path to engine.

Matthias.

Okay, Thanks

[hgm]

A GUI should not use the de Man bases. They are "engine-only" bases.
A GUI should only give the TB path to engine.

This remark intrigues me. You know I am very skeptical about EGT use in GUIs in general, but would there be any reason why Syzygy EGTs are worse than others for use in a GUI? One legitimate use seems to speed up the '50-move dance' between two engines that both use EGTs, and would thus never be able to swindle each other. But I don't see off-hand why DTZ50 could not be used for that.

It seems that especially when you use DTM EGTs, you should never let the GUI play on behalve of the engine, when reaching the EGT stage. On Rybka forum there is an amusing thread where the GUI bungles a 50-move draw when it takes over from Houdini (who was using DTZ50 itself, and thus was counting on the draw). For this application DTZ50 seems the only acceptable solution in the GUI.

[RJN]

A GUI should not use the de Man bases. They are "engine-only" bases.
A GUI should only give the TB path to engine.

This remark intrigues me. You know I am very skeptical about EGT use in GUIs in general, but would there be any reason why Syzygy EGTs are worse than others for use in a GUI? One legitimate use seems to speed up the '50-move dance' between two engines that both use EGTs, and would thus never be able to swindle each other. But I don't see off-hand why DTZ50 could not be used for that.

It seems that especially when you use DTM EGTs, you should never let the GUI play on behalve of the engine, when reaching the EGT stage. On Rybka forum there is an amusing thread where the GUI bungles a 50-move draw when it takes over from Houdini (who was using DTZ50 itself, and thus was counting on the draw). For this application DTZ50 seems the only acceptable solution in the GUI.

I think the problem is a bug in ChessBase GUI, which is supposed to be fixed in the near future. Something along the line that it's NOT the Syzygy bases that the GUI follows, from what I understand.

I agree with the philosophy of not letting the GUI make TB moves for the engine

[syzygy]

A GUI should not use the de Man bases. They are "engine-only" bases.
A GUI should only give the TB path to engine.

This remark intrigues me. You know I am very skeptical about EGT use in GUIs in general, but would there be any reason why Syzygy EGTs are worse than others for use in a GUI? One legitimate use seems to speed up the '50-move dance' between two engines that both use EGTs, and would thus never be able to swindle each other. But I don't see off-hand why DTZ50 could not be used for that.

It seems that especially when you use DTM EGTs, you should never let the GUI play on behalve of the engine, when reaching the EGT stage. On Rybka forum there is an amusing thread where the GUI bungles a 50-move draw when it takes over from Houdini (who was using DTZ50 itself, and thus was counting on the draw). For this application DTZ50 seems the only acceptable solution in the GUI.

For sure Nalimov or orther DTM-tables should not be used by the GUI if the engine is using DTZ50 tables.

A GUI could use DTZ50 tables, but just playing straight DTZ50-optimal moves leads to rather ugly play. An engine can solve this by doing a search (using the tables to filter out bad moves). A GUI will not do that.

But however I look at it, I don't see the point in a GUI playing the moves instead of the engines. If you let the GUI take over, why not just adjudicate the game immediately. If both engines are using the same set of tables, that should not change the outcome. If one of the engines is not, it may change the outcome, but if the user decides that this is OK, why not.

I think it makes more sense for a GUI to only show TB information and not interfere with engine play. It would also be nice if GUIs offer a way to inspect the tables.

[Matthias Gemuh]

A GUI should not use the de Man bases. They are "engine-only" bases.
A GUI should only give the TB path to engine.

This remark intrigues me. You know I am very skeptical about EGT use in GUIs in general, but would there be any reason why Syzygy EGTs are worse than others for use in a GUI? ... .

ChessGUI can play the TB moves if the user is curious to see them.
So ChessGUI says basically "I am adjudicating the game here because it is a 'mate in 43', and if you want to see the mating moves, here they are ...".
DTM bases are needed to do this without engine-type search.

BTW, I see Ronald in this thread. Let's listen to him.

A GUI that is using DTM bases does not need to know which bases an engine is using.

[RJN]

A GUI should not use the de Man bases. They are "engine-only" bases.
A GUI should only give the TB path to engine.

This remark intrigues me. You know I am very skeptical about EGT use in GUIs in general, but would there be any reason why Syzygy EGTs are worse than others for use in a GUI? One legitimate use seems to speed up the '50-move dance' between two engines that both use EGTs, and would thus never be able to swindle each other. But I don't see off-hand why DTZ50 could not be used for that.

It seems that especially when you use DTM EGTs, you should never let the GUI play on behalve of the engine, when reaching the EGT stage. On Rybka forum there is an amusing thread where the GUI bungles a 50-move draw when it takes over from Houdini (who was using DTZ50 itself, and thus was counting on the draw). For this application DTZ50 seems the only acceptable solution in the GUI.

For sure Nalimov or orther DTM-tables should not be used by the GUI if the engine is using DTZ50 tables.

A GUI could use DTZ50 tables, but just playing straight DTZ50-optimal moves leads to rather ugly play. An engine can solve this by doing a search (using the tables to filter out bad moves). A GUI will not do that.

But however I look at it, I don't see the point in a GUI playing the moves instead of the engines. If you let the GUI take over, why not just adjudicate the game immediately. If both engines are using the same set of tables, that should not change the outcome. If one of the engines is not, it may change the outcome, but if the user decides that this is OK, why not.

I think it makes more sense for a GUI to only show TB information and not interfere with engine play. It would also be nice if GUIs offer a way to inspect the tables.

I think you did a fantastic job creating your Syzygy Bases, Ronald.

From what I see, most problems have been config issues, or misunderstanding on how your bases work. Here is a consolidation of "issues" I have seen on the message boards, but you are the final word, but anyone free to correct me. It took time to understand some of these things myself:

1) People using 6-piece set assume it also includes the 5-piece, and are not setting a path to include 5-piece. (probably the #1 misunderstanding)

2) People stating Syzygy is missing (for example) mate in 71, while other EGTB formats show a forced mate. However, they don't realize the other bases don't take the 50 move rule into account.

3) Enabling Syzygy bases for the GUI, and also in some cases not setting the path for the engine, and only the GUI. It seems that despite the ability to set a GUI path, this causes issues on most (all?) GUIs to date.

4) Misunderstanding the evaluation when a mate greater than 50 is reported (although this has been changed in later versions of SF)

5) Misunderstanding of the "swindle" behavior.

6) Path not being set correctly. A semi-colon (windows) or a period (Linux) needs to be used to separate paths. Also, I have seen posts where people have used spaces in the path before/after the semicolons.

7) Not using the DTZ files, then wondering why the position can't always be converted into a win/loss/draw.

8) In general, not understanding the concept of DTZ50.

9) The belief that a RAM disk will improve performance, and not understanding this does basically nothing, since the OS provides the caching. (this won't cause the Bases to operate incorrectly, but is unnecessary)

Of course, most of this is in your Overview link below, but many people don't seem to read it. I just thought it might help some folks to have this listed. (assuming I understand the above correctly, but again, anyone can correct me if wrong)

https://github.com/syzygy1/Stockfish