Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Importance of TBs once more!

Author: Roberto Waldteufel

Date: 16:22:14 10/13/98

Go up one level in this thread



On October 13, 1998 at 17:42:25, Robert Hyatt wrote:

>On October 13, 1998 at 16:14:41, Tim Mirabile wrote:
>
>>On October 13, 1998 at 12:13:21, Bruce Moreland wrote:
>>>
>>>Why did Crafty allow KQ vs KR against any of these?  Didn't it see this as a
>>>forced mate and try to do something to avoid getting into it?
>>>
>>>The only time I can remember being on the weaker side of KQ vs KR was one of the
>>>rare cases that really is drawn (queen stalemates my king, so my rook goes wild
>>>checking their king from one square away).
>>
>>This is bad practice vs. humans though.  A couple of days ago I had a better R+P
>>ending against one of the crafty clones on ICC, and the only way to try to win
>>was to go into a Q vs. R ending, which I would likely not have been able to win
>>at blitz.  But then the thing just refused to take my rook, giving me a Q+R vs.
>>R ending instead.  Has anyone thought of a way to fix this kind of thing yet?
>
>
>
>yes... you need KQRKR database, which I have.  :)  then that just pushes this
>nonsense off a little further.  The opposite is to be in a KRPPP vs KR and
>*force* the opponent to take two pawns leaving a won KRP vs KR.  :)

I wonder to what limits we might push the tablebases. Suppose you have, say, the
stronger side of KRPPKR, and suppose that you construct two simpler positions by
removing in turn each of your pawns. These two simpler positions are KRPKR
positions, so you can look up a score for each of them in the KRPKR tablebase.
Suppose that one (or both) of them is winning for you. How often is it then the
case that the additional extra pawn can change this result. I am exploiting an
underlying assumption that if you take any winning KRPKR position and give
yourself an extra pawn on an arbitrary square, the position is still winning. If
I push this a stage further, I might guess that the best move in the KRPKR won
position would, if it is legal, also win in the KRPPKP position as well. If this
were the case, the program could extend the tablebases beyond their actual
scope, and at the same time perhaps cure the problem of the silly moves where a
program throws away material, albeit to reach a won tablebase position, as these
moves are inefficient and have a rather bad asthaetic effect.

The big question is how often the above hypotheses hold. If they fail often, my
proposal is rubbish! How could the addition of an extra friendly pawn, or it
could even be a piece, spoil an otherwise winning position? Possibly due to
introducing stalemate possibilities, or by blocking a square necessary for one
of the other pieces perhaps. It would be interesting to know how rare (or
frequent) such cases are. If they are very rare, it might pay off to take the
risk and terminate the search in such positions.

I can think of a test for this kind of reasoning you could easily do if you have
all 4-piece endings. Try, for example, comparing KPPK and KPK tablebases (like
the orriginal example, but without the rooks). Since you have all the data for
both cases, you could search through all KPK positions, and for those that are
wins, try adding another pawn on all possible legal squares. Can you find any
drawn KPPK positions in this way? If there are none, then you could make
inferences about the outcome of many KPPK positions from the KPK tablebase.
Maybe we could score many KPPKP positions bases on KPKP database. If you try
this, please let me know the results.

Roberto



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.