Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: KQ vs kr position

Author: Ricardo Gibert

Date: 12:34:54 08/03/99

Go up one level in this thread


On August 03, 1999 at 14:28:04, Robert Hyatt wrote:

>On August 03, 1999 at 10:28:25, Ricardo Gibert wrote:
>
>>On August 03, 1999 at 09:00:33, Robert Hyatt wrote:
>>
>>>On August 03, 1999 at 04:45:07, Ricardo Gibert wrote:
>>>
>>>>On August 03, 1999 at 04:32:27, Bruce Moreland wrote:
>>>>
>>>>>
>>>>>On August 02, 1999 at 22:47:14, Ricardo Gibert wrote:
>>>>>
>>>>>
>>>>>>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.
>>>>>
>>>>>I would be suprised if the Nalimov tables are *not* distance to mate.  The only
>>>>>publicly available distance to conversion tables that I know of are the Thompson
>>>>>tables.
>>>>
>>>>Shortest mate EGTB also has the defect of possibly concluding that an ending is
>>>>drawn due to the 50 move when it is actually winning. By the way, I think this
>>>>issue can be cleared up by noting that "distance to mate" is not necessarily the
>>>>same as "shortest mate".
>>>
>>>
>>>
>>>first, 50 move draw is _not_ included.  How could it be?  Because you have
>>>_no_ idea what position you will enter the database at...
>>>
>>>and distance to mate _is_ "shortest distance to mate" absolutely...
>>>
>>Then this means the EGTB will prefer a mate in 51 without pawns moves or
>>captures to a mate in 52 with a pawn move or capture before the 50 move rule
>>kicks in. It will draw winning positions. Undesirable and unnecessary.
>>Fortunately rare.
>>>
>
>
>yes... but this is a problem no matter what.  Because the tablebase is just
>a file that is indexed by piece location, and it provides mated-in-N, draw, or
>mate-in-N.  It has _no_ idea about prior positions and what might have
>transpired before reaching this position.  It can't even tell if this position
>is a successor of another position in this file, or if it was reached via a
>capture with a zero 50-move counter.

prior positions are irrelevant.

>
>deep mates are going to be a problem in 6 piece files, no doubt about it.  It
>would be interesting to see if there are already violations of this in the 5
>piece files...
>
>
>
>>>
>>>
>>>>>
>>>>>And yes, the tables do suffer from the possible problem that you mentioned,
>>>>>although this should be extremely rare in practice.
>>>>>
>>>>>bruce



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.