divide N verbose

[stegemma]

[...]you do perft 8 (eight) and see e2e4 have wrong node count. Then you play e2e4 on the board and do a perft 4 (four)?[...]

Of course it was a typing mistake, i means 8 then 7 (not 4).

I'm a bug wizard... i can put a bug in the hash even if I don't use a hash at all or a bug in castling that appears even when there are no castling

To explain the problem, i have a single array for all the moves, allocated and cleaned up at the start of perft. Any move will be saved overwriting previous content, this could be one reason for the bug. There are also a complex make/unmake and some parameter moved up and down in the nodes array plus pointers to the moves in each piece object, adjourned only when needed (i use incremental generation, as said). So the order of make/unmake and the move order itself can hide or show some bug but only when you play the exact sequence of moves. More than this... i use a "IsInCheckAfterMove" function that say if teh king has been leaved in check, doing only a fraction of the examined move.

Debugging all of this is funny but not very easy.

[stegemma]

I always play out a divergent move and then compare the perft(N-1) numbers.

Note that this is not the same as setting up a position from a FEN: perft calls make/unmake, so if the bug is there it will not show up when setting up a FEN position.

I'd recommend basing the movegen validation on the set of test positions posted here: http://www.talkchess.com/forum/viewtopic.php?t=47318, it captures most problems you run into (this reminds me, I have one it didn't cover).

Sorry I don't understand. If I do perft 5 and see node count mismatch for a move then something is wrong for that branch. Then I load the FEN, and do a perft 4, and node count is perfect. I already have found the critical node (the root), found the move that goes wrong (see later), and can say the bug is in make/unmake because:
1) the last move preceding the one with wrong counter produced some nasty effect on the status of the current node (bug in unmake)
2) the move with wrong counters is the wrong one (bug in make)

No?

Yes but if the bug appears at ply 8 and disappear at ply 7 (after make the first move that you know to have the wrong count) you then have to test each of the million moves of the 7 remaining plies. You know that the bug is there but you don't know "where".

I can find it but i just searched for a faster way to know exactly where it happens. Muller's perft could help, in the after-work i would try it.

Surely it would be some stupid bug...