Overlapped Zobrist keys array

[bob]

Note that a player can only hold (in hand) a maximum of 4 knights in crazyhouse, since promoted pieces turn back into pawns when captured.
In bughouse, for a minute I was thinking it would be a maximum of 8 knights, but it's still 4 because of piece colors. Of course you could hold up to 16 pawns.

I don't play crazy house, so I don't know the details, but how do you tell whether a given piece will turn back into a pawn when captured? Do you just have to remember? Seems like an ugly rule to me.

The problem is you don't have enough pieces for promotion. When you promote a pawn to a piece, but you don't have that "piece" both players have to remember. And when it is captured, it obviously reverts to a pawn. If you promote to a knight and you have one, you promote normally, otherwise get ready for some confusion.

[hgm]

With most GUIs I think you just have to remember. However, I think H.G. has added support into newer versions of WinBoard for showing promoted pieces a little bit differently.

Indeed, but that only works n local play. ICS nforunately do epresent a Pawn promoted to Knight as a plain Knight. And in ICS play, the information flow in WinBoard goes through the ICS: a new position is not derived from a previous position, but the move is sent to the ICS, and the new position is received back. This is a pain in games like Crazyhouse and Chess960, where the ICS messes up the promoted pieces and castling rights respectively. So one of these days I should alter WinBoard to _combine_ information from the previous position with that what the ICS sends it, in stead of using only the latter.

In over-the-board play it of course works just the other way around: a Pawn that promotes remains represented by a Pawn (because spare pieces are not usually not available), and you have to remember that it is a Knight.

[hgm]

No. I explicitly said I would use a _list_ of zobrist random numbers for each piece type.

Exactly, this is what I said. You would have to assign keys to (copyNumber, pieceType, square) combinations. In this case only for square == HOLDINGS, but it still unecessary bloats the key table.

Since I can have 10 knights in total from my pieces, plus my partner can hand me two from his game, I need an array of numbers knights(12). Now I don't use the same zobrist key for each knight. And when I choose to drop a piece on the board, I would xor the last number in the active list, and then xor in the square I dropped to and away we'd go.

So to update the key you do:

Z = Zobrist[pieceType];
hashKey ^= Z[dropSquare] ^ Z[holdingsCount] ^ Z[holdingsCount+1];

That is more work than

Z = Zobrist[pieceType];
hashKey += Z[dropSquare] - Z[holdingsSquare];

what you would have to do wth an additive key. Not only do you save a table lookup plus an ALU operation, but with clever representation of drop moves you could save on branches (and mispredictions) as well, as the latter cod has the same form as that of an ordinary move.

[bob]

No. I explicitly said I would use a _list_ of zobrist random numbers for each piece type.

Exactly, this is what I said. You would have to assign keys to (copyNumber, pieceType, square) combinations. In this case only for square == HOLDINGS, but it still unecessary bloats the key table.

Since I can have 10 knights in total from my pieces, plus my partner can hand me two from his game, I need an array of numbers knights(12). Now I don't use the same zobrist key for each knight. And when I choose to drop a piece on the board, I would xor the last number in the active list, and then xor in the square I dropped to and away we'd go.

So to update the key you do:

Z = Zobrist[pieceType];
hashKey ^= Z[dropSquare] ^ Z[holdingsCount] ^ Z[holdingsCount+1];

That is more work than

Z = Zobrist[pieceType];
hashKey += Z[dropSquare] - Z[holdingsSquare];

what you would have to do wth an additive key. Not only do you save a table lookup plus an ALU operation, but with clever representation of drop moves you could save on branches (and mispredictions) as well, as the latter cod has the same form as that of an ordinary move.

I just wasn't following the "multiple pieces on the same square" comment. If this is what was meant, that clears things up (multiple pieces on a "phantom square" (namely "in your hand").