# Computer Chess Club Archives

## Messages

### Subject: Re: Counting & Encoding Any Chess Position in 157 bits

Date: 09:32:20 11/15/99

Go up one level in this thread

```On November 15, 1999 at 03:30:24, Ratko V Tomic wrote:

>> Two questions:
>>
>> 1) I didn't see side to move here. Another bit?
>
>I assume white is to move (as in the chess problems). This doesn't really lose
>anything "chesswise" since for every position with white to move there is a twin
>position with reversed colors also with white to move, therefore equivalent to
>the first position in which black had the turn.
>
>Overall I think that it doesn't make much sense mixing these types of issues
>(ep, castle, side to move, 3-repetition, 50-move, etc) with the combinatorics of
>the chess positions. Namely, even if you know the ep, castle and the side to
>move, you still can't continue to play a legal game from that position, unless
>you also know all the positions since the last capture or a pawn move (whichever
>came last), since you don't know how many times each of the positions you may
>get into occured earlier, and how many moves till the 50-move rule kicks in. You
>would need a position as far as 99 plies back, plus up to 99 plies leading to
>the current position to _really_ be able to play the legal game from that point
>on. Since, to paraphrase Kronecker, the laws of combinatorics come from God and
>the 50-move rule, 3-repetition rules, etc come from  humans, they're apples and
>oranges.
>
>One might as well ask to encode also the clock settings for each side, the type
>of time and various game limits and so on, since any of those might be
>considered necessary in some contexts to play the fully legal game from the
>given position on.

I understand your point of view here, but I am on the fence as to whether I
agree.

The advantage of side to move, castling state, and en-passant state is that you
can set up a position which effectively matches all of the major state elements
(dropping time, move by rep, and 50 move rule) and then analyze this position.

Since move by rep and 50 move rule are so infrequently applicable, they are not
very intrinsic to the vast majority of positions (granted a purist could argue
this point).

On the other hand, having NO state information is probably worse than having
just the basic state information. What can one do with a position that does not
have side to move? Well, I guess you could analyze it from each side and state
best move based on side to move, but it doesn't seem very helpful. Even if you
assumed side to move as white, that tends to be a bit awkward when you are
discussing a famous position where it is black to move (yes, it is Karpov to
move, but we changed the colors in order to store it).

Note: I believe that the EPD standard has side to move, castling, and en passant
state information for a single random position.

>
>
>> 2) How do you decode such a monster?
>
>To paraphrase yet another mathematician, this can be done quite elegantly, but
>the answer is a bit too long to fit on this margin. (Well, there are few
>thoughts on this question in the  followup post.)

I haven't read all of your other two posts (they will take a while to digest),
but I am still confused on how you could encode/decode a 117 bit (143 - 26 bit)
single value. Seems beyond the capabilities of normal C unless I'm missing
something (a special library for large binary values maybe).