Hi there,
I like statistics but a wrong mate-distance is bad for statistics to move-average!
I wish me that programmer more looking on games without resign-mode.
Often loses on time before mate (some engines have this bug).
But the topic for my message is mate-distance:
Have a look what RubiChess play on the end of the game!
Best
Frank
[pgn][Event "40 Moves in 12 min"]
[Site "fcp-tourney-2021, WASP-1"]
[Date "2021.03.03"]
[Round "19.41"]
[White "RubiChess 1.9 NN BMI2 x64"]
[Black "Lc0 0.26.3 NN CPU x64"]
[Result "1-0"]
[ECO "A85/07"]
[Opening "Dutch (c4/Nc3...e6)"]
1. c4 {book 0s} 1... f5 {book 0s} 2. Nc3 {book 0s} 2... Nf6 {book 0s} 3. d4
{book 0s} 3... e6 {book 0s} 4. e3 {book 0s} 4... d5 {book 0s} 5. Bd3 {book 0s}
5... c6 {book 0s} 6. h3 {book 0s} 6... Bd6 {book 0s} 7. Nge2 {+0.34/29 32s}
7... O-O {+0.10/6 15s} 8. O-O {+0.34/30 19s} 8... Qe7 {+0.13/6 26s (b6)} 9. Qc2
{+0.25/29 23s (Bd2)} 9... a6 {+0.12/6 14s (g6)} 10. c5 {+0.28/31 39s (Bd2)}
10... Bc7 {+0.14/8 12s} 11. f3 {+0.33/31 19s} 11... e5 {+0.14/10 18s (a5)}
12. Bxf5 {+0.26/32 18s (dxe5)} 12... Bxf5 {-0.04/10 17s} 13. Qxf5 {+0.54/32 16s}
13... Nbd7 {-0.03/10 12s (Ne4)} 14. Qd3 {+0.43/28 29s (Qc2)} 14... Nh5 {+0.02/8
44s (Rae8)} 15. Bd2 {+0.62/30 55s} 15... Rf7 {0.00/11 11s (Rae8)} 16. f4
{+0.75/28 16s} 16... e4 {+0.02/11 11s} 17. Qc2 {+0.67/29 14s} 17... g6 {-0.01/10
19s} 18. Qb3 {+0.23/28 31s (g4)} 18... Rb8 {-0.07/10 17s} 19. g4 {+0.14/31 33s
(Rf2)} 19... Ng7 {-0.07/10 16s} 20. Rf2 {+0.16/30 15s} 20... b6 {-0.06/12 47s
(Qh4)} 21. Qa4 {+0.72/28 16s} 21... Qe6 {-0.05/13 2s (Qf6)} 22. b4 {+0.93/29
21s} 22... h5 {-0.02/12 15s (a5)} 23. Rg2 {+0.81/29 19s} 23... Nf6 {-0.11/14 20s
(hxg4)} 24. cxb6 {+0.94/31 28s (Qxa6)} 24... Rxb6 {-0.07/11 23s} 25. Qa3
{+0.91/32 18s (Qd1)} 25... Rb8 {-0.02/11 42s} 26. Na4 {+0.95/32 16s} 26... hxg4
{0.00/12 20s (a5)} 27. Nc5 {+1.04/34 19s} 27... Qf5 {+0.03/11 22s (Qc8)}
28. hxg4 {+0.69/29 33s (Qxa6)} 28... Nxg4 {+0.10/10 11s} 29. Qxa6 {+1.03/29 15s}
29... Nf6 {+0.12/10 28s (Bb6)} 30. Rf1 {+1.28/29 19s} 30... Bb6 {+0.16/10 22s}
31. Qa4 {+1.59/31 14s} 31... Rc8 {+0.19/9 6s} 32. b5 {+1.37/30 23s (Qd1)}
32... cxb5 {+0.06/9 32s} 33. Qxb5 {+0.87/30 12s} 33... Bc7 {+0.08/11 16s (Rb8)}
34. Nc3 {+1.49/29 16s (Qa6)} 34... Qh3 {+0.04/11 19s (Bd6)} 35. Rxg6 {+2.52/30
20s (Qa6)} 35... Kh7 {0.00/15 18s (Rb8)} 36. Rg2 {+3.12/32 16s (Rg5)} 36... Ngh5
{+0.49/14 42s} 37. Nxd5 {+3.06/32 13s (Rff2)} 37... Kh8 {+0.78/10 18s (Rg7)}
38. Nxf6 {+4.19/30 10s} 38... Nxf6 {+1.11/14 9s} 39. Qa6 {+4.55/31 7s (Qc4)}
39... Rg8 {+1.34/12 22s} 40. Rxg8+ {+3.77/30 10s} 40... Kxg8 {+1.45/15 18s}
41. Kf2 {+4.76/33 16s} 41... Bxf4 {+1.49/15 23s} 42. Ke1 {+4.58/33 16s (exf4)}
42... Bxe3 {+1.77/12 48s (Bg5)} 43. Rxf6 {+5.21/29 16s} 43... Qh4+ {+1.99/13
31s} 44. Kd1 {+5.94/32 33s} 44... Rxf6 {+1.98/12 29s} 45. Qa8+ {+5.91/31 12s
(Qc8+)} 45... Kg7 {+2.15/11 1:18m} 46. Bxe3 {+4.92/32 12s} 46... Qh2 {+2.23/12
55s (Qh1+)} 47. Qb7+ {+7.48/29 18s} 47... Kh8 {+2.23/11 26s (Kg8)} 48. Qc8+
{+8.15/28 15s (Qb5)} 48... Kg7 {+2.83/11 1:37m (Kh7)} 49. Ne6+ {+17.16/29 12s
(Qg4+)} 49... Kf7 {+3.66/10 31s (Rxe6)} 50. Qd7+ {+19.56/28 33s} 50... Kg6
{+4.55/11 10s} 51. Nf4+ {+20.56/24 17s (Qg7+)} 51... Rxf4 {+7.00/8 44s} 52. Qd6+
{+21.47/29 28s} 52... Kf5 {+10.27/8 38s (Kg7)} 53. Qxf4+ {+M56/60 16s}
53... Qxf4 {+49.76/8 10s} 54. Bxf4 {+M54/81 15s} 54... Kf6 {+45.65/6 34s (Kg6)}
55. Ke2 {+M54/88 14s (a4)} 55... Ke7 {+M115/2 12s (Ke6)} 56. Ke3 {+M52/98 13s}
56... Ke6 {+M114/2 14s (Kd7)} 57. Kxe4 {+M51/106 16s} 57... Kd7 {+M112/2 15s}
58. d5 {+M12/49 28s} 58... Kc8 {+M110/2 14s (Kd8)} 59. a4 {+M10/50 14s (d6)}
59... Kd7 {+M109/2 13s (Kb7)} 60. a5 {+M9/60 16s} 60... Kc8 {+M108/2 12s} 61. a6
{+M7/51 31s} 61... Kd7 {+M107/2 11s (Kd8)} 62. a7 {+M6/48 18s} 62... Ke7
{+M106/2 10s} 63. d6+ {+M5/46 30s (a8Q)} 63... Kf6 {+M105/2 9s (Kf8)} 64. a8=Q
{+M4/44 16s} 64... Kg7 {+M104/2 7s (Ke6)} 65. d7 {+M4/38 18s} 65... Kg6 {+M103/2
6s (Kf7)} 66. d8=Q {+M3/36 15s} 66... Kf7 {+M2/2 6s} 67. Qf6+ {+M7/62 16s (Qg5)}
67... Kxf6 {+71.28/1 0s} 68. Qf8+ {+M6/67 14s} 68... Ke6 {+M105/2 6s} 69. Bc7
{+M7/67 17s} 69... Kd7 {+M104/1 0s} 70. Kd5 {+M5/76 13s} 70... Kxc7 {+M103/1 0s}
71. Kc5 {+M4/83 15s} 71... Kd7 {+M3/2 7s (Kb7)} 72. Qf7+ {+M3/97 16s} 72... Kc8
{+M2/2 5s (Kd8)} 73. Kc6 {+M2/107 17s} 73... Kb8 {+M1/2 3s} 74. Qb7# {+M1/255
0s} 1-0[/pgn]
Mate distance a problem for some engines ... example RubiChess
Moderators: hgm, Dann Corbit, Harvey Williamson
-
Frank Quisinsky
- Posts: 6808
- Joined: Wed Nov 18, 2009 7:16 pm
- Location: Gutweiler, Germany
- Full name: Frank Quisinsky
-
RubiChess
- Posts: 562
- Joined: Fri Mar 30, 2018 7:20 am
- Full name: Andreas Matthies
Re: Mate distance a problem for some engines ... example RubiChess
Hi Frank.
I know that Rubi is not the best choice when you need an engine finding shortest mate but I would guess that in your example many of the M<bignumber> scores and even some M<smallnumber> are just some bad interpretations of TB scores.
Would be interesting to see the corresponding UCI log of the game.
One problem is that there is no official spec how to report a tablebase win to the GUI. Rubi used a score of 30000 - dtz some time ago but that was falsly displayed as mate in ... by the TCEC GUI. Later I switched to 29900 - dtz which is better at TCEC but may still confuse your shredder GUI.
Next problem is of cause the horrible endgame play when the engine just follows the "distance to zero path" of Syzygy sacrifying all the pieces to finally end in a KQvK endgame. But even Marco Costalba failed to solve this problem completely iirc.
Losing on time... hopefully not a problem of Rubi.
Regards, Andreas
I know that Rubi is not the best choice when you need an engine finding shortest mate but I would guess that in your example many of the M<bignumber> scores and even some M<smallnumber> are just some bad interpretations of TB scores.
Would be interesting to see the corresponding UCI log of the game.
One problem is that there is no official spec how to report a tablebase win to the GUI. Rubi used a score of 30000 - dtz some time ago but that was falsly displayed as mate in ... by the TCEC GUI. Later I switched to 29900 - dtz which is better at TCEC but may still confuse your shredder GUI.
Next problem is of cause the horrible endgame play when the engine just follows the "distance to zero path" of Syzygy sacrifying all the pieces to finally end in a KQvK endgame. But even Marco Costalba failed to solve this problem completely iirc.
Losing on time... hopefully not a problem of Rubi.
Regards, Andreas
-
hgm
- Posts: 27701
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Mate distance a problem for some engines ... example RubiChess
Perhaps not a general solution. But refraining using the EGT when the opponent has a bare King would be simple enough, and already give an enormous improvement...
-
Frank Quisinsky
- Posts: 6808
- Joined: Wed Nov 18, 2009 7:16 pm
- Location: Gutweiler, Germany
- Full name: Frank Quisinsky
Re: Mate distance a problem for some engines ... example RubiChess
Good morning Andreas,
at first:
RubiChess have no other technical problems and works fine for me (no time loses, other things).
I can use the Shredder GUI feature "debug" ... type "ucidebug" ... but for so many games played here the produced debug file is very big.
Often I am thinking:
Maybe better to start eng-eng complete without endgame bases.
I remember on a discussion by mail with chessbase programmer Mathias Feist for some years.
Mathias told me that for the own eng-eng games he used no Nalimov bases (older discussion, Nalimov are at this times available only).
If I do that I have different advantages:
I can use engines, often "lost on time" or haven't the mate-distance problems.
Additional example:
FCP Tourney-2020: Chiron lost one game on time (I am using 4-man) ... after 2.000 games
FCP Tourney-2021: Chiron lost 10 games on time (I am using 5-man) ... after 760 games
If I am looking in my own engine-configuration:
https://www.amateurschach.de/main/_configuration.htm
A lot of engine have problems with time-loses (again not RubiChess).
I will check the mate-distance problem with all of the other engines I am using.
I saw that often in the still-running FCP Tourney-2021, not RubiChess only.
Best and thanks for your answer!
Frank
at first:
RubiChess have no other technical problems and works fine for me (no time loses, other things).
I can use the Shredder GUI feature "debug" ... type "ucidebug" ... but for so many games played here the produced debug file is very big.
Often I am thinking:
Maybe better to start eng-eng complete without endgame bases.
I remember on a discussion by mail with chessbase programmer Mathias Feist for some years.
Mathias told me that for the own eng-eng games he used no Nalimov bases (older discussion, Nalimov are at this times available only).
If I do that I have different advantages:
I can use engines, often "lost on time" or haven't the mate-distance problems.
Additional example:
FCP Tourney-2020: Chiron lost one game on time (I am using 4-man) ... after 2.000 games
FCP Tourney-2021: Chiron lost 10 games on time (I am using 5-man) ... after 760 games
If I am looking in my own engine-configuration:
https://www.amateurschach.de/main/_configuration.htm
A lot of engine have problems with time-loses (again not RubiChess).
I will check the mate-distance problem with all of the other engines I am using.
I saw that often in the still-running FCP Tourney-2021, not RubiChess only.
Best and thanks for your answer!
Frank