A few positions to test movegen

[Ajedrecista]

Hello John:

Here are a few more positions I used to test my movegen and perft when converting Myrddin to bitboards (thanks to Ron Murawski for several of them):

r3k2r/8/8/8/3pPp2/8/8/R3K1RR b KQkq e3 0 1
perft 6 = 485,647,607

r3k2r/Pppp1ppp/1b3nbN/nP6/BBP1P3/q4N2/Pp1P2PP/R2Q1RK1 w kq - 0 1
perft 6 = 706,045,033

8/7p/p5pb/4k3/P1pPn3/8/P5PP/1rB2RK1 b - d3 0 28
perft 6 = 38,633,283

8/3K4/2p5/p2b2r1/5k2/8/8/1q6 b - - 1 67
perft 7 = 493,407,574

rnbqkb1r/ppppp1pp/7n/4Pp2/8/8/PPPP1PPP/RNBQKBNR w KQkq f6 0 3
perft 6 = 244,063,299

r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq -
perft 5 = 193,690,690

8/p7/8/1P6/K1k3p1/6P1/7P/8 w - -
perft 8 = 8,103,790

n1n5/PPPk4/8/8/8/8/4Kppp/5N1N b - -
perft 6 = 71,179,139

r3k2r/p6p/8/B7/1pp1p3/3b4/P6P/R3K2R w KQkq -
perft 6 = 77,054,993

8/2p5/3p4/KP5r/1R3p1k/8/4P1P1/8 w - -
perft 7 = 178,633,661

8/5p2/8/2k3P1/p3K3/8/1P6/8 b - -
perft 8 = 64,451,405

r3k2r/pb3p2/5npp/n2p4/1p1PPB2/6P1/P2N1PBP/R3K2R w KQkq -
perft 5 = 29,179,893

jm

JetChess 1.0.0.0 agrees in all the twelve positions you posted. Good work!

Regards from Spain.

Ajedrecista.

[lucasart]

Here is a list of a few artifical positions to test some of the common pitfalls of move generators.
Each position appears twice with colors reversed.
I think it may be useful to others too.
Of course passing the test doesn't mean the movegen is bug-free.

avoid illegal en passant capture:
8/5bk1/8/2Pp4/8/1K6/8/8 w - d6 0 1 perft 6 = 824064
8/8/1k6/8/2pP4/8/5BK1/8 b - d3 0 1 perft 6 = 824064
en passant capture checks opponent:
8/8/1k6/2b5/2pP4/8/5K2/8 b - d3 0 1 perft 6 = 1440467
8/5k2/8/2Pp4/2B5/1K6/8/8 w - d6 0 1 perft 6 = 1440467
short castling gives check:
5k2/8/8/8/8/8/8/4K2R w K - 0 1 perft 6 = 661072
4k2r/8/8/8/8/8/8/5K2 b k - 0 1 perft 6 = 661072
long castling gives check:
3k4/8/8/8/8/8/8/R3K3 w Q - 0 1 perft 6 = 803711
r3k3/8/8/8/8/8/8/3K4 b q - 0 1 perft 6 = 803711
castling (including losing cr due to rook capture):
r3k2r/1b4bq/8/8/8/8/7B/R3K2R w KQkq - 0 1 perft 4 = 1274206
r3k2r/7b/8/8/8/8/1B4BQ/R3K2R b KQkq - 0 1 perft 4 = 1274206
castling prevented:
r3k2r/8/3Q4/8/8/5q2/8/R3K2R b KQkq - 0 1 perft 4 = 1720476
r3k2r/8/5Q2/8/8/3q4/8/R3K2R w KQkq - 0 1 perft 4 = 1720476
promote out of check:
2K2r2/4P3/8/8/8/8/8/3k4 w - - 0 1 perft 6 = 3821001
3K4/8/8/8/8/8/4p3/2k2R2 b - - 0 1 perft 6 = 3821001
discovered check:
8/8/1P2K3/8/2n5/1q6/8/5k2 b - - 0 1 perft 5 = 1004658
5K2/8/1Q6/2N5/8/1p2k3/8/8 w - - 0 1 perft 5 = 1004658
promote to give check:
4k3/1P6/8/8/8/8/K7/8 w - - 0 1 perft 6 = 217342
8/k7/8/8/8/8/1p6/4K3 b - - 0 1 perft 6 = 217342
underpromote to check:
8/P1k5/K7/8/8/8/8/8 w - - 0 1 perft 6 = 92683
8/8/8/8/8/k7/p1K5/8 b - - 0 1 perft 6 = 92683
self stalemate:
K1k5/8/P7/8/8/8/8/8 w - - 0 1 perft 6 = 2217
8/8/8/8/8/p7/8/k1K5 b - - 0 1 perft 6 = 2217
stalemate/checkmate:
8/k1P5/8/1K6/8/8/8/8 w - - 0 1 perft 7 = 567584
8/8/8/8/1k6/8/K1p5/8 b - - 0 1 perft 7 = 567584
double check:
8/8/2k5/5q2/5n2/8/5K2/8 b - - 0 1 perft 4 = 23527
8/5k2/8/5N2/5Q2/2K5/8/8 w - - 0 1 perft 4 = 23527

Nice unit test. DiscoCheck agrees with all your numbers. I replaced the test suite I was using before by this one. I was previously using the 4 positions from the chess programming wiki perft result page. I was using a few positions at high depth logic, but more positions at shallower depth is better. So I prefer your test suite for that reason. It's also a lot faster to run.
https://github.com/lucasart/chess/commi ... 2d472db3c3

[mar]

Nice unit test. DiscoCheck agrees with all your numbers. I replaced the test suite I was using before by this one. I was previously using the 4 positions from the chess programming wiki perft result page. I was using a few positions at high depth logic, but more positions at shallower depth is better. So I prefer your test suite for that reason. It's also a lot faster to run.
https://github.com/lucasart/chess/commi ... 2d472db3c3

Thanks, however Evert found that some of the positions contain illegal fens (i.e. they can't occur in a game), so perhaps you should use the corrected version along with other testpositions found elsewhere in this thread.

[lucasart]

Nice unit test. DiscoCheck agrees with all your numbers. I replaced the test suite I was using before by this one. I was previously using the 4 positions from the chess programming wiki perft result page. I was using a few positions at high depth logic, but more positions at shallower depth is better. So I prefer your test suite for that reason. It's also a lot faster to run.
https://github.com/lucasart/chess/commi ... 2d472db3c3

Thanks, however Evert found that some of the positions contain illegal fens (i.e. they can't occur in a game), so perhaps you should use the corrected version along with other testpositions found elsewhere in this thread.

I saw that. But I will still keep your positions. DiscoCheck doesn't care if a position can be reached in a real game or not, and it should not assume that the ep square would be empty is ep capture is illegal (I don't see how to use that info in any useful way to speed up the program).

[mar]

I saw that. But I will still keep your positions. DiscoCheck doesn't care if a position can be reached in a real game or not, and it should not assume that the ep square would be empty is ep capture is illegal (I don't see how to use that info in any useful way to speed up the program).

Ok The problem is that positions with ep flag set when no capture is possible will hash to different keys, this is probably ok in search but could be problem with opening books (that's why polyglot clears invalid ep flags). In fact, if you clear invalid ep flag in your do-move you get a tiny speed penalty. Checking for adjacent opponent pawns should do because illegal captures (into check) will be rejected by pseudo-is-legal test.

[Evert]

I saw that. But I will still keep your positions. DiscoCheck doesn't care if a position can be reached in a real game or not, and it should not assume that the ep square would be empty is ep capture is illegal (I don't see how to use that info in any useful way to speed up the program).

The en-passant capture being illegal is actually not the problem in itself.

[d]8/5bk1/8/2Pp4/8/1K6/8/8 w - d6 0 1
Given that there's an en-passant capture, Black's last move must have been d7-d5, but then the white king was in check during black's turn - which is illegal.

Jazz (and Leonidas) verify if a move leaves the king in check (unless the move is an evasion, in which case they already know that it's a legal move). One of the short-cuts taken is that an en-passant capture cannot leave the king in check, unless the king is on the same rank (the well-known "pinned en-passant capture" pitfall). Making this test more general (so it would be "correct" in the above position) slows things down measurably (but still not very much). Sjaak is far too general an engine to have a legal evasion generator and so gets this position "right" anyway.

As I recall, you always do legal move generation, so it may be less of an issue there, but I would still imagine you can get a minor speedup by not doing the test for something that never happens in a real game...

[lucasart]

As I recall, you always do legal move generation, so it may be less of an issue there, but I would still imagine you can get a minor speedup by not doing the test for something that never happens in a real game...

Indeed, DiscoCheck generates legal moves directly, never going through pseudo-legal moves filtering. Despite the widespread notion that pseudo-legal is faster, I think my raw perft code is very hard to beat

So you propose to:
- assume the fen shows an ep square only when the ep capture would be legal (ok, if the FEN standard does indeed say that)
- when I play a move, and the move is a double pawn push, only set the ep square if the ep would be legal. That's where I disagree with you, because this computation is time consuming, and is done everytime a double pawn push is played.

I'll give it a try, but I really doubt I can make the raw perft faster like this.

[Evert]

So you propose to:
- assume the fen shows an ep square only when the ep capture would be legal (ok, if the FEN standard does indeed say that)
- when I play a move, and the move is a double pawn push, only set the ep square if the ep would be legal. That's where I disagree with you, because this computation is time consuming, and is done everytime a double pawn push is played.

Neither. I propose simplifying the test for whether an en-passant capture would leave the king in check, for instance by only doing it if the king is on the same rank as the pawn that is going to be captured - the only possible situation where the king could be left in check (if it wasn't in check before) after an en-passant capture. That's a test that needs to be done in one way or another anyway.

I don't bother testing whether en-passant is legal or not before setting the en-passant square. I don't think it happens often enough to really matter.

By the way - as far as I know, legal move generation is faster for perft (because you can do bulk counting at leaf-nodes), but not in regular play. Never tried it though (legal evasions were a clear improvement, but they're easier).

[spirch]

work like a charm in mine, thanks!

[Richard Allbert]

Thanks a lot for these positions - I've been using the file provided on the Roce engine page, but these add a bit of spice. Deserves a bump.