crazyhouse promotions

[zenpawn]

Is there a standard way for engines to keep track of which pieces are the result of promotions, so as to pocket them as pawns when captured?

A couple options I'm considering:

1) bitboard which would be updated on moves or captures of a promoted piece

2) promoted versions of the Q, R, N, and B piece types

[Ferdy]

Is there a standard way for engines to keep track of which pieces are the result of promotions, so as to pocket them as pawns when captured?

A couple options I'm considering:

1) bitboard which would be updated on moves or captures of a promoted piece

2) promoted versions of the Q, R, N, and B piece types

I am using (2).

[Evert]

1) bitboard which would be updated on moves or captures of a promoted piece

2) promoted versions of the Q, R, N, and B piece types

Option 2 is preferable, I think. It easily lets you specify piece values for these too (which should be different from their unpromoted counterparts).
The variant agnostic nature of my engine pretty much rules out option 1 as a reasonable alternative though, so I never tried it.

[hgm]

I also use different piece types. Shokidoki distinguishes 16 piece types per color, CrazyWa 32. Half of these are promoted types (i.e. they demote on capture). The King can be either, as it cannot be captured anyway. In both CrazyWa and Shokidoki it proved more convenient to put it with the promoted types.

But since both these engine are mailbox, option (1) would not be suitable.

[Evert]

I also use different piece types. Shokidoki distinguishes 16 piece types per color, CrazyWa 32. Half of these are promoted types (i.e. they demote on capture). The King can be either, as it cannot be captured anyway. In both CrazyWa and Shokidoki it proved more convenient to put it with the promoted types.

But since both these engine are mailbox, option (1) would not be suitable.

If you use a piecelist (not saying you do), the two options become sortof the same if you place promoted pieces in their own range, do they not?

[zenpawn]

Thanks, everyone. I started heading down the path of adding new piece types, but not yet sure how/if Zobrist works with them.

Also, is there a FEN-like notation for Crazyhouse to indicate promoted pieces?

[hgm]

I am not sure how a piece list comes in to this. It is true that when I identify a 1-bit slice through the mailbox board as a bitboard, the '16' bit would correspond to a 'should demote on capture' bitboard. This because I use piece types 16-31 for promoted pieces, and 0-15 for unpromoted pieces.

Initially I did not use that in any way, though: because the hand counters reside in the (non-contiguous) unused part of a 0x88-like board, I use a table to map (colored) piece types to hand counters. So any piece can demote to any other (including itself, i.e. no demotion). A move can imply a constant to be added to the piece type, and this constant could have been chosen different from 16. For under-promotions in Crazyhouse it actually is.

But for Wa (the only critical case) 16 happens to be perfect: there are 16 pieces that can be in hand, two of which (put 14 and 15) cannot promote. 16-29 are then the corresponding promoted types, 30 ('promoted Eagle) is unused, and 31 ('promoted Fox') is used for King. Because of this it does not matter whether you add or OR the promotion increment to the piece type, not even in Crazyhouse under-promotions, because the type code for Pawns is 0. So I switched to OR'ing the increment, because that makes the engine resistent to a promotiong move being erroneously applied to an already promoted piece (E.g. because of a hash-key collision).

BTW, I don't use a piece list. Scanning the board to find own pieces is an overhead I don't really like. But in drop games the board is never very empty, so the overhead is not that big. And updating a piece list is not trivial either, because such a list would have to be able to accomodate all pieces on one side. So it would either have to be variable-length, or it would be on average half-empty, not much better than scanning a board that on average is 3/4 empty. Perhaps using white and black 'bitrank' occupancy variables might give a slight speedup. But that is only a micro-optimization.

[hgm]

Also, is there a FEN-like notation for Crazyhouse to indicate promoted pieces?

Yes: a tilde (~) is appended to the piece type to indicate it is a promoted Pawn. E.g. Q~.

And pieces in hand are appended to the board enclosed in brackets [].

[zenpawn]

How is everyone handling Zobrist keys for the transposition table? The extra piece types are one wrinkle, but there's also the reserve.

[kbhearn]

holdings aren't difficult to handle for the zobrist keys, they're just extra bits of game state - so for each side you have holdings of 0-2 queens, 0-4 knights, bishops, rooks, 0-16 pawns - this can simply enough be enumerated by (3+5*3+17)*2 zobrist keys using xor.

or... you can do it with just one zobrist key for each piece type/color and addition/subtraction method instead which would save a few (possibly irrelevant) ops and keys (i.e. zobristHoldings = sum over all colorpieces(keyHoldings[colorpiece]*countHoldings[colorpiece]) which can be incrementally updated with a single addition/subtraction as a piece gets captured or dropped)

similarly the extra piece types are again just extra zobrist keys - technically you could get away with just 64 more zobrist keys (one per square) that says 'the piece on this square is a promoted pawn' - but maybe you want 8*64 for white-knight-promoted-from-pawn etc for simplicity's sake.