Author: J. Wesley Cleveland
Date: 13:03:34 02/11/02
Go up one level in this thread
On February 11, 2002 at 10:33:26, Robert Hyatt wrote: >On February 11, 2002 at 02:30:53, Dieter Buerssner wrote: > >>On February 10, 2002 at 23:37:54, Robert Hyatt wrote: >> >>>On February 10, 2002 at 18:55:59, Angrim wrote: >>> >>>>On February 09, 2002 at 22:35:54, Robert Hyatt wrote: >>>> >>>>>1. 6 piece files are going to require some large mate-in-N scores. IE they >>>>>will need 16 bits at least, which doubles the size compared to a current 5 >>>>>piece file where all scores are 8 bits max. >>>> >>>>This doubles the size of the file before compression, but has little >>>>effect on the size of the compressed file. At least as long as the >>>>majority of the positions in the file are relatively short mates or >>>>draws. Only the positions which are long mates will take extra >>>>space after compression. Compression could be further improved by >>>>switching to building DTC tables. >>>> >>> >>>Think about that a moment, and you will see it is a flawed statement. IF >>>the file is 2x larger _before_ compression it will most likely be 2x larger >>>_after_ compression. Otherwise you are saying that larger files compress >>>more than smaller files which is a simply flaw in reasoning. >> >>I think, Angrim is correct. The file of the double size file has much less >>randomness, and so can compress better. For example a file of random bytes >>(values 0-255) cannot be compressed. Storing the value as 16-bit words makes >>this compressable to half size. > > >But again, with a pawn ending, what says that most of the positions have an >upper 8 bits of zero? I'm not into making assumptions about these things >after seeing what has _already_ happened. You don't have to make *any* assumptions. If most positions have the upper 8 bits zero, it will compress better. If not, it will not compress as well. I strongly suspect that this is true, as it means that most positions are draws or mates in < 128, but we will only know after the table is constructed. > >> Of course, in the case of TBs not all second >>bytes will be the same, but they should still be predictable with good >>probability (for example it can be known in advance, that there is no mate > 300 >>in a specific TB, which makes most available values in the 16 bit range not >>occuring at all). > >If they were built using such an assumption, which they are not, at present... > > > >> >>To the other point you mentioned - the efficiency of storing (say) 9-bit values >>instead of 16-bit values. As you point out, this needs more CPU resources - >>sure. But it will need much less memory/disk bandwidth, and I think it is not >>unlikely at all, that it will be faster in the end. Anyway, I think after >>compression it won't make a difference anymore. >> >>Regards, >>Dieter
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.