Author: Vincent Diepeveen
Date: 15:14:49 06/16/05
Go up one level in this thread
On June 16, 2005 at 03:50:17, Ed Schröder wrote: >On June 15, 2005 at 16:36:54, Eric Oldre wrote: > >>I was wondering if anyone would like to volunteer any tricks they've >>used to help find certain bugs in their search function. >> >>I think that the ideas of using perft for move generation and >>reversing the board to find bugs in the evaluation have both >>been really useful to me. I was wondering if anyone has used >>techniques similar to these to help find search bugs. >> >>I understand that just because a engine can properly pass these >>and other tests doesn't mean it's free of bugs. But they certainly >>help detect at least some of them. >> >>I'm certain that there must be plenty of bugs in Latista's search >>and I think it's time for me to work on discovering them. If >>you don't have any automated tricks like above. Does anyone >>have any general advise to help me spot some bugs? >> >>Eric Oldre >> >>PS. I have at various spots in my program tried to follow a similar >>model of asserts as in fruit. I'm sure taking some time to >>do this at more parts of my program would help. > > >As an addition to all the hints of others consider a piece of software that sets >a breakpoint based on the move list. > >[d]Rnk1r2r/1p1b2p1/1Pq1p1n1/2Ppp1p1/1QP5/5N2/5PPP/5RK1 w - - > >Say your program can't find the easy 1.Rxb8+ Kxb8 2.Ra1! within a reasonable >depth then set a breakpoint on 2.Ra1 and then go step by step through the search >(for instance) by the space bar in the meantime displaying all the relevant >information on the screen. >Ed Oh well, i might be doing that far faster. I just walk through the hashtable what move gave a cutoff for Ra1. In such a case i can skip slow debugging with the debugger. I see in 5 seconds the problem from the hashtable in such a case. Vincent
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.