Author: Eugene Nalimov
Date: 14:30:29 11/17/98
Go up one level in this thread
On November 17, 1998 at 17:19:30, Robert Hyatt wrote:
>On November 17, 1998 at 15:34:15, Eugene Nalimov wrote:
>
>>Very rough estimation:
>>
>>Pawnless 6-man ending - 10**10 positions.
>>6-man ending with pawn(s) - 2.5*10**10 positions.
>>
>>8 bits per position is not enough, 9-10 bits necessary.
>>So, pawnless 6-man ending will use 20Gb, ending with pawn(s)
>>will use 50Gb.
>>
>>It's possible to handle huge files at PC using NT (there is
>>no such restriction on file size as in Linux), but to be
>>reasonable effective generator must use 1-2Gb of RAM (I'm
>>speaking not about my generator, but about generator that
>>is written especially with 6-man tables in mind). Also, you
>>must have necessary amount of disk space free.
>
>
>how do you address such a big file since (a) the PC has 32 bit words
>and (b) the ansi standard requires that the data type for fseek() be
>a "long" and not something obtuse?
>
>IE the alpha handles this nicely even under linux... but on a peecee...
(1) You can use not C I/O library, but Win32 primitives... And
there you can specify 64-bit index (or 2 32-bit halves).
(2) Or you can manually split large file into several smaller
ones. Than you can use (index64 div 2**32) as file #, and
(index64 mod 2**32) as offset in the file.
(3) Or you can use several fseek() calls - first one is
absolute, and subsequent ones are relative to the current
file position. Must work if there is not OS-enforced file
size limit.
Option (1) or usage of 64-bit OS is of course preferrable, but
option (2) is highly portable.
Eugene
>>
>>The hardest part will be generation of pawnless endings -
>>endings with pawns can be partitioned to a lot of subclasses,
>>depending of the pawns locations.
>>
>>Of course you can
>>(1) Generate on a powerful supercomputer (BTW, task can be
>> parallelized very well), compress table, transfer compressed
>> table to PC, and decompress only small chunks when necessary.
>>(2) Generate not DTC or DTM, but win/draw/loss table -
>> then you can pack 5 positions per byte.
>>(3) Generate some subclasses - e.g. with rammed pawns, or
>> with 2 identical pieces, etc.
>>
>>Eugene
>>
>>On November 17, 1998 at 13:03:53, Robert Hyatt wrote:
>>
>>>On November 17, 1998 at 08:14:45, Mark Young wrote:
>>>
>>>>On November 17, 1998 at 08:05:33, Robert Hyatt wrote:
>>>>
>>>>>On November 17, 1998 at 06:35:08, Ralph E. Carter wrote:
>>>>>
>>>>>>Has anyone projected the size of these?
>>>>>
>>>>>
>>>>>easy to do... for edward's format, use 64* size of previous file. IE for
>>>>>openings with at least one pawn, two files each with a size of 32 gigabytes.
>>>>>
>>>>>Eugene's format is more compact, around 50%. Still *very* *big*...
>>>>
>>>>How big a factor increase is adding pawns to the table bases that are 6 ,7 or 8
>>>>man.
>>>
>>>It really is not a factor. IE if you have a totally pawnless tablebase, then
>>>a tablebase with a single pawn is bigger, because some of the compression
>>>tricks can't be used or you will make a pawn move in impossible directions when
>>>you rotate reflect and mirror the board. But once you have a single pawn on
>>>the board, every additional piece is roughly 64 time bigger than the last
>>>one. Eugene actually beats this a bit, so that since some squares are occupied
>>>(say 5 in a 5 piece ending, going to a 6 piece ending only takes 59* as much
>>>space (if I calculated that right) and not 64* like the old Edwards indexing
>>>scheme...
>>>
>>>But it really is moot... No PC's allow files that large today, because of the
>>>32 bit nature of the processor... you can't go beyond 4 gigs on any machine I
>>>know of until you step up to the alpha/etc 64 bit architectures... Yes it is
>>>"possible" to go beyond 4 gigs on a PC, but it makes handling the file index
>>>very messy... and I don't know of a system that does it...
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.