AndrewGrant wrote:So I recently got around to factoring in the castling rights + enpass square into my zorbist hash calculations.
Self testing showed a rather large drop in elo.
I then went an decided to only factor in the enpass square if an enemy pawn could actually form the enpass. This made my node counts more simliar to my base line. However, self testing showed a reasonable elo drop once again. But a greater drop than what is expected for the overhead added.
My question here is, has anyone else found that ignoring castle rights and / or enpass is an improvement? It seems like a horrid idea to drop these two factors, but self-testing suggests otherwise.
No, it suggests that you need to find the bug
You definitely need to use castling rights and ep target square in your hash key. Not using them can't be an improvement of your engine. However, both involve a lot of pitfalls when implementing it. Here are some suggestions how to proceed:
1) Basic assumption is that "perft" returns correct numbers for some important test positions. Otherwise make/unmake and move generator would be typical sources for hash key problems as well.
2) Double check that "make move" updates the hash key correctly in all cases and "unmake move" restores it to its original value. The latter is usually guaranteed by saving the hash key on a stack, the former can be checked in a debug version by adding a function that calculates the whole hash key from scratch, and then comparing the incremental and the "from scratch" hash key, it must be the same after each make or unmake operation.
Typical update rules for castling rights and en passant are (I hope I did not miss anything):
- Moving the king (including castling) clears both castling rights of the moving side.
- Moving a rook (including castling) clears one of the castling rights of the moving side.
- Capturing a rook in a corner clears one of the castling rights of the opponent.
- No other legal move affects any castling right.
- Even the null move does not affect any castling right.
- The ep target square always changes when making a move (including the null move!) from a position where the ep target square is set to a valid square.
- The ep target square always changes when making a pawn double step to a square left or right to an enemy pawn (unless you have implemented the detection of exceptional cases where en passant is not allowed after such a move due to a pinned piece).
- No other situation affects the ep target square.
3) If "perft" and hash key updating do not show any errors then you can still have errors, either by always treating two different positions as identical or by always treating two identical positions as different. Both can cause trouble regarding repetition detection (if that is based on hash keys, as in most engines) and in search, where the more severe case for both would be to always treat two different positions as identical.
4) Another possible source of trouble is how castling rights and ep target square are mapped to zobrist keys. For both there are different solutions around. In any case, even if a solution is not the most efficient one, it must lead to correct code in the sense that different values of the position properties (CR, EP) are mapped to different zobrist keys and identical values aren't. You can write simple test code for this, independent from any concrete board position.