Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: KQ vs kr position

Author: Ricardo Gibert

Date: 14:17:24 08/04/99

Go up one level in this thread


On August 04, 1999 at 16:45:32, Robert Hyatt wrote:

>On August 04, 1999 at 12:29:08, Ricardo Gibert wrote:
>
>>On August 04, 1999 at 09:19:56, Robert Hyatt wrote:
>>
>>>On August 03, 1999 at 23:13:13, Ricardo Gibert wrote:
>>>
>>>>On August 03, 1999 at 21:54:23, Robert Hyatt wrote:
>>>>
>>>>>On August 03, 1999 at 15:34:54, Ricardo Gibert wrote:
>>>>>
>>>>>>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.
>>>>>>
>>>>>
>>>>>you are wrong here.  I play move A, then move B (which unmakes move A),
>>>>>then move A again, then move B again, and now I probe the table, and it
>>>>>says if you play move X you win the rook in 4 moves.  Unfortunately,
>>>>>a couple of moves before you win the rook, you play move A again and
>>>>>the position is repeated and the game ends as a draw.
>>>>
>>>>The EGTBs hits should be "part" of the eval. A tool. You catch 3 fold reps the
>>>>same way you always do. For example, distance to mate also would have this
>>>>"problem". What difference does it make if you find mate or win of a rook?
>>>
>>>>
>>>>Besides, after you play A the 1st time, you probe and find move X to win the
>>>>rook. No draw.
>>>>
>>>
>>>
>>>this is going in circles.  This was _my_ argument.  then _you_ pointed out
>>>you were talking about doing a probe _after_ an adjournament.  And there, the
>>>problem is going to come up and there is no solution for it.
>>>
>>>If my program plays the whole game, this will _never_ be a problem.  If you
>>>give it a position to play after someone else has played a bunch of moves,
>>>then this wil never work properly.
>>>
>>
>>It will be a problem regardless (unless you also provide the game score) of how
>>you do it. "My way" addresses the 50-move problem.
>>>
>
>
>I don't think it is a problem at all, at present, as I don't know of any 5
>piece files that have more than 50 moves without a pawn move or capture.

KNNKP

But I am talking about producing an adjournment analysis where I need to avoid
the 50 move rule due to my sub-optimal play.

Example: I adjourn in a KQKR ending and I need to make a winning capture or mate
in 5 moves to win and avoid the 50 move rule draw. A mate in 6 won't do it. "My
way" just tells me the answer. It returns whatever is quicker, the win of the
rook or mate. It won't deal with 3 fold repetition gracefully, but we are
talking about the 50 move rule here.

>However, the 6 piece endings are a serious problem in this regard.  Someone
>might probe the tablebase files for the deepest mates and then follow the PV
>(by looking at the scores as you step forward) to see if there is a PV in the
>thing that has more than 50 non-capture/non-pawn-move moves in it.  Lewis
>Stiller has already proven that this is a problem in 6 piece files.
>
>Many years ago I did an experiment to see if this was 'fixable' by building a
>KBN vs K database... but I added one new rule, if all three pieces don't get
>moved within a 10-move window, the game is a draw.  I ended up storing a
>'DTM' score _and_ a "conversion" score... where a conversion occurred everytime
>the 'third' piece was moved to reset the counter.  It seemed to work, with the
>only problem being 'database entry'.  IE when you first hit the database, the
>DTC might be (say) 7, yet it might be that more than 3 moves have been played
>in the real game (again, assuming starting from a position rather than from the
>beginning of the game).  To fix this, I started out by simply playing the move
>or moves that would get the 10-move-rule counter back to zero, and _then_ using
>the DTM/DTC values as you suggest.  And it worked except for a few oddball cases
>that were not really fixable... it might be that the only moves that reset the
>10-move-rule counter lead to tablebase draws because you have already played
>ineffectively before you started hitting the databases (remember, these were
>positions that the program was just given, not positions it had been playing
>from the beginning.)
>
>Whether all of the issues of 'adjourned' analysis can be resolved or not is
>a question.  My initial thought is "no".  Because it is definitely possible to
>be in a won position, but by fiddling around before using the tablebases, you
>have reached a position that will run afoul of the 50-move rule before winning,
>and there are no options to win a piece (ie KBN vs K, where you have played 30
>moves already, and the resulting position is a mate in > 20 no matter what you
>do, and there is nothing to win or no pawn to push to reset the counter.)
>
>Sticky problem...
>
>
>
>
>>>
>>>>>
>>>>>If you don't have state information in the database, there is _no_ way
>>>>>to probe it and ask about such things.. because it says you can capture
>>>>>a piece in 29 moves, but how many _prior_ positions of yours do you repeat
>>>>>before doing so?
>>>>>
>>>>>This is an old discussion.  There are _many_ problems here...
>>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>>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 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.