Computer Chess Club Archives




Subject: Re: not using nullmove?

Author: Dann Corbit

Date: 18:00:08 02/17/04

Go up one level in this thread

On February 17, 2004 at 20:55:13, Dann Corbit wrote:

>On February 17, 2004 at 12:03:03, Tord Romstad wrote:
>>On February 17, 2004 at 08:19:28, martin fierz wrote:
>>>On February 17, 2004 at 07:55:32, Tord Romstad wrote:
>>>>KR vs KP is a difficult one.  Does anybody have any good suggestions about
>>>>how to evaluate it?  At the moment I don't have any specific code for this
>>>>endgame at all, and Gothmog almost always evaluates it as a win for the rook.
>>>>In reality, it is of course very often a draw.
>>>i'll have to think about this one too. i haven't done either KR-KP or KQ-KP;
>>>KQ-KP should be rather easy as there are basically only two drawing positions;
>>Yes.  KQ-KP is much easier, and also less important, because the probability
>>of a draw is much smaller here.
>>>KR-KP is much harder. but you should at least be able to easily identify many
>>>cases where KR is clearly winning; e.g. any time the KR-side king is in the
>>>square of the pawn KR is winning (with one exception: wKe2, bPd2, bKf1/f2, black
>>>to move, but qsearch should catch that).
>>This is a good start, but I think it might be more valuable to work
>>from the other end:  Which positions do we know are drawn?  I guess
>>the probability of a draw is big if the pawn is on the fifth rank or
>>beyond and supported by the king, and the attacking king is far away.
>>But this is certainly too simple to be a sure drawing rule.
>>There is also not many clear rules to be found in Keres' "Practical
>>Chess Endings" (my main endgame reference), which makes me fear that
>>it is not easy to evaluate this endgame correctly.
>Here's a dumb idea:
>Write a program to scan a Nalimov database, but throw away everything except
>won/lost/drawn/broken (needs 2 bits per reflected board position to store the
>outcome state).
>Then write a table.
>For up to the 4 man tables, it should be really tiny and fit into ram without
>any fuss.
>Seems like one single program could write a recognizer for anything [for which a
>Nalimov or Edwards or Thompson EGTB exists].

One step further:
For the list of possible board positions for a given class (e.g. KRK) create a
list of them.  Then create a perfect hash for these positions.

Then, in your program, the table holds:
HASHVAL, won/lost/drawn/brokenbits

If (for instance) there were 65,000 possible postions after all reflections and
rotations, then you would only need 18 bits per position to store the hash and
the answer.

This page took 0.03 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.