Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Min # of bits needed to store a chess position

Author: blass uri

Date: 16:30:50 04/22/00

Go up one level in this thread


On April 22, 2000 at 17:41:35, Heiner Marxen wrote:

>On April 22, 2000 at 14:47:08, Tom Kerrigan wrote:
>
>>On April 22, 2000 at 13:28:39, KarinsDad wrote:
>>
>>>On April 22, 2000 at 13:25:03, Tom Kerrigan wrote:
>>>
>>>[snip]
>>>>
>>>>Notice my idea was to use Huffman encoding for the bitboard, and not the pieces.
>>>>
>>>>-Tom
>>>
>>>
>>>How so? Please elaborate.
>>>
>>>KarinsDad :)
>>
>>I doubt it would be possible to do a very good job compressing the pieces (4
>>bits ea.) themselves, but I think the bitboard should be fairly compressable. I
>>suspect that most bitboards have strings of 0's scattered throughout them.
>
>If you mean that bitboard which distinguishes empty from nonempty positions,
>then no: try to do the math yourself (at first I did not believe it myself):
>there are at least 2 and at most 32 of the 64 bits set to "non-empty".
>Sum choose(2,64) upto choose(32,64) and compare to 2^64, and you will see,
>that you need a little bit more than 63 bits to code all possibilities,
>regardless of how clever you do it.
>
>Heiner

You are right if you assume that all the location configurations of 2-32 pieces
are legal and have the same probability but not all the location configurations
of 2-32 pieces are legal

For example:
If there are 32 pieces you must have at least 2 of them in every file
because there is one white pawn and one black pawns in every file.
If there are 31 pieces you must have at least 2 of them in at least 6 files.

There are many configurations with probability 0 and I think that you can save
at least one bit even if you assume that all the legal configurations have the
same probability.

Uri



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.