Author: Tom Likens
Date: 13:34:31 04/19/02
Go up one level in this thread
On April 19, 2002 at 13:47:38, Dieter Buerssner wrote:
>On April 19, 2002 at 12:31:14, Tom Likens wrote:
>
>>On April 17, 2002 at 03:09:12, Tony Werten wrote:
>>
>>>Search for the current position in the tablebase. Then try all moves and search
>>>them in egtb as well. If the best move is not following the current position (ie
>>>also draw, checkmate or checkmated in rootposition-1) then disable egtb's and
>>>don't retry until a piece is captured or promoted.
>
>I think, the only practical problem is the winning case. With draw, and say the
>drawing move is missing from the TBs, you will get either no TB hits, or some
>TBhits, that show, you are lost. The normal search will handle this, and will do
>one of the other moves. When checkmated in the future, well - nothing
>disasterous can happen anymore anyway.
>
>BTW. It is enough, to disable TB access of positions of the same number of
>pieces, than the root position. For example in the KRPKR case, with missing
>KQRKR, it is no problem to still access all the 4-men TBs, and may even still
>help, to find the correct move.
>
>>This doesn't seem to handle the more general case of problems deep in the
>>search. For example, in the position:
>>
>>[D]4K2k/8/5P2/6R1/8/r7/8/8 w - - 0 1
>>
>>If we assume the program has the KRPKR tablebases but *not* the KQRKR
>>tablebases then part of the search looks like this:
>>
>> root [KRPKR] hit
>> /
>> 1 f7 { move A }
>> [KRPKR] hit
>> /
>> 1... Rf3 {move B} <-- This is the last "good" tablebase score
>> [KRPKR] hit
>> /
>> 2 f8=Q+ {move C} <-- This value can't be trusted as perfect
>> [KQRKR] miss knowledge.
>>
>>When updating the PV with tablebase moves {move C} should be trucated since
>>it represents an untrustworthy value. But the moves A and B *are* valid and
>>should be preserved. Here this is a trivial case, but it becomes much more
>>interesting deep in a search when these moves don't represent plies 1,2 and 3
>>but 11, 12 and 13. The natural place to handle this is in the function that
>>manages the updating of the PV when a tablebase hit occurs.
>
>I don't understand your problem. For practical playing, it won't make a
>difference, as long, as you don't have a won TB position at the root, where the
>position(s) after the winning move(s) cannot be found in TBs (most probably
>because it is a promotion, but it might also be a capture, from a 5-men
>position, and the 4-men TB is missing. The later case has probably no practical
>relevance, because of the size of the complete set of 4-men TBs).
>
>Showing a correct PV, is not improtant for practical play (here).
I think we actually agree here. My previous post was a roundabout way of
saying that when a tablebase hit occurs simply return from that node with
an appropriately adjusted PV. And you're right for practical play this
shouldn't make any difference. Still, half the fun of computer chess is
understanding the "impractical" aspects of it.
>>One other possiblity that occurs to me is that the program could actually
>>play out the moves and then restart the normal search at the end of variation,
>>effectively leapfrogging a few plies.
>
>Yes. But this would only be needed to show a long PV. And as discussed above,
>only when this situation is at the root, some measures have to be taken.
Yep, but when analyzing this might be nice to have.
regards,
--tom
>BTW. Even without any tricks (like disabling TB access in critical positions),
>in many problematic cases the search would find the right move, when the program
>does not stop searching, when it sees any mate, but rather tries to find a
>shorter mate. This, and also not allowing TB access when the position was
>already repeated, would solve almost all "missing TB artifacts", but the
>temporarily disabling as discribed by Tony is certainly the better solution.
>
>Regards,
>Dieter
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.