ep and castle rights hashing

[xmas79]

Hi all,
recent post about ep square on polyglot,pointed me to having that ep "bug" in my engine,as I blindly set ep square on every double push.fixing this was very easy,but now I think I should do the same thing on castle rights. when in check, a king cannot castle,so search should not distinguish between two positions where one king is in check regardless of the castle rights for that king. probabily is not worth the effort? Should I do this?

best regards,
Natale.

[Steve Maughan]

No.

When the king is in check it still has the *right* to castle at a future time. So removing the castling component of the hash would be wrong.

Steve

[tpetzke]

Hi,

you should think further

If you have a bonus for the king still possessing its castling rights you should handle positions where the king still has the rights different to where he has lost them (permanently).

If you have a bonus for the king being able to castle with the very next move you should handle positions with the king in check equally to where he has lost the castling rights, and also of course positions where there are still pieces between king and rook.

Most engines award a bonus for the first case, I know of no engine that has a bonus for the 2nd case.

[syzygy]

If you have a bonus for the king being able to castle with the very next move you should handle positions with the king in check equally to where he has lost the castling rights, and also of course positions where there are still pieces between king and rook.

This would be wrong. You should not only look at the static evaluation.

If you have two identical positions with the king in check with the sole difference that in one position the king has lost castling rights and in the other position the king still has castling rights, then the search is likely to return different results for both positions. This is because one position leads to a search tree without castling moves and the other position leads to a search tree with castling moves.

If the search may return different scores for two positions, then it makes no sense to assign them the same hash key.

Another reason for not assigning these two positions the same hash key is that the hash key is probably used to detect repetitions. According to FIDE rules, the two positions are not identical. So they should not be detected as identical...

[Edmund]

The two positions P1 (with castling possible) and P2 (with castling not possible) but all other aspects equal are obviously different positions and need different hash-keys.

However this is the only case where, with a static evaluation you can say with 100% certainty that P1 is better or equal than P2.

This means for example, if your position allows for a transition into P1 and your opening book indicates that P2 is a very favorable position for you, you might as well consider an instant book-move.
Also you might use this information for more transpositiontable cutoffs.

[Sven]

Hi all,
recent post about ep square on polyglot,pointed me to having that ep "bug" in my engine,as I blindly set ep square on every double push.fixing this was very easy,but now I think I should do the same thing on castle rights. when in check, a king cannot castle,so search should not distinguish between two positions where one king is in check regardless of the castle rights for that king. probabily is not worth the effort? Should I do this?

best regards,
Natale.

The "is in check" property is not the key point here. The real point is that you can have two positions with identical piece locations where in one case a castling right is available (so king and rook have not moved yet) and in the other case that castling right is not available (so either the king or the rook has already moved but then returned to its original square). Whether the king is in check in both cases, or is not in check in both cases, does not matter at all.

As to the hashing aspects of this situation, everything has already been said, i.e. different castling rights require different hash keys and also require to recognize the two positions as different w.r.t. repetition detection, where the latter is based on the FIDE rules. So even if, in the "in check" case, the available legal moves are the same in that position they are not necessarily the same in positions later in the game. En passant is different here since it is a short-term property of the position that is valid for one ply only, while each of the four castling rights remains valid until a move is played that destroys it.

Sven

[tpetzke]

You're right.

I was only looking whether it has an impact on the evaluation depending on the terms you have (e.g. whether you can store all positions in the eval cache in the same slot no matter what the castling rights are)

The hashkey you use in the main transposition table should make a difference in any case.

[syzygy]

The two positions P1 (with castling possible) and P2 (with castling not possible) but all other aspects equal are obviously different positions and need different hash-keys.

However this is the only case where, with a static evaluation you can say with 100% certainty that P1 is better or equal than P2.

Static evaluation has very very little to do with this.

Only if you statically detect that only king moves can get the king out of check, so that effectively the right to castle was already lost, does it make sense to treat the two positions the same.

[hgm]

I think Edmund's statement is more general: any position that has castling rights (check or not) is upward compatible with corresponding position where you have none. So a lower bound on the score of a position without castling rights (for the stm) would also be a lower bound on the position with them, and you probably could even sharpen the bound if your eval assigns some minimum value to castling rights. The inverse would be true for upper bounds. So you can often use a hash hit upon one of the two positions to cause a cuttoff even when you were looking for the other. This would be an argument to not distinguish them by hash key. (But then you should have a flag in the hash table that tells you the castling rights for which the recorded score was calculated, so that you know how to make the correction.

A similar case occurs in variants with drops, when you have extra pieces in the hand.

The case of not setting e.p. rights in the hash key when there is no Pawn to capture is more similar to not considering a King that has not moved to have castling rights when the Rook is already gone.

[Sven]

Only if you statically detect that only king moves can get the king out of check, so that effectively the right to castle was already lost, does it make sense to treat the two positions the same.

But not for repetition detection, since FIDE rules still define the two positions as different. The last sentence of article 9.2 says:

When a king or a rook is forced to move, it will lose its castling rights, if any, only after it is moved.

Sven