Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: KQ vs kr position

Author: Ricardo Gibert

Date: 19:47:14 08/02/99

Go up one level in this thread


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.

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?

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.

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.

>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.02 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.