Author: Heiner Marxen
Date: 04:08:41 02/11/02
Go up one level in this thread
On February 10, 2002 at 23:40:06, Robert Hyatt wrote: >On February 09, 2002 at 22:49:22, Russell Reagan wrote: > >>On February 09, 2002 at 22:35:54, Robert Hyatt wrote: >> >>>Several issues: >>> >>>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. >> >>Why would you need to use a full 16-bits? And why would you add on "at least" to >>that? How many mates are going to take more moves than 65,536 moves without >>reaching a 50-move rule point or 3-fold repitition? The answer is none. Maybe >>you could explain why my reasoning doesn't work. >> > > >Simply because the _current_ way of building them uses distance to mate. >And distance to mate is distance to mate, period... and it will definitely >push beyond 8 bits, and using 9 bits is _not_ convenient for reasonable speed >and accessing. I feel different. Accessing non-byte aligned entities packed into memory just needs a multiplication, a division and some shifting and masking. That is not much overhead compared to the complex index computations, with lots of table lookups, the bookkeeping of the caching and multiple function calls done for just one EGTB probe. OTOH, the memory savings can be significant. Also, when less than 8 bits would be sufficient. I think, one main reason to stay byte aligned is that the compression algorithm works on bytes, and would not achieve good compression, when odd bit lengths are packed together, crossing byte boundaries all along. Unfortunately, I do not know of a better compression algorithm, which works well with entities of arbitrary bit sizes. Otherwise I would already have proposed it. Cheers, Heiner
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.