Help with Debugging My Chess Engine - 2

[universecoder]

I've made the changes you mentioned. Still working on perft though.

[Sven]

I've made the changes you mentioned. Still working on perft though.

After looking into your code again I think the castling rights code is still partially wrong. At the end of playMove() you change white castling rights only when making a move for white. But black might capture a rook!

Regarding perft, you could add code that prints the perft count for each root move so that you can compare that to corresponding "trusted" output of other engines.

[universecoder]

I am doing the thing with perft as you suggested, but can you provide me some guidance on correcting this castling thing?

[universecoder]

a3 380
a4 424
b3 420
b4 429
c3 420
c4 449
d3 539
d4 568
e3 613
e4 622
f3 380
f4 409
g3 420
g4 429
h3 380
h4 424
Na3 425
Nc3 474
Nf3 474
Nh3 425

These are my results. Some(most) are wrong. How do I efficiently analyse the moves along each line? My results are correct till perft(2).

[Sven]

a3 380
a4 424
b3 420
b4 429
c3 420
c4 449
d3 539
d4 568
e3 613
e4 622
f3 380
f4 409
g3 420
g4 429
h3 380
h4 424
Na3 425
Nc3 474
Nf3 474
Nh3 425

These are my results. Some(most) are wrong. How do I efficiently analyse the moves along each line? My results are correct till perft(2).

Follow the first move that delivers a wrong perft(2) count and do the same as before, comparing your perft(1) results for all root moves to trusted perft(1) results.

The version on GitHub crashes for me when compiling with CygWin. Stacktrace:

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x00000001004054f7 in chessboard::generateAllMoves (this=0xffffc680) at moveGen.cpp:43
43                                              if ( board[finalSquare] == EM ) {
(gdb) where
#0  0x00000001004054f7 in chessboard::generateAllMoves (this=0xffffc680) at moveGen.cpp:43
#1  0x0000000100404e68 in chessboard::perft (this=0xffffc680, depth=1) at chessboard.cpp:849
#2  0x0000000100404efe in chessboard::perft (this=0xffffc680, depth=2) at chessboard.cpp:858
#3  0x0000000100404efe in chessboard::perft (this=0xffffc680, depth=3) at chessboard.cpp:858
#4  0x000000010040773f in main () at main.cpp:10

If I call printBoard() in the debugger (after adding a flush(cout) at the end and recompiling) I see that the current position at crash time is after 1.a4 b5. Maybe it happens within the generation of the capture move a4xb5, I don't know. The piece list for black pawns does not contain the square b5.

Since you get a regular perft output you might have fixed that already, or you don't get this crash on your system. In any case I thought it would be worth reporting it.

[Sven]

I am doing the thing with perft as you suggested, but can you provide me some guidance on correcting this castling thing?

You could try it by removing only these if-else lines from end of playMove():

Code: Select all

	if ( side == white ) {
...
	}
	
	else {
...
	}

so that you check independent from side to move whether castling rights updates and corresponding hash key updates are necessary. After doing so there may be some redundancy in the code but that does not really matter, you can postpone any optimization issues until (much) later.

[elcabesa]

you did perft3 on your engine and on stockfish and saw that a4 move gives you a wrong perft ( stockfish 420, yours 424)
so your next step is to execute a2a4 move, and compare perft 2 of this position for your engine and Stockfish.

the position to be tested is rnbqkbnr/pppppppp/8/8/P7/8/1PPPPPPP/RNBQKBNR b KQkq a3 0 1 ( starting position + a2a4).

this will lead to found what is the position that give you problem at perft 1

[universecoder]

I get the following now:

a6 21
a5 20
b6 21
b5 26
c6 21
c5 21
d6 21
d5 21
e6 21
e5 21
f6 21
f5 21
g6 21
g5 21
h6 21
h5 21
nc6 21
na6 21
nh6 21
nf6 21

Where do I find the correct record of this though? (Since this is played initPos + a2a4)?

[universecoder]

I got it, I just used the perft function in stockfish!

[universecoder]

I followed the line along a2a4. The problematic move was b7b5, now I am at depth 1 and I saw all the '26' positions manually(it turns out that there should be just 22). I found that some moves were generated twice! ( eg. a4xb5 ) -> twice, the h pawn moving twice and so on. So I went to the generate moves functions and I printed the number of times it entered the pawn loop. It was 10. So I checked the number of squares in the pieceList of white pawns and it turned out to be 8 only. Why is this happening?

a4xb5 -> twice
a4a5 -> twice
h2h4 -> twice
h2h3 -> twice

As of now I think this is because of the changes done in playMove() and undoMove(). Theit effects are undone but set<int> is implemented as a binary search which is causing problems. This is because it stores the elements in order and therefore I change this ordering while updating my things.( I think this is the reason right now ).