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.