[Exceptional C++ Style] Item 26 -- Data Formats and Efficiency

[Adrian Fagg]

> -----Original Message-----
> From: effective-cpp-bounces at accu.org
> [mailto:effective-cpp-bounces at accu.org]On Behalf Of Lois Goldthwaite
> Sent: 31 January 2005 00:07

> Since White and Black always move alternately, you could even
> reduce this to
> 10 bits by considering only codes for the appropriate
> player's pieces. Here
> again, noting what piece a pawn promoted to would require a
> bit of extra
> space, but I'm assuming the new queen (or bishop, knight, or
> rook) could
> continue to keep the same identifier in the game. Come to
> think about it,
> it's rare for a pawn to promote to anything except a queen. If queen
> promotion were the assumed default, extra space in the game
> score would be
> needed only rarely.

Very nice. It seems that given the sequential nature of a game, two extra
bits inserted into the stream whenever a promotion occurs is as good as it
gets. Otherwise how do you know it was the default case and the next two
bits are the first of the next coordinate or piece?

>My final suggestion is to use a bit of lateral thinking and find some other
>means to reduce the size of the chess database. An off-the-shelf compressor
>like bzip might result in more space-saving than all the bit-twiddling we
can
>hack. Of course real tests on real files should be performed before making
>this decision.

In my experience (i.e. a very few cases), a more efficient data format
compresses to something a little smaller than an inefficient one. Usually
it's a law of diminishing returns though.

Lossy compression is a whole different kettle of fish - typically almost all
video formats look random enough to zip, rar etc to be only slightly
compressed if you're lucky, whereas they may vary by orders of magnitude in
their own effectiveness.

Regards,

Adrian

Work: mailto:adrianf at evaluategroup.com
Home: mailto:adrian.fagg at ntlworld.com

Pretty pictures: http://homepage.ntlworld.com/rbyadf/