Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: not using nullmove?

Author: Dann Corbit

Date: 18:02:38 02/17/04

Go up one level in this thread


On February 17, 2004 at 21:00:08, Dann Corbit wrote:

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

The position could be implicit [based on the hash value], requiring only 2 bits
per position.  If it were that compact, you would need a bitset/bitget operation
to pull the bits, since you can't address something smaller than one character.



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.