lucasart wrote:
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...
jdart wrote:Arasan ran these with 0 errors, as I expected. I'm sure it has plenty of bugs, just not in the move generator.
Thanks for providing these tests. I have added them to my unit test module.
--Jon
It's a nervous wait, though isn't it?
I've had a lot of long haul flights with work recently, and have been rewriting Lime on the plane - and began collecting as many positions as possible. Some good positions here.
Re testing : my opening book generator runs through about 750,000 games, parsing and executing each move, and checking legality. So that is maybe 40-50 million positions.
Plus I sometimes run the engine with debug enabled and many asserts turned on. So that is another fairly stringent test. If ever an illegal move is executed it will probably fail one of the asserts.
That is why I didn't expect problems in the movegen area.
I recently found a case that wasn't covered by any of the test positions listed here: resolving check by en-passant capture of the checking pawn. This is the relevant position (comments say it comes from John Merlino's test set):
[d]8/7p/p5pb/4k3/P1pPn3/8/P5PP/1rB2RK1 b - d3 0 28
Evert wrote:I recently found a case that wasn't covered by any of the test positions listed here: resolving check by en-passant capture of the checking pawn. This is the relevant position (comments say it comes from John Merlino's test set):
[d]8/7p/p5pb/4k3/P1pPn3/8/P5PP/1rB2RK1 b - d3 0 28
perft 4: 67197
perft 6: 38633283
It's already in this thread, along with other positions used by John:
Evert wrote:I recently found a case that wasn't covered by any of the test positions listed here: resolving check by en-passant capture of the checking pawn. This is the relevant position (comments say it comes from John Merlino's test set):
Evert wrote:I recently found a case that wasn't covered by any of the test positions listed here: resolving check by en-passant capture of the checking pawn. This is the relevant position (comments say it comes from John Merlino's test set):
Evert wrote:I recently found a case that wasn't covered by any of the test positions listed here: resolving check by en-passant capture of the checking pawn. This is the relevant position (comments say it comes from John Merlino's test set):
[d]8/7p/p5pb/4k3/P1pPn3/8/P5PP/1rB2RK1 b - d3 0 28
perft 4: 67197
perft 6: 38633283
It's already in this thread, along with other positions used by John:
