Distributed Chess Theory Was: Re: [rc5] v3
SHuffman at Atl.Carreker.Com
Wed Oct 29 08:21:26 EST 1997
On Tue, 28 Oct 1997 13:13:21 -0700, Sebastian Kuzminsky wrote:
> 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
Only at certain times in its operation. I envision the client as
having two modes of operations. First when it gets a game to work on
it needs to reconstruct the current board position. If we assume that
all transmitted moves are legal this becomes extremely quick (Move
Piece 7 to square 32: Place piece 7 in square 32; Capture any piece
currently there; Check for special conditions [eighth rank pawn,
castle, etc]; remove piece 7 from current position). When evaluating
possible moves from that position, then the client needs to know what
moves are possible for each piece.
> 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.
I am not as concerned with the size of the matrix while the client is
evaluating. An eighth rank pawn can be in a state of flux (as far as
the client is concerned) until its moves define what piece it has
Of course when the client begins evaluating moves it needs to know the
pieces capabilities, so I do see a flaw in my encodeing scheme. If the
transmitted game sets up a board where a pawn has been converted and
only moved in either a rook-like or bishop-like fashion, then it may be
either a queen or the appropriate lesser piece. But hey, I don't
envision this happening often. How often is this ambiguity going to
> 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.
That is true, each time the number of pieces active is halved, you can
drop the size of a move by one bit. Once again though, variable length
fields adds complexity to the board reconstruction process.
"A penny saved may be a penny earned, but it's a waste of
a deposit slip and it really pisses off the tellers."
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.
More information about the rc5