strange perft results

[pocopito]

As commented on other posts, at ply 3 the first checks occur, so probably you are not handling properly how to run out of them, and therefore creating extra moves for ply 4.
Besides divide, you can try testing a couple of positions where the side to move is in check.

[mcostalba]

To add a divide command to Stockfish

This is a good idea, it could help debugging other engines so that their authors can use SF as a known good reference.

I have just added 'divide' command natively to current dev master.

[Brunetti]

There're useful epd files suited for move generator testing. I stored a good one here: http://e4e6.com/perft.epd.

Alex

[flok]

Did some work on it and found the following bugs:

- I had an enum for each piece type (PAWN, ROOK, etc) but 2 of them had the same value

- en passant bugs

- when moving a pawn, it would not detect that it caught an opponent piece if it was not doing a promotion

- not in all case were the moves for both sides calculating so that it was not known if a piece (eg king) was under attack or not


There's still, I think, at least one left because

# en passant capture checks opponent:
8/8/1k6/2b5/2pP4/8/5K2/8 b - d3 0 1 ;D6 1440467

gives:

FAIL: test_Perft::ep_cap_gives_check: unexpected node count 1441006 at depth 5 (expected: 1440467)

(ep_cap_gives_check is the name I gave to this testcase)

[flok]

Forgot to mention: I created a little python script which more or less generates random chess positions. For each it invokes the engine I want to test and some other engine. As a command line parameter they get the epd/fen string and they're expect to return the number of valid moves in that position (current ply so to say). When the numbers don't match, then there's a problem with the move generation and I have a epd/fen string which directly triggers this. So far (35k tests) no problems have been found but that might change in a night.

If you like to give it a try or would like to change it, it is on github: https://github.com/flok99/shuffle_board

It has at least one problem: it can create positions where a king (or even both) is in check.

[mvk]

See if you can pass this test. It is created from random games. It is verified by several independent programs, and I have never had a bug which wasn't caught within the first 10% of the set.

[flok]

See if you can pass this test. It is created from random games. It is verified by several independent programs, and I have never had a bug which wasn't caught within the first 10% of the set.

Yes, thank you, but I created the script to find an epd/fen string that shows the problem (if any) in one ply.

[xmas79]

...When the numbers don't match, then there's a problem with the move generation... ... ... So far (35k tests) no problems have been found but that might change in a night.

So you cannot spot bugs in the make/unmake part of te engine, as you are only testing the move generation part. Perft, instead, tests generate/make/unmake, and testing this as a whole is better IMHO (and is is a very different thing). Incremental boards updates, ep square targets, remove piece/add piece back, stuff that you really need to get right.

My two cents,
Natl.

[syzygy]

See if you can pass this test. It is created from random games. It is verified by several independent programs, and I have never had a bug which wasn't caught within the first 10% of the set.

Yes, thank you, but I created the script to find an epd/fen string that shows the problem (if any) in one ply.

The single most important advice you got was to implement a divide command. That command together with a little bit of patience and diligence would find and solve all your problems.

It's entirely your choice whether to follow that advice or not, but imo it would not be polite if at some point in the future, when you still have not implemented a divide command, you ask again for help in debugging your move generator.

[flok]

The single most important advice you got was to implement a divide command. That command together with a little bit of patience and diligence would find and solve all your problems.

It's entirely your choice whether to follow that advice or not, but imo it would not be polite if at some point in the future, when you still have not implemented a divide command, you ask again for help in debugging your move generator.

There is still some time left before the future has passed.

Also I think it should be commended that I first invested time (3 days) in creating unit tests for most of my code. The python script which is now happily running by itself, took an hour. So it is not like I've been wasting my time. In my profession unit tests are seen as the only way to go in fact.

Please note that I very much appreciate suggestions done.