strange perft results

[mvk]

Many bugs don't show up in root.

[Robert Pope]

Many bugs don't show up in root.

Exactly. For example, if your engine's makemove doesn't set the ep flag correctly after a pawn move, that can never be caught by a setboard/movegen test.

[syzygy]

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.

How you spend your time is, of course, entirely your own business.

My point is that the type of problem you had, and apparently still have, is very easy to solve if you just implemented a divide command. Certainly _much_ easier for you with a divide command than it is for any of us to guess at what could possibly be wrong in code that we cannot (and do not want to) see.

I'm afraid your python script isn't going to get you very far. 35000 random positions to test your move generator on is a tiny tiny drop. A single perft 5 at the root position tests more than 5 times as many positions (and also tests other aspects of your code, as has already been pointed out by others).

It seems my feeling of déjà vu is real:
http://talkchess.com/forum/viewtopic.php?t=49465

"Fixing a perft problem is a simple, basic, debugging concept."

[flok]

fyi: did not have much time today but enough to adjust stockfish and do some tests with divide
looks promising

for '8/8/1k6/2b5/2pP4/8/5K2/8 b - d3 0 1' depth 5
it fails for:

my program: C4-D3 [en-passant] 40199
stockfish c4d3: 40093

my program: C4-C3 [regular] 95853
stockfish: c4c3: 95420

Going 1 step deeper shows that all moves give different results, for both the c4-d3 and the c4c3 case.

Will look into that tomorrow. Which is 4 hours away

[syzygy]

Going 1 step deeper shows that all moves give different results, for both the c4-d3 and the c4c3 case.

Perfect, so (tomorrow) you choose 1 of these moves and go another step deeper.

I find it really wonderful that a move generator can be debugged with so much ease and precision. A bug might affect just 1 position in a billion, but as long as you run perft on a large enough variety of positions you will detect it, and once detected you are (using the divide command) guaranteed to find the very position on which it generates a move too many or too few.

[lucasart]

POS 1.2 is rated 290 elo on CCRL 40/4.

This is even lower than Ram 2.0 by HG Muller, which is a random mover!!

Somehow, when I read this thread, I am not surprised...

[flok]

POS 1.2 is rated 290 elo on CCRL 40/4.
This is even lower than Ram 2.0 by HG Muller, which is a random mover!!
Somehow, when I read this thread, I am not surprised...

This is not about pos.
Pos is not, in no way at all, comparable to any brute force chess engine. It is not doing any alpha/beta negamax or whatever search.

Furthermore I might have mis-read your reaction but to me it "sounds" a bit insulting. I wonder why you would do that as for most of us this chess programming is a hobby. It is not as if I get people to pay money for my chess engine and then rip them off with something low quality.

[Sven]

POS 1.2 is rated 290 elo on CCRL 40/4.

This is even lower than Ram 2.0 by HG Muller, which is a random mover!!

Somehow, when I read this thread, I am not surprised...

The engine Folkert is currently working on is not "POS" but "DeepBrutePos". I don't know exactly its current strength but I would estimate the strength of a slightly older version of which I know the source code to be clearly above 1800 at least, maybe above 2000. Not comparable at all to "POS".

[flok]

Found the problem: it was in the promotion code.

Pawns did promote, their type changed. But, so to say, the pointer to the code that is specific for the piece-type did not change.
So no e.g. queen-specific moves were generated and, depending on the case, check-evasions were not done.

The perfts I checked run fine now.