Author: Leen Ammeraal
Date: 22:25:02 04/16/02
Go up one level in this thread
On April 16, 2002 at 23:15:47, Tom Likens wrote: > >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. ... I cannot remember having had problems with this situation. But there is a similar case, which was more serious for me: the program may be dealing with N-piece tablebases in which one of the N pieces is a pawn, which is about to promote, while the corresponding N-piece tablebases with that pawn replaced with a queen is lacking. The effect was that the pawn refused to promote. For this reason, I now temporarily switch off tablebase probing when a pawn is about to promote. Leen
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.