Computer Chess Club Archives


Search

Terms

Messages

Subject: Interesting EGTB bug

Author: Tom Likens

Date: 20:15:47 04/16/02



Hello Everyone,

I recently had what I considered an interesting endgame tablebase bug which
cost my program 1/2 a point on ICS.  The problem occurred when a KR vs. KR
endgame was reached and the opponent captured the program's rook.  Instead of
grabbing the rook with its king it moved the king away and immediately lost the
game.  Looking at the log file revealed that it had been in the endgame
tablebases for a while.  In fact, the way I structure this is that if I'm not
in swindle mode and the root position is a tablebase draw then it simply prints
out the PV to the maximum search depth and returns (skipping the search
entirely).

The problem was that the EGTB probe code did not recognize the K vs. K
situation as a draw (essentially a case of missing the 2-man tablebase file).
So instead of leaving the tablebases it played a losing move that kept it in
the tablebases, aarrgghh!!  Simple to fix, but it begs the larger question of
what happens in general if a program has access to an N piece tablebase but
not all the N-1 piece tablebases that the position could become if a piece or
pieces were traded off.  Since the tablebases represent "perfect" knowledge I
give them preference over values returned by the evaluation function.  Could
this phenomenon be at work in subtle ways during the regular search,
influencing the program into staying in the tablebase no matter what the cost?

How do other programmers handle this?  Or is it even a real problem?

regards,
--tom



This page took 0.16 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.