The Zobrist hash function used in Polyglot does not keep track of which rook has castling rights if there are multiple rooks present on the same side of the king.

• However it is rather unlikely that this situation would occur in the opening.
• So the ambiguity can be resolved in a satisfactory way by making the following convention.

Positions in which a rook has castling rights which is not an outer rook (closest to a or h file) should not be included in the book.

• Nonetheless this is an unsatisfactory situation.
• Therefore the upcoming versions of xboard/winboard extend the Polyglot hash function in such a way that it takes into account the full castling rights in Chess960, therefore removing the need of the above disambiguating convention.
• This is done in a backward compatible way. i.e. ordinary chess positions or Chess960 positions in which there is no castling ambiguity will keep their old hash key.

The declaration of RANDOM_CASTLE is replaced by:

const uint64 RandomCastle[16]={
< to be filled in >
}

In this case “castle” will be the exclusive or of entries taken from RANDOM_CASTLE, one for each rook that has castling rights (so at most four offsets).

The offset for a rook that has castling rights is computed as:

• If the rook is an outer rook (i.e. closest to the a or h file) then the offset is

This is like in ordinary chess.

• If the rook is not an outer rook then the offset is:

• where “file” denotes the file the Rook is on, encoded in the usual way, i.e. b=1,c=2,d=3,e=4,f=5,g=6.

A castling move is encoded as a usual move (see above) in which the “from square” is the position of the king and the “to square” is the position of the rook.

• This is to maintain compatibility with various Fruit derivatives.