review of my code

[Rein Halbersma]

Well, that is I think the whole point.
I can't find what is causing that it is giving the incorrect perft counts.
Especially since move-generation seems to be fine - I used the move generator from "pos" (the non-brute-force engine I wrote earlier) and that one has been playing for years on fics without never any matches lost because of incorrect moves (104492 games currently).

Just use the divide() ehancement for perft(): take a known perft position that your program gets wrong, generate the perft for all its successors, take again one of the moves leading to a disagreement until you have found a single move that is illegal. Then fix the problem in your move generator. Then rinse and repeat until you have confirmed all known perft counts.

[JVMerlino]

Well, that is I think the whole point.
I can't find what is causing that it is giving the incorrect perft counts.
Especially since move-generation seems to be fine - I used the move generator from "pos" (the non-brute-force engine I wrote earlier) and that one has been playing for years on fics without never any matches lost because of incorrect moves (104492 games currently).

Just use the divide() ehancement for perft(): take a known perft position that your program gets wrong, generate the perft for all its successors, take again one of the moves leading to a disagreement until you have found a single move that is illegal. Then fix the problem in your move generator. Then rinse and repeat until you have confirmed all known perft counts.

This post contains several useful positions for verifying your move generator:

http://www.talkchess.com/forum/viewtopi ... 53&t=49034

jm

[bob]

Well, that is I think the whole point.
I can't find what is causing that it is giving the incorrect perft counts.
Especially since move-generation seems to be fine - I used the move generator from "pos" (the non-brute-force engine I wrote earlier) and that one has been playing for years on fics without never any matches lost because of incorrect moves (104492 games currently).

If perft is wrong it is doubtful that "move generation is fine." Fixing a perft problem is a simple, basic, debugging concept. Try a bunch of different positions to shallow depths so that once you find a wrong total, it doesn't take so much time to repeat while debugging.

[flok]

Well, that is I think the whole point.
I can't find what is causing that it is giving the incorrect perft counts.
Especially since move-generation seems to be fine - I used the move generator from "pos" (the non-brute-force engine I wrote earlier) and that one has been playing for years on fics without never any matches lost because of incorrect moves (104492 games currently).

Never playing illegal moves is not the same as knowing all of the legal moves that can be played.

Yes, but it refuses to play moves it does not think are valid.

[flok]

Well, that is I think the whole point.
I can't find what is causing that it is giving the incorrect perft counts.
Especially since move-generation seems to be fine - I used the move generator from "pos" (the non-brute-force engine I wrote earlier) and that one has been playing for years on fics without never any matches lost because of incorrect moves (104492 games currently).

If perft is wrong it is doubtful that "move generation is fine." Fixing a perft problem is a simple, basic, debugging concept. Try a bunch of different positions to shallow depths so that once you find a wrong total, it doesn't take so much time to repeat while debugging.

Unless the search-code is also considered to be part of the move generation code, I don't think the problem is there.
It looks like the search tree-code was incorrect.

[bob]

Well, that is I think the whole point.
I can't find what is causing that it is giving the incorrect perft counts.
Especially since move-generation seems to be fine - I used the move generator from "pos" (the non-brute-force engine I wrote earlier) and that one has been playing for years on fics without never any matches lost because of incorrect moves (104492 games currently).

If perft is wrong it is doubtful that "move generation is fine." Fixing a perft problem is a simple, basic, debugging concept. Try a bunch of different positions to shallow depths so that once you find a wrong total, it doesn't take so much time to repeat while debugging.

Unless the search-code is also considered to be part of the move generation code, I don't think the problem is there.
It looks like the search tree-code was incorrect.

For the pert search? That's only 16 lines of code in Crafty.

[Rein Halbersma]

Well, that is I think the whole point.
I can't find what is causing that it is giving the incorrect perft counts.
Especially since move-generation seems to be fine - I used the move generator from "pos" (the non-brute-force engine I wrote earlier) and that one has been playing for years on fics without never any matches lost because of incorrect moves (104492 games currently).

Never playing illegal moves is not the same as knowing all of the legal moves that can be played.

Yes, but it refuses to play moves it does not think are valid.

For any mismatch there are 2 possibilities: either you generate less or you generate more moves than a correct move generator would do. Just nail it down to one of these cases and fix it in your source.

[hgm]

If you will not develop a method to debug your code interactively yourself (rather than just staring at it), you will never get anywhere in Chess programming.

But it should not be very difficult to do that. Just equip the engine with code that at any time keeps the moves from the root to the current position in an array, and put a conditional print statement just behind the return of the recursive call to Search that prints ply, remaining search depth, IID iteration (if you do IID), move just searched, score it got, best score in the node so far. Only have that routine print in nodes that are along a specified path. (To make this easy, allow your binary to accept such a path on the command line.)

Then find a position where it reproducibly makes the same obvious blunder. If you have that, start printing in the root to see which move gets the wrong score (either the blunder will get too high a score, or the good alternatives too low a score). Then add that move to path, and run again, to see how that move obtained this wrong score in the daughter node. Work your way up in the tree until you reached the error. (Usually a move that should have refuted the preceding one, but is not searched at all, so that there is nothing to follow.) Then start printing other info in that same node to see what is going on there.

[flok]

To show that I appreciate your suggestions, I decided to bite the bullet and implement perft. It wasn't all that difficult and I have no idea why I didn't do it earlier (15 minutes of work).
I'm very pleased with the results: they match 100% with what is shown at http://chessprogramming.wikispaces.com/Perft+Results:

single threaded

Code: Select all

Nodes at 1: 20 (took: 0.01s)
Nodes at 2: 400 (took: 0.042s)
Nodes at 3: 8902 (took: 0.124s)
Nodes at 4: 197281 (took: 0.939s)
Nodes at 5: 4865609 (took: 20.827s)
Nodes at 6: 119060324 (took: 601.289s)

multi threaded

Code: Select all

Nodes at 1: 20 (took: 0.013s)
Nodes at 2: 400 (took: 0.058s)
Nodes at 3: 8902 (took: 0.279s)
Nodes at 4: 197281 (took: 1.009s)
Nodes at 5: 4865609 (took: 9.249s)
Nodes at 6: 119060324 (took: 264.414s)

[pocopito]

Those are god news.

I guess you should follow Jonh Merlino's hint above and test some hard positions:
http://www.talkchess.com/forum/viewtopi ... 53&t=49034

As you can see in that thread, even very serious engines many years working without an issue were able to find some nasty bugs on their moves generator.

Best

E Diaz