Author: Ross Boyd
Date: 21:53:38 06/15/05
Go up one level in this thread
On June 15, 2005 at 19:07:27, Dann Corbit 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. > >Function to dump the current board [an absolute necessity]. >Function to generate the hash from scratch and also incrementally and compare >the two (bad hash and the search is hosed) >Function to mirror the board and see if solutions are identical (but mirrorred) >Function to change colors and side to move and see if solutions are identical >(but reversed for color) >Function to list node counts by type (normal, qsearch, hashhit...) >Function to check for capture of a king >Function to check for both sides in check >Function to save complete move state with memcpy and then compare with >makemove/unmakemove to see that they are identical >Function to count hash collisions >Function to count hash table transposition hits (found it, regardless of depth) >Function to count hash table transposition success (found it, deep enough to >use) > >Probably lots more things, but these spring to mind. Some are more eval >oriented, but are also helpful if the search has gone bonkers. Yes, everything that Dann has listed above... plus... 1) use tons of assert()s... make sure all parameters are valid or within range. 2) Write two move generators, one that is slow and deadly accurate and compare it with your optimised version. 3) Validate all input is legal, especially moves and FEN positions. 4) Functions to compute piece/square and material balance, and compare it with your incremental ones. 5) EP captures always seem to be a hotspot for bugs. Make sure you test ep moves for discovered checks properly. eg. in the following diagram, after black plays d7d5, if white plays e5xd6 ep, then its a discovered check... [D]8/3p4/8/KR2P2k/8/8/8/8 b - - 0 1 For qsearch tuning: 1) Functions which verify delta pruning is not pruning moves that would have raised alpha. 2) Functions which verify the accuracy of your SEE. (this function would be a recursive function to do swap-offs on a given square, and returning the minimaxed gain/loss.) For move ordering tuning: 1) Keep a count of how many beta cuts occurred, and how many were found on the first move. 2) Create a multitude of varied test positions. Compare different move ordering methods by comparing nodes to reach depth. (Its IMPORTANT not to change anything except the move ordering heuristics while doing this or the results become completely useless for making comparisons) For evaluation tuning: 1) Add evaluation debug code to break down the evaluation into its fundamental parts. eg. piece/square, pawn structure, king safety, outposts, mobility, etc.. 2) Breakdown eval on a piece by piece basis. Detailed descriptions of pawn structure weaknesses/strengths... eg Pawn on e4 is isolated,doubled, passed or backward. BR on H8 is trapped, etc etc 3) If you support egtb's, compare egtb result with your evaluation score... LOTS of elo to be found here regarding misevaluations of basic endings. If the egtb probe returns a mate score, be sure your eval is returning a darn good winning score. And for egtb draws, your eval should return a draw or something VERY close to it. Of course, there are some endings that are inherently difficult to score statically. For GUI interface debugging: 1) Optionally, log all i/o to a file. Compare with GUI debug file. Some GUI's are not at all faithful to the WB and/or UCI protocols. You have to defend your engine against this. But most of all, have fun! Ross
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.