Author: Dieter Buerssner
Date: 10:47:38 04/19/02
Go up one level in this thread
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).
>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.
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.