Author: Robert Hyatt
Date: 05:58:35 08/03/99
Go up one level in this thread
On August 02, 1999 at 22:47:14, Ricardo Gibert wrote: >On August 02, 1999 at 20:49:56, Dann Corbit wrote: > >>On August 02, 1999 at 20:06:07, Ricardo Gibert wrote: >> >>>On August 02, 1999 at 18:15:27, Jeff Anderson wrote: >>> >>>>Could someone with access to the KQ v kr endgame tablebase tell me how many >>>>moves before Black mates in this position? >>> >>>I believe the tablebases are not optimized for finding the shortest mate. For >>>instance, in this case, it finds the shortest route to mate OR win the rook. >>>After winning the rook, it then finds the shortest mate from there. So it is >>>possible the "best" play generated by the table base is not the shortest mate. >>>It is also possible for a tablebase, organized differently, can give a solution >>>of a different length than another tablebase, though I would not expect that >>>here. >>> >>>So "perfection" is not guaranteed, but it does have the virtue of being optimal >>>in the light of the 50 move rule. In other words, it is possible that a position >>>is winnable without exceeding the 50 move rule, but the "shortest mate" would >>>exceed the 50 move rule. Of course, in that case it would not really be the >>>"shortest mate." I would be interested in seeing an example position of this if >>>someone has it. >>The Nalimov tablebase files have distance to mate. But as a confirmation, here >>is the output of Chest: > >With Nalimov, it is possible that is always the case for KQKR as memory >requirements are not a factor to generate a shortest mate EGTB for this ending, >but I've already given a reason why this is undesirable. > >The reason can manifest itself in the case where you have adjourned in an KQKR >ending (human vs human) and have only x numbers of moves to avoid the 50 move >rule. Using a tablebase for your adjournment analysis that gives "shortest mate" >instead of "shortest win of rook or mate" could be a problem. this can't possibly happen unless someone has a bug. KQ vs KR is _never_ won in more than 50 moves. So at the point where the program reached this ending, it plays it optimally. Your case could not possibly happen. In other endings, this is a possible problem, but only if it is mate in > 50 from the starting position where the ending is reached. > >Objectively speaking, it is never wrong to win the rook instead. Subjectively >speaking, your opponent is bound to resign after losing the rook anyway. >Shortest win can be faster than the shortest mate in that case. > >Your post is a little ambiguous. Are you saying Nalimov EGTB is a shortest mate >EGTB for all the 5 man endings? How would the tables be generated? this is correct. You start by enumerating all possible 5 man positions, and marking the ones that are "mate" and then working backward. Takes a lot of time to build, not time to probe. > >I would be surprised if all the endings covered by the Nalimov EGTB are of the >shortest mate variety. I would also be disappointed for the reason indicated. >Some endings (other than KQKR which a computer program can win in about 34 >moves) would be "impossible" to win using such a TB due to the 50 move rule. > Eugene does use distance-to-mate in all files... >By the way, back in the days when a 20mhz 386 was a high end machine, I helped a >friend of mine learn how to play KQKR perfectly using the Thompson EGTB. I >myself learned how to do it within the 50 move rule. Not so easy against a >computer even though I am a master. Miles & Browne are 2 well known players that >have been embarassed. I don't think I can do it today. > >My friend showed up for a big tournament in Canada (St. Johns?) where a guy was >showing off his program that could play KQKR. I guess he got a kick out of >embarassing all the titled players there. My friend consistently won the ending >in the "optimal" number of moves. The guy couldn't believe it. > this ending is remarkably easy to win, even without databases. I ran several tests last year and was surprised that even at a couple of seconds per move, Crafty could win using no tablebases, against a version of itself that did. >>Reading job: >>W: Kg2 Rf2 (2) >>B: Kg4 Qa2 (2) >>FEN: 8/8/8/8/6k1/8/q4RK1/8 b - - >>analysing (mate in 14 moves): >>No solution in 14 moves. >>refu 1: Qa8+ Kf1 [ 13-] >>solu 1: Rf3 [ 4+] >>solu 2: Kh2 [ 12+] >>solu 3: Kg1 [ 10+] >>refu 2: Qd5+ Kf1 [ 13-] >>solu 4: Rf3 [ 4+] >>solu 5: Kg1 [ 4+] >>solu 6: Kh2 [ 13+] >>refu 3: Qa3 Kg1 [ 13-] >>solu 7: Rd2 [ 5+] >>solu 8: Rc2 [ 11+] >>solu 9: Rf6 [ 12+] >>solu 10: Rf4+ [ 4+] >>solu 11: Rf7 [ 13+] >>solu 12: Rf1 [ 8+] >>solu 13: Kh2 [ 5+] >>solu 14: Rf5 [ 6+] >>solu 15: Rf3 [ 4+] >>solu 16: Rf8 [ 4+] >>solu 17: Re2 [ 4+] >>refu 4: Qa4 Rd2 [ 13-] >>solu 18: Rf6 [ 11+] >>solu 19: Rf7 [ 12+] >>solu 20: Rf8 [ 13+] >>refu 5: Qa5 Re2 [ 13-] >>solu 21: Rf4+ [ 4+] >>solu 22: Rc2 [ 12+] >>solu 23: Rf6 [ 11+] >>solu 24: Rf7 [ 7+] >>solu 25: Rf1 [ 6+] >>solu 26: Rf8 [ 13+] >>solu 27: Rb2 [ 11+] >>solu 28: Rf3 [ 4+] >>solu 29: Kh2 [ 12+] >>solu 30: Rf5 [ 4+] >>refu 6: Qa6 Rd2 [ 13-] >>solu 31: Rf4+ [ 4+] >>solu 32: Re2 [ 3+] >>refu 7: Qa7 Rc2 [ 13-] >>solu 33: Rf4+ [ 4+] >>solu 34: Kg1 [ 3+] >>refu 8: Qa1 Rf8 [ 13-] >>solu 35: Rf4+ [ 4+] >>solu 36: Rf6 [ 4+] >>solu 37: Rb2 [ 3+] >>refu 9: Qb3 Kg1 [ 13-] >>solu 38: Rf4+ [ 4+] >>solu 39: Rd2 [ 5+] >>solu 40: Rf6 [ 11+] >>solu 41: Rf5 [ 5+] >>solu 42: Ra2 [ 3+] >>solu 43: Rf8 [ 13+] >>solu 44: Rf1 [ 6+] >>solu 45: Kh2 [ 5+] >>solu 46: Rf3 [ 4+] >>solu 47: Rf7 [ 4+] >>solu 48: Re2 [ 4+] >>refu 10: Qc4 Rd2 [ 13-] >>solu 49: Rf6 [ 11+] >>solu 50: Rf4+ [ 3+] >>solu 51: Rf5 [ 6+] >>solu 52: Rf3 [ 4+] >>solu 53: Rf7 [ 4+] >>solu 54: Rf1 [ 6+] >>solu 55: Re2 [ 3+] >>solu 56: Rc2 [ 3+] >>solu 57: Ra2 [ 3+] >>solu 58: Rf8 [ 13+] >>refu 11: Qe6 Rd2 [ 13-] >>solu 59: Rf4+ [ 4+] >>refu 12: Qg8 Rd2 [ 13-] >>solu 60: Rf4+ [ 4+] >>solu 61: Rf3 [ 4+] >>refu 13: Qb1 Rf8 [ 13-] >>solu 62: Rf4+ [ 4+] >>solu 63: Rf7 [ 12+] >>solu 64: Rf6 [ 11+] >>solu 65: Rf5 [ 4+] >>solu 66: Rc2 [ 3+] >>solu 67: Ra2 [ 3+] >>Time (user) = 856.00 sec (ca. 14.3 min)
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.