Computer Chess Club Archives


Search

Terms

Messages

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

Author: Flemming Rodler

Date: 15:15:48 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

If you do variable length compression of the bitboard then you only care about
the average number of bits used to store the position and not if some very
unlikely position uses more than 64 bits to store. Since some positions are more
likely to occure than others (ie. the starting position) compression is possible
and the average would be below 64 bits/position.

/Flemming



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.