Author: KarinsDad
Date: 19:38:01 05/21/99
Go up one level in this thread
On May 21, 1999 at 14:35:56, Dave Gomboc wrote: >On May 21, 1999 at 14:17:14, KarinsDad wrote: > >>On May 21, 1999 at 12:58:35, Dann Corbit wrote: >> >>[snip] >>> >>>I have not had a chance to check the reference, but I think 100 bits is >>>incredibly few. In effect, it means specifying the state of each square >>>in 1.5 bits, or the state of each piece in 3 or 4 bits." >>> >>>J. Nievergelt has promised to send me a postscript document when he gets back >>>into country. I am awaiting that document with baited breath. >> >>I can understand saving each piece type (including state information) in less >>than 4 bits per piece, but how do you compress the location of the pieces? >> >>For example, even a starting position of chess where you know exactly where the >>pieces are requires 32 pieces * ~3 bits per piece (color is assumed based on >>side of the board) = slightly less than 96 bits. >> >>Please forward me on a copy of this when you get it if it is worthwhile. >> >>KarinsDad :) > >Didn't somebody already describe the method here? It boiled down to a decision >tree. The idea is to ask questions about the position, and the future questions >you ask will depend upon the answers you already have. Kind of like a big >decision tree. > >Dave Isn't that what the current compression schemes do (in an offhand sort of way)? I'm not convinced this will work for all positions. If you have the algorithm (i.e. decision tree), please post it. Thanks, KarinsDad :)
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.