Author: Keith Evans
Date: 20:57:52 03/03/04
Go up one level in this thread
On March 03, 2004 at 16:45:21, Andrew Wagner wrote: >Hmm, you guys are fast, but I'm not sure either of you actually completely read >my post :). The two keys are > >1.) "mass-produce" (i.e. not copy and paste a fen and type 'perft 1', 'perft 2', >etc.) > >and 2.) "my own positions" - the ones on peter's site are great, but if your >program is off in one of those positions it's very hard to track down a bug from >it. I want to put together a list of simple positions that will test perft for >very specific things. in fact, here, let me paste my first set of test >positions, for castling: > This approach makes it easy to debug: http://chessprogramming.org/cccsearch/ccc.php?art_id=333116 Until to try it yourself you probably won't believe it, but this really makes it easy to debug when stuff goes wrong. I debugged a hardware move generator written in Verilog this way - so it's applicable to any language and maybe any movegen architecture. The important thing is that you sort your movelist, sort crafty's movelist and then do a diff. You will see exactly what's wrong (missing or extra moves), and then you can look through your unsorted movelist, search for the point where the error was made, and you'll know the problem very quickly. If you use this approach on a reasonable machine and os, then you can debug perft's with millions of moves. No problem. I wouldn't do it any other way - comparing perft #'s is a good way to tell when your stuff is working, but not useful for debugging IMHO. -Keith
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.