Author: Komputer Korner
Date: 22:04:35 11/23/97
Go up one level in this thread
I would suggest that EG researchers stop after completing all the 6 man pawnless EG tablebases and then start doing ones with pawns. The reason is that I challenge anyone to come up with an actual game position that has ever had a 7 man or higher pawnless endgame. On November 18, 1997 at 12:31:18, Steven J. Edwards wrote: >A six man tablebase for a pawnless class has 64 times as many entries as >a pawnless five man class. Each pawnless five man class file (two >files, WTM and BTM, per class) requires 160 Mbyte with one byte per >entry; so a pawnless six man class needs 10 Gbyte, BUT only if each >entry requires a single byte. If, say, two bytes were used then 20 >Gbyte is needed. The problem is that the number of bits required is >based on the logarithms of the maximal mate/loss distances and these >aren't known until after the calculation is over. I have no doubt that >many of the six man classes are going to need more than one byte per >entry. > >Similar comments go for six man classes with pawns: at one byte per >entry, each of the files needs 32 Gbyte of storage. > >For each extra man, multiple the respective (pawn/pawnless) numbers by >sixty four. This means Tbyte (terabyte) sizes. > >In addition to entry size, another difficulty is the indexing needed for >large file access. Most consumer systems support, at best, 31 bits of >file indexing. This is 2 Gbyte which is big enough for most purposes, >but not for six man classes. There are a number of ways of handling >this, the obvious one being the use of multiple files for a single >tablebase class side-to-move. > >The program tbgen was designed from the start to allow generation of >classes with more than five men. It does not require RAM storage >proportional to the class size, but instead uses disk resources so it >can run on modest machines as long as they have enough mass storage. >Of course, the index type used in tbgen (indexT, a long int) needs to be >redefined to handle extra long indexing. Another feature of the tbgen >program is that none of the files it uses are accessed randomly (e.g., >fseek()), but instead only sequentially. This means that tape drives >can be used for some or all of the files. Some minor recoding might be >needed depending on the tape interface, but nothing very significant. > >I have spent some time working on estimation of running times for >different classes. There are many factors involved including piece >count, type, distribution, etc. The truth is that the only way to find >out how long a class might take is to go ahead and generate it. > >But before starting anything with six man classes, I would first propose >that work be continued on completing the en passant implementation. >This would allow a full KPKP (very handy) and eventually a full KPPKP >(which would be extremely useful). > >(tbgen.tar.gz and tbgen.zip are available from the chess.onenet.net ftp >site in the pub/chess/uploads/TB directory.) > >-- Steven (sje@mv.mv.com)
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.