Author: Christophe Theron
Date: 23:49:54 11/30/00
Go up one level in this thread
On November 30, 2000 at 02:33:06, Scott Gasch wrote:
>Hi,
>
>I've recently been working on an SEE also and find that the best way to verify
>it is to just construct a position where there are pins and xray attacks and
>then walk through the SEE code in a debugger. It's not very fun but I think I
>have found all the "issues" now. Here's an interesting FEN to start with. It
>has no pins but I tested that code with a breakpoint and a search...
>
>[D]r3k2r/ppq2ppp/1pnbbn2/3pp3/3PP3/1PNBBN2/PPQ2PPP/R3K2R w KQkq - 2 0
>
>I really liked your idea about eval testing with symmetric positions. One thing
>I do (that probably a lot of others do also) is to put a bunch of asserts all
>over the code that get compiled out in a "fast" version. I have three levels of
>debugger code -- none, normal and paranoid. The paranoid setting does things
>like calculate the pawn eval numbers even if it got a hash hit and then compare
>the scores with what was in the hash... save a copy of the board before the
>MakeMove / UnmakeMove sequence in search and then compare it after it comes
>out... etc. Whereas the normal debug level is just your typical asserts... "I
>just captured a piece... make sure it was the right color" or "I expect a pawn
>to be at square X".
>
>That's about all I have to say... would love to hear some more original ideas
>about testing engines!
>
>Scott
What you are doing is the right thing to do.
I have the same overly paranoid debug code spread all over Chess Tiger's
sources. After so many years of chess programming, it turns out that it is not
paranoid at all. It is just enough to catch very nasty bugs.
So from time to time, without any special immediate need, I add paranoid
checking code. I have #if (DEBUG_xxx) conditionals all over the sources
(DEBUG_xxx allowing to turn on checking code for a specific thing).
A very efficient way to find bugs is to have several versions of the same
routine. For example, generate moves in several different ways, collect the
resulting moves lists, and compare them. That's what I do in "debug genmove"
mode. I have also a code that compares the incrementally computed hash codes to
hash codes computed from scratch in every position. An obvious thing to check, I
would say.
From time to time I launch a big test. The program has to compute a given number
of fixed positions to a given ply depth with all the debug code turned on. It
runs 20 times slower than the normal version, but I feel more comfortable once I
have run this test and no error has been found. The goal is not to check if the
program finds the right moves for the positions, but just to check that the
debug code does not catch a problem.
However, it's never enough. Let the program play automatically 400 games and it
might find itself another well hidden bug.
Christophe
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.