Tracking castling rights

[lithander]

How do you restore castling rights? Are you making a copy of the board state? I'm doing incremental make-move, unmake-move, so if I switch from my current has-moved? approach, I'll need to be able to restore castling rights when unmaking a king or rook move.

I don't have an undo method. I just make a copy of the board state if I want to be able to go back to that.

How do you undo en-passent squares without remembering something from the previous state?

[mvanthoor]

Have you also taken into account somewhere that you can lose castling rights when one of the rooks is captured before it has even moved?

It can't be captured without a move targeting the rook's square. So for these cases UpdateCastlingRights(move.ToIndex) will revoke the castling rights!

I got the correct Perft 5 result on the position you linked: 193.690.690

Cool If you can pass the entire perftsuite.epd test, then that's the first step to a bug-free engine

[unserializable]

I finally implemented perft. I didn't discover any bugs in move generation (although I should've done perft before I painfully debugged my move generation manually by playing games!!), but I fixed a bunch of bugs in my fen parsing One of them was related to my "piece has moved" bit which the fen parser didn't set properly.

Congrats! And if at all in doubt, make sure there is 7 moves available for black in following:
[d] 8/8/8/8/3kpP1R/8/6K1/8 b - f3 0 1

to make sure the check-exposing e.p. capture is not included among legal moves (I found position to be problematic only with code review, my limited testing with positions had not revealed it before, but then again, I had not used widely available test sets).

[lithander]

If you can pass the entire perftsuite.epd test, then that's the first step to a bug-free engine

Where do I find this? I don't want to just google it and end up with the wrong one.

[lojic]

How do you restore castling rights? Are you making a copy of the board state? I'm doing incremental make-move, unmake-move, so if I switch from my current has-moved? approach, I'll need to be able to restore castling rights when unmaking a king or rook move.

I don't have an undo method. I just make a copy of the board state if I want to be able to go back to that.

How do you undo en-passent squares without remembering something from the previous state?

For EP squares, I have an array that is indexed by ply. The logic was a bit tricky (possibly due to other aspects of my implementation), but now that I have a nice perft test suite, I'd feel comfortable trying the same thing with castling rights and comparing the speed.

[mvanthoor]

If you can pass the entire perftsuite.epd test, then that's the first step to a bug-free engine

Where do I find this? I don't want to just google it and end up with the wrong one.

It is here (and many other engines also include it):

https://github.com/mvanthoor/rustic/blo ... ra/epds.rs

If you just lift the strings from this file and save them in "perftsuite.epd" (plain text, without the double quotes around the strings and the comma's at the end) then you have it. I put them into an array of strings, so I can have a feature called --epdtest (or -e), which can be compiled into the engine if it is activated on compilation. When I change things that can affect the move generator, I always compile Rustic in debug mode with this feature enabled, and then the engine can test itself when I run "./rustic -e".

Obviously you can also read the strings from a file instead of compiling them into the engine, if you like that better.

[lithander]

Obviously you can also read the strings from a file instead of compiling them into the engine, if you like that better.

I'm relieved to report that all tests on depth 5 and 6 passed!

...but the test took 10 minutes...

[mvanthoor]

Obviously you can also read the strings from a file instead of compiling them into the engine, if you like that better.

I'm relieved to report that all tests on depth 5 and 6 passed!

...but the test took 10 minutes...

But now you know for sure that your move generator and make/unmake are bug free.

Now you only need to implement a feature to check your incremental Zobrist hash against a hash created from scratch, and a similar feature to check incrementally updated PST and material values against those created from scratch, for every position.

Then this test will take something like 20 minutes

Fortunately, you don't have to run it as long as you don't change anything in these functions:
- move generator
- make / unmake move
- zobrist hashing
- incremental PST update
- incremental material value update
- And the init functions that create those values from scratch at the beginning.

Most of this stuff never changes if it works, except if you're going to implement a faster way of doing things.

It'll also come in handy to test a transposition table. If the perft numbers don't match when the TT is active, there's something wrong in there, or you have a mistake in updating the Zobrist hash. (But that should have already been covered by the update/from scratch test).