A Debugging Strategy

[Fguy64]

OK one thing my program does not have yet is proper diagnostics output, PV or perftt or whatever you want to call it. But I do know what level1 node is being searched when something weird happens. So, if my alpha-beta is working properly, the following should work (I think)

As I see it, If I know what level1 move is being searched when the program craps out, then I should be able to make that move manually, reduce the ply by 1, restart the engine, and the engine should crap out in the exact same position.

Agreed?

[Gian-Carlo Pascutto]

Only if the fault isn't caused by something else going wrong earlier...

[Fguy64]

Only if the fault isn't caused by something else going wrong earlier...

noted thanks. I'll take that as a qualified yes.

I've recently refined my moveGen, and I'm 99% sure the problem is there, a certain position isn't being handled properly. And so I'm 99% sure that the problem will arise regardless of how the position is reached. I just have to find the position.

[jwes]

I would strongly recommend that you implement perft with a divide option. Until you know that your move generator is correct, you will find that apparent search bugs are often actually move generation bugs, and debugging will be slow and frustrating.

[Fguy64]

I would strongly recommend that you implement perft with a divide option. Until you know that your move generator is correct, you will find that apparent search bugs are often actually move generation bugs, and debugging will be slow and frustrating.

Noted, thanks. Yes I am beginning to see it would help. It's on my wish list. Soon, but I only got my alpha-beta working yesterday.

Anyways, this was a runtime exception that crashed the program, the stack trace pretty much told me moveGen, and because I always know which level1 node is being searched it was easy enough to step through the tree and find the problem position. My moveGen was working before, but I had to rewrite the promotion code, and it was just a logic error which allowed a pawn to exist on the 8th rank, and a runtime error was created when movGen was applied to that pawn.

regards.

[hgm]

Agreed?

No. This usualy does not work. What happens in the engine if you search the position as root is completely different from when you search it from a level=1 node. The window is different, the hash-table contents is different (you get other hits or misses), etc. Very often the error simply disappears.

The way I always do it is make all the debug printouts in my code conditional on the node I am in, through if(PATH) statements, where I then #define PATH as (say) level==3 && move[1]==... && move[2]==... && move[3]==...
Usually I print the move that is made in MakeMove(), (which also puts that move in the array move[]), and again in UnMake(), so if something goes wrong (even a crash) I know after which move this happend, and then I add that move to the PATH, to get one step closer to the point of the error, and then I rerun the search exactly as before. Eventually this brings me to the node of the error. (If the error occured between taking back a move and making the next one, you know it does occur in the current node.)

[Fguy64]

Agreed?

No. This usualy does not work. What happens in the engine if you search the position as root is completely different from when you search it from a level=1 node. The window is different, the hash-table contents is different (you get other hits or misses), etc. Very often the error simply disappears.

The way I always do it is make all the debug printouts in my code conditional on the node I am in, through if(PATH) statements, where I then #define PATH as (say) level==3 && move[1]==... && move[2]==... && move[3]==...
Usually I print the move that is made in MakeMove(), (which also puts that move in the array move[]), and again in UnMake(), so if something goes wrong (even a crash) I know after which move this happend, and then I add that move to the PATH, to get one step closer to the point of the error, and then I rerun the search exactly as before. Eventually this brings me to the node of the error. (If the error occured between taking back a move and making the next one, you know it does occur in the current node.)

point taken, thanks.

I don't disagree, but I should clarify that so far I don't have a hash table and I don't think I have a window. or iterative deepening or anything else. At the moment it is straight up fixed depth negamax/alphabeta. And my evaluation is strictly on material. The bare bones, which as I see it is pretty much black and white.

Anyways, I can't say the strategy will work every time, but it's worked often enough to make it useful.

regards.

[hgm]

With alphabeta you have a window. (alpha, beta) _is_ the window.

[Fguy64]

With alphabeta you have a window. (alpha, beta) _is_ the window.

Ok noted. however, and I don't mean to belabor the point, I just like to nail things down when i can. So I welcome the chance to discuss this stuff to the nth degree with someone who has been there.

So do we agree that with just straight up fixed depth negamax/alpha beta with no hashing or other bells and whistles and no considerations to move ordering, then does that validate my debugging strategy, from a mathematically correct perspective?

In other words I should be able to step through level one moves and reduce the ply by 1 each time and reach the same destination.

again the whole point is that right now, All I know is the level1 move that is being searched.

[hgm]

So do we agree that with just straight up fixed depth negamax/alpha beta with no hashing or other bells and whistles and no considerations to move ordering, then does that validate my debugging strategy, from a mathematically correct perspective?

No, we don't, as I already said in the first place. With NegaMax searching a node at level 1 is something _completely_ different from seaching that same position as root for any move but the first. The first move increases alpha, i.e. changes the window.