Topic Rybka Support & Discussion / Rybka Discussion / RYBKA 4--DRAWN GAME THAT SHOULD HAVE BEEN EASILY WON
![[us]](/mwf/v12/flags/us.png "United States")
Hello friends. I am looking for some answers/justification as to why Rybka 4 failed to checkmate my opponent.
I was playing with Black in a 3 minute engine game in the playchess engine room. By move 79, I was ahead, King-Queen vs King (mate in 12). Rybka refused to checkmate my opponent and moved all the way up to move 123 before drawing the game due to my time running out!
Even novice player such as myself could have checkmated Rybka with KQ v K ending. I am truly baffled (and bothered) by this. I'm not sure how to post the game here for others to see, but if someone can give me a suggestion as to how that can be done, I will post the game.
I was playing with Black in a 3 minute engine game in the playchess engine room. By move 79, I was ahead, King-Queen vs King (mate in 12). Rybka refused to checkmate my opponent and moved all the way up to move 123 before drawing the game due to my time running out!
Even novice player such as myself could have checkmated Rybka with KQ v K ending. I am truly baffled (and bothered) by this. I'm not sure how to post the game here for others to see, but if someone can give me a suggestion as to how that can be done, I will post the game.
![[nl]](/mwf/v12/flags/nl.png "Netherlands")
I am not really sure, but I think that the answer is quite simple, a computer simply doesn't play like a human and for a computer a KQ v K game is alot of calculating. A human knows that this is a winning position a computer needs to stay calculating.
Now when you play a 3 minute game, time simply runs out and a normal person could stress out and I think the computer simply doesn't give himself time to calculate in depths of 10 anymore or higher. I think you simply had to tell Rybka that he had won and you can do that by installing the Nalimov endgame tablebases. For as far I know the engine will get slower, but now it doesn't have to calculate anymore in the endgame with 3-4-5-6 pieces, depending on how many tablebases you have.
Like I said I am not sure about this, but I think this is what happened and 123 moves in a 3 minutes game is really alot.
Now when you play a 3 minute game, time simply runs out and a normal person could stress out and I think the computer simply doesn't give himself time to calculate in depths of 10 anymore or higher. I think you simply had to tell Rybka that he had won and you can do that by installing the Nalimov endgame tablebases. For as far I know the engine will get slower, but now it doesn't have to calculate anymore in the endgame with 3-4-5-6 pieces, depending on how many tablebases you have.
Like I said I am not sure about this, but I think this is what happened and 123 moves in a 3 minutes game is really alot.
![[il]](/mwf/v12/flags/il.png "Israel")
This is simply not correct
KQ vs K is easy for computers unless they have bugs.
tablebases are not needed.
Rybka is known to be a program with bugs but most programs are not going to have problems to mate with KQ vs K even in 1 second without tablebases.
KQ vs K is easy for computers unless they have bugs.
tablebases are not needed.
Rybka is known to be a program with bugs but most programs are not going to have problems to mate with KQ vs K even in 1 second without tablebases.
![[ch]](/mwf/v12/flags/ch.png "Switzerland")
Use TB's to fix that.
![[za]](/mwf/v12/flags/za.png "South Africa")
> Use TB's to fix that.
NO
. Rybka should be able to understand simple things like that. Things like checkmating with a bishop and a knight. After all it is on top of rating lists. Well, I'm still puzzled by that mysterious behavior. I know that Rybka take a little bit long to deliver a mate in 1, but draw in a KQ vs K game!!! Maybe there was something wrong with the GUI settings somewhere.
![[gb]](/mwf/v12/flags/gb.png "United Kingdom")
It is interesting that some engines get this without TBs and others don't.
Sotckfish and Critter find the mate immediately. Not surprising as they don't use TBs, so must have that knowledge programmed in to succeed.
Shredder 9 and R3 don't find mate (certainly not quickly) if you put the defending K in the middle of the board and the attacking K at the edge, unless you have TBs on.
Hiarcs 13, which does use TBs when available, does find the mate immediately without TBs. We have seen a simialr thing with KNB vs K. Hiarcs has the method built in where R3 does not.
There is a theoretical argument that building in this knowledge will slow the engine down. I don't really buy that. The test for the relevant endgames to see if the mating methiod should be applied would take very few instructions and those instructions would be even be quick instructions. The mating method would kick in after that and of course would take many more instructions, some of which will be slower instructions, but that would not slow the engine down for other positions. The test to whether to apply the mating method would not be appreciably more (if more at all) than checking the TB index.
I think the real issue is about progamming effort. It would not be huge but it is just extra work and that will be at the cost of something else that coud make the engine stronger, eg improved search or improved evaluation.
The part of me that wants elegance says these basic mating methods should be programmed in. The part of me that wants the strongest engine says leave them out, rely on TBs and put the effort into something else. As a user I would on balance go for the former, as a vendor I would go for the latter.
Sotckfish and Critter find the mate immediately. Not surprising as they don't use TBs, so must have that knowledge programmed in to succeed.
Shredder 9 and R3 don't find mate (certainly not quickly) if you put the defending K in the middle of the board and the attacking K at the edge, unless you have TBs on.
Hiarcs 13, which does use TBs when available, does find the mate immediately without TBs. We have seen a simialr thing with KNB vs K. Hiarcs has the method built in where R3 does not.
There is a theoretical argument that building in this knowledge will slow the engine down. I don't really buy that. The test for the relevant endgames to see if the mating methiod should be applied would take very few instructions and those instructions would be even be quick instructions. The mating method would kick in after that and of course would take many more instructions, some of which will be slower instructions, but that would not slow the engine down for other positions. The test to whether to apply the mating method would not be appreciably more (if more at all) than checking the TB index.
I think the real issue is about progamming effort. It would not be huge but it is just extra work and that will be at the cost of something else that coud make the engine stronger, eg improved search or improved evaluation.
The part of me that wants elegance says these basic mating methods should be programmed in. The part of me that wants the strongest engine says leave them out, rely on TBs and put the effort into something else. As a user I would on balance go for the former, as a vendor I would go for the latter.
> There is a theoretical argument that building in this knowledge will slow the engine down. I don't really buy that.
The unmentionables can solve many positions quickly.
Still, I am puzzled by the problem that Elitejustice mentioned. I think it is something wrong from his settings.
So it's not true that time is an issue here?
I think that (here I go again) if tablebases were installed Rybka wouldn't have had any problems, but because it was not a 2 hr. game, which gave the engine enough time to think about a possible mate, Rybka simply had to keep on moving (I just imagine Rybka having 2 secs. left on the clock and maybe gets a second every move but simply couldn't find mate in 1 sec.
One problem I don't understand is that I just can't imagine that Rybka would ever give up his queen in order to get to a draw, but maybe he offered a draw after move 123.
When it comes to posting the game, you can just paste the game here as a pgn, since it's plain text and everybody can copy this and paste it in their gui.
Anyway, I allready said I wasn't sure in my first post, but this also remembered me about an old 80s movie, named War Games, in which the computer keeps on calculating a simple game of tic tac toe to understand that when you play a real nuclear war, there can't be a winning side. This is simply the difference between a human and a computer, a human knows that KQ against K is a winning combination, but a computer has to keep calculating. I do aggree however that this should have been an easy mate, but I think that Rybka simply couldn't find it in time and I believe that rybka in the normal settings doesn't think continuously and has to start thinking again after the other side made his move.
I think that (here I go again) if tablebases were installed Rybka wouldn't have had any problems, but because it was not a 2 hr. game, which gave the engine enough time to think about a possible mate, Rybka simply had to keep on moving (I just imagine Rybka having 2 secs. left on the clock and maybe gets a second every move but simply couldn't find mate in 1 sec.
One problem I don't understand is that I just can't imagine that Rybka would ever give up his queen in order to get to a draw, but maybe he offered a draw after move 123.
When it comes to posting the game, you can just paste the game here as a pgn, since it's plain text and everybody can copy this and paste it in their gui.
Anyway, I allready said I wasn't sure in my first post, but this also remembered me about an old 80s movie, named War Games, in which the computer keeps on calculating a simple game of tic tac toe to understand that when you play a real nuclear war, there can't be a winning side. This is simply the difference between a human and a computer, a human knows that KQ against K is a winning combination, but a computer has to keep calculating. I do aggree however that this should have been an easy mate, but I think that Rybka simply couldn't find it in time and I believe that rybka in the normal settings doesn't think continuously and has to start thinking again after the other side made his move.
You may need some knowledge to win KBN vs K but there is
no need for special knowledge to win KQK
pushing the opponent king to the corner and reducing the distance between the kings is something that may be productive also in non tablebases endgames like KRBN vs KRN(nalimov at least does not have 7 piece endgames)
no need for special knowledge to win KQK
pushing the opponent king to the corner and reducing the distance between the kings is something that may be productive also in non tablebases endgames like KRBN vs KRN(nalimov at least does not have 7 piece endgames)
Yes, you are completely right about this Uri, but this is from a human's point of view, a computer does calculating and it has to calculate less if it's programmed that in this instance KQK is a winning combination.
The only thing both humans and computers have to consider that this doesn't end up in a stalemate or that the queen gets taken by the King, but you have to agree with me on that one, that would be real stupid.
I really think that Rybka wasn't programmed in the way that it knows in advance that KQ K is a winning combination, so it has to calculate a winning move every time, like in human games the only way to loose is a stalemate (draw) loose the queen or simply think that there is no winning combination and offer a draw. I think that Rybka is too smart to loose the queen or get into a stalemate, so I just think that it offered a draw because it couldn't find the winning move in time, that gives another way (actually the only way) of loosing the game, out of time.
I call getting a draw loosing, it may sound strange though, but since you cannot loose this type of endgame, unless you are the opponent, making a draw here is the same as loosing to me.
The only thing both humans and computers have to consider that this doesn't end up in a stalemate or that the queen gets taken by the King, but you have to agree with me on that one, that would be real stupid.
I really think that Rybka wasn't programmed in the way that it knows in advance that KQ K is a winning combination, so it has to calculate a winning move every time, like in human games the only way to loose is a stalemate (draw) loose the queen or simply think that there is no winning combination and offer a draw. I think that Rybka is too smart to loose the queen or get into a stalemate, so I just think that it offered a draw because it couldn't find the winning move in time, that gives another way (actually the only way) of loosing the game, out of time.
I call getting a draw loosing, it may sound strange though, but since you cannot loose this type of endgame, unless you are the opponent, making a draw here is the same as loosing to me.
Well that is the point... pushing the opposing king to corner (or at least edge) is the key bit of knowledge you need and shortening the distance between the kings certainly helps. You also need to "know" not to wieght your own K & Q towards the centre of the board as you would in most endgame positions if you want to do it efficiently. I suspect Rybka (R3 at least) struggles with K+Q vs Q because it does not turn off the wieghting of its own pieces towards the centre (and of course it is possible it does not weight the edges and corners heavlily enough for the opposing king).
There is of course an arguement that you don't need any knowledge for K+Q vs Q and brute force will just find the win. That is OK for many postions but for anyone who wants to see how hard it can be in the longer K+Q vs K mates, try setting up Q on a1, K on b1 and opposing K on e4 and see how long it takes a mate solver to find the mate. I gave up waiting for Matemaster to solve this after 10 mins when it was still showing 0% completion. That is not even the longest K+Q vs K mate.
The Stockfish code is worth a read for how it tackles endgame mating positions with heavy wiegihting for edges and corners.
There is of course an arguement that you don't need any knowledge for K+Q vs Q and brute force will just find the win. That is OK for many postions but for anyone who wants to see how hard it can be in the longer K+Q vs K mates, try setting up Q on a1, K on b1 and opposing K on e4 and see how long it takes a mate solver to find the mate. I gave up waiting for Matemaster to solve this after 10 mins when it was still showing 0% completion. That is not even the longest K+Q vs K mate.
The Stockfish code is worth a read for how it tackles endgame mating positions with heavy wiegihting for edges and corners.
This is just what I mean, the computer simply plays in a different way than humans. Even when Rybka is the best, I think that unless he didn't find the mate or was told that it was winning anyhow, the engine wants to find the solution. I think that you meant K+Q vs K instead of Q, but ofcourse that is what we talk about here all along ;)
Anyway, I only know a bit about chess, but I do know alot about computers and since it's not that long ago that the computer was better than a human and some people even believe that Deep Blue didn't actually beat Kasparov (I'm actually one of them) and in the 80s they even said that it would take atleast another 100 years before a computer could beat the best chess players in the world, you must really assume that computers work different than a human brain.
Just take a King Pawn vs. King endgame, ofcourse you would be trying to get a queen for the pawn, but the number of possible moves is certainly lower than KQ / K, where the Queen can go all over the board and a pawn just forwards.
This is why calculating the moves to promote is easy for the computer, King can move to 8 places and pawn only 1 except if it started on row 2 or 7, so it only needs to calculate 9 possible moves for each move and another 8 for black's answer, we simply can't think that fast, so before we checked if the oponents king can even reach the soon to promote pawn, the computer allready calculated every move until promotion. But now the Queen, she can move to alot more places and since Rybka wasn't told KQ / K is a winning combination, it will start calculating with a certain depth or until he found a mate. This simply takes up alot more time and instead of maybe 50 possible moves to calculate to promote, it shoud now calculate maybe 5 billion different moves to get mate, this simply takes more time.
I think however that there could be a simple solution for this, tell Rybka from within the engine that some piece combinations are a winning combination and for instance K vs. K is always a draw, but therefore the engine would get bigger in size, therefore using more memory per core etc. etc. and Rybka will never give up, even when it takes 1 million moves. I just don't think that it's worth all the effort and that they will make these changes, because finding an easy mate in KQ vs. Q is also possible, so my suggestion would be in this case to just use the 3 piece Tablebases
Anyway, I only know a bit about chess, but I do know alot about computers and since it's not that long ago that the computer was better than a human and some people even believe that Deep Blue didn't actually beat Kasparov (I'm actually one of them) and in the 80s they even said that it would take atleast another 100 years before a computer could beat the best chess players in the world, you must really assume that computers work different than a human brain.
Just take a King Pawn vs. King endgame, ofcourse you would be trying to get a queen for the pawn, but the number of possible moves is certainly lower than KQ / K, where the Queen can go all over the board and a pawn just forwards.
This is why calculating the moves to promote is easy for the computer, King can move to 8 places and pawn only 1 except if it started on row 2 or 7, so it only needs to calculate 9 possible moves for each move and another 8 for black's answer, we simply can't think that fast, so before we checked if the oponents king can even reach the soon to promote pawn, the computer allready calculated every move until promotion. But now the Queen, she can move to alot more places and since Rybka wasn't told KQ / K is a winning combination, it will start calculating with a certain depth or until he found a mate. This simply takes up alot more time and instead of maybe 50 possible moves to calculate to promote, it shoud now calculate maybe 5 billion different moves to get mate, this simply takes more time.
I think however that there could be a simple solution for this, tell Rybka from within the engine that some piece combinations are a winning combination and for instance K vs. K is always a draw, but therefore the engine would get bigger in size, therefore using more memory per core etc. etc. and Rybka will never give up, even when it takes 1 million moves. I just don't think that it's worth all the effort and that they will make these changes, because finding an easy mate in KQ vs. Q is also possible, so my suggestion would be in this case to just use the 3 piece Tablebases
![[kw]](/mwf/v12/flags/kw.png "Kuwait")
Can you post the game. Just so that I understand what you are saying ... Rybka showed mate in 12, but then refused to play for this mate and played on till move 123. If so that is certainly strange behaviour and I would check your setup. Now with regards to EGTB's, I think everyone should have at least all the 4 EGTB's as on today's hardware where a 2 TB hard disk can be had for less than $100. Personally I think all 5 EGTB's as well as some 6 EGTB's are worth installing. I can't imagine a position with KQ vs K where Rybka 4 cannot find mate very quickly, and I would take a look at your setup as there might be a problem.
Howdy, you have got to have another problem. I tried KQK in many positions
and R4 makes mate without problems.
Wayne
and R4 makes mate without problems.
Wayne
> Howdy, you have got to have another problem. I tried KQK in many positions
> and R4 makes mate without problems.
Hi Wayne,
I did the same and also used the mindbreaker's parameters as well. Rybka checkmates without any problems.
Thank you all for your advice and comments! Yes, I will have to install EGTB soon!
M ANSARI, unfortunately I am at work now and did not email the game to myself. Thus, I will not be able to post the info until I get home later.
However, a few people mentioned "settings" as a possible cause. I had been using the top 'experimental' parameter settings that 'MINDBREAKER' had been testing. I had been playing with the parameter settings for 'Experiment 61' for quite some time in the playchess engine room with no problems. { FYI I'm engine rated at the moment around 2655 }
I don't know if this could have affected how the endgame was played, but I will defer to the experts.
http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?tid=18686;pg=4 }}
Yes, I will have to install EGTB soon! M ANSARI, unfortunately I am at work now and did not email the game to myself. Thus, I will not be able to post the info until I get home later.
However, a few people mentioned "settings" as a possible cause. I had been using the top 'experimental' parameter settings that 'MINDBREAKER' had been testing. I had been playing with the parameter settings for 'Experiment 61' for quite some time in the playchess engine room with no problems. { FYI I'm engine rated at the moment around 2655 }
I don't know if this could have affected how the endgame was played, but I will defer to the experts.
http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?tid=18686;pg=4 }}
It is really refreshing to know that so many knowledgeable people are on here to offer their support and advice. Thanks again to all who have replied! I am anxious to get home so that I can finally send this game out! However, if any of you are in contact with Vousatej...he was my opponent in the game in question last night. Maybe he can supply you with the game before I do. We played last night {I am in Southern Calif...so it was night for me}
Ok....friends....here is the game in question....I would welcome any thoughts from the experts out there as to what happened in this game:
[Event "Rated game, 3m"]
[Site "Engine Room"]
[Date "2010.12.12"]
[Round "?"]
[White "Vousatej, Deep Rybka 4 SSE42 "]
[Black "Elitejustice, Deep Rybka 4 SSE42 "]
[Result "1/2-1/2"]
[ECO "B92"]
[WhiteElo "2632"]
[BlackElo "2655"]
[Annotator "0.00;0.00"]
[PlyCount "245"]
[EventDate "2010.12.12"]
1. e4 c5 2. Nf3 d6 3. d4 cxd4 4. Nxd4 Nf6 5. Nc3 a6 6. Be2
e5 7. Nb3 Be7 8. Bg5 O-O 9. Bxf6 Bxf6 10. Qd3 Be6 11. O-O-O Be7 12. g3 a5 13.
a3 Nd7 14. f4 Qb6 15. Nd2 Nc5 16. Qb5 Qxb5 17. Bxb5 exf4 {(Bg4)} 18. gxf4 Bg4
19. Rdf1 f5 20. Rhg1 {(Bc4+)} Bh5 21. Bc4+ Kh8 22. Rg3 Bf6 23. exf5 Bxc3 24.
Rxc3 Rxf5 25. Nb3 {(Bb5)} Raf8 26. Nxc5 dxc5 27. Rb3 Bf7 28. Bxf7 R8xf7 29. Rb5
g5 30. Rxa5 {Elitejustice,Deep Rybka 4 SSE42 x offers a draw} gxf4 31. Ra4 Kg7
32. Re4 Kg6 33. Rf2 {(Kd2)} Rh5 34. a4 Rh4 35. a5 Rf6 {(Kg5)} 36. c3 Rf7 37.
Rc4 {(b3)} Rf5 38. b3 Rg4 39. Kd2 {(Re4)} Rd5+ {(Kg5)} 40. Kc2 Kf5 41. b4 {(h3)
} cxb4 42. cxb4 Rd7 43. h3 Rh4 44. Rf3 Ke5 {(Re7)} 45. b5 Rg7 {(Rf7)} 46. Ra4
Rg2+ {(Kd6)} 47. Kd3 Rg7 48. a6 {(Kd2)} bxa6 49. bxa6 Ra7 50. Kc4 Rh6 51. Kb5
Rf6 52. Rd3 {(Rc3)} Kf5 53. Rc3 Kg5 54. Rf3 Re7 55. Ra1 Rf5+ {(Ra7)} 56. Kc4
Ra7 57. Kb4 Ra8 {(Kg6)} 58. Ra5 {(Ra4)} Rxa5 59. Kxa5 Kf5 60. Rc3 {(Ra3)} Ke4
61. Rc7 {(Rc4+)} h5 62. Rc4+ {(Re7+)} Ke3 63. Rc3+ Kd4 {(Ke4)} 64. Rb3 {(Ra3)}
h4 65. Ra3 {(Rf3)} Ke4 {(Rf8)} 66. Ra4+ Ke3 67. Ra3+ Kf2 68. Rd3 f3 69. Rd7 Rf8
70. a7 Kg2 71. Rd1 {(Rf7)} f2 72. Kb6 {(Kb5)} f1=Q {(Kxh3)} 73. Rxf1 Kxf1 74.
Kb5 {(Ka6)} Kg2 {(Ra8)} 75. Kb6 Rh8 {(Rg8)} 76. Kb7 Re8 {(Kxh3)} 77. a8=Q {
(Ka6)} Rxa8 78. Kxa8 Kxh3 79. Kb7 {(Ka7)} Kg2 80. Kc7 {(Ka8)} h3 81. Kb7 {(Kc6)
} Kf3 82. Kc6 {(Kb6)} h2 83. Kd5 Ke2 84. Ke5 h1=Q 85. Kd6 {(Ke6)} Kf3 86. Kd5 {
(Kc5)} Qb1 87. Kc6 {(Kc5)} Qf5 88. Kd6 {(Kc7)} Qc2 89. Kd5 Qe4+ 90. Kc5 Qa4 91.
Kd5 Ke3 92. Ke6 Qf4 93. Kd5 Kf3 94. Kc5 {(Ke6)} Qh6 95. Kd5 {(Kd4)} Qh4 96. Kc5
Ke3 97. Kc6 {(Kd5)} Qh7 98. Kd6 Qg7 99. Ke6 {(Kd5)} Kf4 100. Kd5 Kg3 101. Kc4 {
(Kc6)} Qg4+ 102. Kc5 {(Kd3)} Qf3 103. Kd6 {(Kc4)} Kh3 104. Ke6 {(Ke7)} Kh2 105.
Kd6 Qf6+ 106. Kd5 Qf5+ 107. Kc4 {(Kc6)} Kg3 108. Kd4 Qe6 109. Kc3 {(Kc5)} Qd7
110. Kc4 {(Kb4)} Qd6 111. Kb5 {(Kb3)} Qd2 112. Kc5 {(Kb6)} Qb2 113. Kc4 Kf3
114. Kd5 Ke2 115. Ke6 {(Kc6)} Qd4 116. Ke7 {(Kf7)} Qc4 117. Kd6 Kf1 118. Ke5 {
(Kd7)} Qb5+ 119. Ke6 {(Kf6)} Qb6+ 120. Ke5 {(Kd7)} Qc5+ 121. Ke6 {(Kf6)} Qc7
122. Kd5 {(Kf6)} Qf7+ 123. Kc6 {(Kd6) Time} 1/2-1/2
[Event "Rated game, 3m"]
[Site "Engine Room"]
[Date "2010.12.12"]
[Round "?"]
[White "Vousatej, Deep Rybka 4 SSE42 "]
[Black "Elitejustice, Deep Rybka 4 SSE42 "]
[Result "1/2-1/2"]
[ECO "B92"]
[WhiteElo "2632"]
[BlackElo "2655"]
[Annotator "0.00;0.00"]
[PlyCount "245"]
[EventDate "2010.12.12"]
1. e4 c5 2. Nf3 d6 3. d4 cxd4 4. Nxd4 Nf6 5. Nc3 a6 6. Be2
e5 7. Nb3 Be7 8. Bg5 O-O 9. Bxf6 Bxf6 10. Qd3 Be6 11. O-O-O Be7 12. g3 a5 13.
a3 Nd7 14. f4 Qb6 15. Nd2 Nc5 16. Qb5 Qxb5 17. Bxb5 exf4 {(Bg4)} 18. gxf4 Bg4
19. Rdf1 f5 20. Rhg1 {(Bc4+)} Bh5 21. Bc4+ Kh8 22. Rg3 Bf6 23. exf5 Bxc3 24.
Rxc3 Rxf5 25. Nb3 {(Bb5)} Raf8 26. Nxc5 dxc5 27. Rb3 Bf7 28. Bxf7 R8xf7 29. Rb5
g5 30. Rxa5 {Elitejustice,Deep Rybka 4 SSE42 x offers a draw} gxf4 31. Ra4 Kg7
32. Re4 Kg6 33. Rf2 {(Kd2)} Rh5 34. a4 Rh4 35. a5 Rf6 {(Kg5)} 36. c3 Rf7 37.
Rc4 {(b3)} Rf5 38. b3 Rg4 39. Kd2 {(Re4)} Rd5+ {(Kg5)} 40. Kc2 Kf5 41. b4 {(h3)
} cxb4 42. cxb4 Rd7 43. h3 Rh4 44. Rf3 Ke5 {(Re7)} 45. b5 Rg7 {(Rf7)} 46. Ra4
Rg2+ {(Kd6)} 47. Kd3 Rg7 48. a6 {(Kd2)} bxa6 49. bxa6 Ra7 50. Kc4 Rh6 51. Kb5
Rf6 52. Rd3 {(Rc3)} Kf5 53. Rc3 Kg5 54. Rf3 Re7 55. Ra1 Rf5+ {(Ra7)} 56. Kc4
Ra7 57. Kb4 Ra8 {(Kg6)} 58. Ra5 {(Ra4)} Rxa5 59. Kxa5 Kf5 60. Rc3 {(Ra3)} Ke4
61. Rc7 {(Rc4+)} h5 62. Rc4+ {(Re7+)} Ke3 63. Rc3+ Kd4 {(Ke4)} 64. Rb3 {(Ra3)}
h4 65. Ra3 {(Rf3)} Ke4 {(Rf8)} 66. Ra4+ Ke3 67. Ra3+ Kf2 68. Rd3 f3 69. Rd7 Rf8
70. a7 Kg2 71. Rd1 {(Rf7)} f2 72. Kb6 {(Kb5)} f1=Q {(Kxh3)} 73. Rxf1 Kxf1 74.
Kb5 {(Ka6)} Kg2 {(Ra8)} 75. Kb6 Rh8 {(Rg8)} 76. Kb7 Re8 {(Kxh3)} 77. a8=Q {
(Ka6)} Rxa8 78. Kxa8 Kxh3 79. Kb7 {(Ka7)} Kg2 80. Kc7 {(Ka8)} h3 81. Kb7 {(Kc6)
} Kf3 82. Kc6 {(Kb6)} h2 83. Kd5 Ke2 84. Ke5 h1=Q 85. Kd6 {(Ke6)} Kf3 86. Kd5 {
(Kc5)} Qb1 87. Kc6 {(Kc5)} Qf5 88. Kd6 {(Kc7)} Qc2 89. Kd5 Qe4+ 90. Kc5 Qa4 91.
Kd5 Ke3 92. Ke6 Qf4 93. Kd5 Kf3 94. Kc5 {(Ke6)} Qh6 95. Kd5 {(Kd4)} Qh4 96. Kc5
Ke3 97. Kc6 {(Kd5)} Qh7 98. Kd6 Qg7 99. Ke6 {(Kd5)} Kf4 100. Kd5 Kg3 101. Kc4 {
(Kc6)} Qg4+ 102. Kc5 {(Kd3)} Qf3 103. Kd6 {(Kc4)} Kh3 104. Ke6 {(Ke7)} Kh2 105.
Kd6 Qf6+ 106. Kd5 Qf5+ 107. Kc4 {(Kc6)} Kg3 108. Kd4 Qe6 109. Kc3 {(Kc5)} Qd7
110. Kc4 {(Kb4)} Qd6 111. Kb5 {(Kb3)} Qd2 112. Kc5 {(Kb6)} Qb2 113. Kc4 Kf3
114. Kd5 Ke2 115. Ke6 {(Kc6)} Qd4 116. Ke7 {(Kf7)} Qc4 117. Kd6 Kf1 118. Ke5 {
(Kd7)} Qb5+ 119. Ke6 {(Kf6)} Qb6+ 120. Ke5 {(Kd7)} Qc5+ 121. Ke6 {(Kf6)} Qc7
122. Kd5 {(Kf6)} Qf7+ 123. Kc6 {(Kd6) Time} 1/2-1/2
I've had this happen before BUT it was a Non-Rybka engine.Remarkably this looks like a bug but I don't think this has been reported before.It also could be a problem with too much hash or a GUI setting is off.Maybe there was a conflict in the reading of the Tablebases vs what the engine wanted to do, but no engine needs TB for this easy mate.Can you reproduce this in your GUI,set it for a shootout with the Rybka engine to see what happens.
OK, I hope I don't get too many angry responses, but this game does proove I am right after all.
1. Both engines played are the same, probably with different settings.
2. It would be a real coincidence that both engines have the same bugs.
3. Elitejustice offered a draw after move 30, but Vousatej didn't accept.
4. If you aggree with the 3 above, and Rybka should know that KQ vs. K is a winning combination, then why didn't Vousatej's engine resigned if he was in this loosing combination.
I still keep to my original thoughts, Rybka simply didn't find the mate in time. This has nothing to do with a bug, but that Rybka just wasn't programmed to know every winning combination in advance, when Vousatej had installed the tablebases, he probably resigned, that is if he installed the 3 piece tablebases and ofcourse if Elitejustice had the tablebases installed, he would have won.
This is ofcourse different if one of the players had the 4-5-6 piece tablebases installed.
1. Both engines played are the same, probably with different settings.
2. It would be a real coincidence that both engines have the same bugs.
3. Elitejustice offered a draw after move 30, but Vousatej didn't accept.
4. If you aggree with the 3 above, and Rybka should know that KQ vs. K is a winning combination, then why didn't Vousatej's engine resigned if he was in this loosing combination.
I still keep to my original thoughts, Rybka simply didn't find the mate in time. This has nothing to do with a bug, but that Rybka just wasn't programmed to know every winning combination in advance, when Vousatej had installed the tablebases, he probably resigned, that is if he installed the 3 piece tablebases and ofcourse if Elitejustice had the tablebases installed, he would have won.
This is ofcourse different if one of the players had the 4-5-6 piece tablebases installed.
OK, this is not at all unusual and when I used to play on Playchess and Rybka 3, I used to have to "fix" all those games in my database as "won" otherwise the database would be corrupted. This is most likely a problem with the GUI and the timestamp from Playchess. Depending on your internet connection, you will have "different" amounts of time to play the move. I sometimes play human games on Playchess and I always gain about 200 ELO in bullet when I play from somewhere in Europe simply because the ping time is so much quicker. Now back to Rybka ... I would first make sure that I have not changed the default time buffer, which if I remember correctly is set to "3". I have seen here posted some people who have changed that to get a better ELO scoring engine, but all you are doing is giving about 3 seconds more thought for the engine by taking it away from the safety buffer ... and in very fast games 3 seconds might make the engine seem stronger even though it really isn't. When we were beta testing Rybka 4, Rybka would sit on a mate position and not play ... it almost seemed like it was trying to test your nerves, but in reality this was in response to people who did not like that Rybka stopped thinking once it spotted a long mate because a shorter mate might be found. So at the moment Rybka will play a mate, but will think in ponder time to look for a quicker mate ... in the meantime the lag of your internet connection is less that the response time for Rybka to give out its move. I will see if I can talk Vas into adding a parameter where you can decide to play immediate mate even if it is longer without looking for a faster mate, that might solve the problem in your case.
So first I would check that the time buffer is default, I would guess that is where the problem is. Rybka 4 testing was not done on Playchess, so it is possible that in very fast no increment games the default setup of time buffer is not enough for some internet connections with "high lag". The timestamp on Playchess is not perfect and tends to give more time to people with fast ping times.
So first I would check that the time buffer is default, I would guess that is where the problem is. Rybka 4 testing was not done on Playchess, so it is possible that in very fast no increment games the default setup of time buffer is not enough for some internet connections with "high lag". The timestamp on Playchess is not perfect and tends to give more time to people with fast ping times.
Topic Rybka Support & Discussion / Rybka Discussion / RYBKA 4--DRAWN GAME THAT SHOULD HAVE BEEN EASILY WON
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill