Distributed Chess Theory Was: Re: [rc5] v3
kuzminsk at taussky.cs.colorado.edu
Tue Oct 28 13:13:21 EST 1997
"Skip Huffman" <SHuffman at Atl.Carreker.Com> wrote:
] That does save one bit, but it significantly complicates the design of
] the client. The client now has to keep a separate table for each type
] of piece so as to translate its "move code" into a board destination.
] The trade off may or may not be worth it. Also it would make pawn
] conversions more complicated because a pawn that has reached the eighth
] rank may have become any of several pieces with different movement
Your arguments against (as i understand them, correct me if i'm
1. It makes the clients more complicated because they need to be able
to figure out where the pieces are allowed to go.
2. It makes pawn promotions more complicated because once promoted, the
moves allowed change.
First, the client needs to know where the piece can move anyway,
because it needs to be able to advance the board position by making all
possible moves for all possible pieces, iteratively. This can be done
Second, by the 200-bit board encoding proposed on the list recently,
after a pawn has been promoted it is not encoded as a
pawn-promoted-to-X, but simply as X (for some suitable piece X). We DO
need to add a field to the encoding of a pawn moving to the opponents
base rank. This field would be 2 bits long, and selects between rook,
knight, bishop and queen. That increases the size of a pawn move from 5
to 7 bits, when promoting.
Another opportunity for optimization is to decrease the number of
bits used to encode the piece. It is known how many pieces are on the
board and where they are, so the piece selection field of the move
encoding only needs to select between the currently active pieces.
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.
More information about the rc5