Author: Robert Hyatt
Date: 07:33:26 02/11/02
Go up one level in this thread
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. > 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.