Author: Guido
Date: 05:43:06 05/30/02
Go up one level in this thread
On May 29, 2002 at 17:09:51, Dieter Buerssner wrote: >On May 29, 2002 at 07:11:54, Guido wrote: > >Interesting post, Guido. > >>For example the KRBBKRR ending occupy in my indexing scheme little more than 85 >>Gb. > >Do you mean 85 Gb of indeces or 85 Gb disk space. With the forumula > >462*62*61*60*59*58/(2*2!) > >I get about 9^*10^10 which is about 84 Gb of indices. This would only leave 1 >byte per position (so no mates longer 127). Do you have any other tricks, that >save a significant amount of index space? I am aware of some "immediate check >squares" that can be left out. And - as you explained me earlier, the case where >all but one man are on the diagonal. But would think, that this will only save >few percents. > It is exactly my computation. I said that if 8 bits are not sufficient, it is not necessary to use 16 bits, but 9, 10 or more, depending on the longest sequence of that particular ending, so the problem is how to manage a carry different from 8 bits. I implemented an algorithm to realize this idea and write the correspondent code, but at present I have no possibilities to check the correctness of this part of the program. So if 9 bits are supposed sufficient, the requested disk space will be: 84*4*9/8 = 378 Gb and 400 Gb could be OK. I use a 600 MHz PIII with 512 Mb RAM and until now, with an old program that uses only RAM, I generated all the TBs with 3,4 e all 5-men TBs with pieces and some with one pawn, and therefore not the last case KPPKP which would contain one position, a lost in 127 moves, for which 8 bits are not sufficient (clearly a specific solution for this exception could be easily found). I am a little afraid of using the new program for calculating the other 5-men endings because it uses continuously the disk for days and days for each ending. My tests of the program were made only with 4-men endings, while a first test with 5-men still shows a little bug that I'll correct in a short time. So I wait for a cheap more powerful 64 bits PC and larger and faster disks. >>I think that CPU time in generating 6- and 7-men endings is surely the biggest >>problem, together with the requested characteristics of the disks, but when 64 >>bits processor and large and fast disks will be cheaply available, computations >>of EGTB could be done for the most part in parallel by many people on different >>computers (as it is done now for Mersenne's primes), sending reciprocally their >>results to the other partecipants, so reducing the years requested for this job. > >I have no idea, how the job could be parallelized for a single pawnless TB. For >pawns, sure, because one could have an extra TB for each pawn position. But >still then, the ones with more advanced pawns would already need to be >available, to calculate the ones with less advanced pawns. So, say for single >pawn TB at most 8 could be done in parallel (a7-h7, and so on). Do I miss here >anything? I was speaking of generation of a set of Tbs not of a single ending: e.g. if you have to generate 5-men TBs, all the Tbs with only pieces can be generated in the same time from different people, provided obviously that all have the 4-men TBs, so a lot of work can be done in parallel. When this work is ended, all these TBs are given to the partecipant, so it is still possible to generate Tbs with one pawn in parallel and so on. It is clear that at the end only one person will generate the KPPKP ending, possibly with the fastest machine. I don't know if Prof. Hyatt is now working with more computers in parallel to generate 6-men Tbs. The problem you spoke about is different and is related to the fact that endings with pawn occupy a lot of space and spend a lot of time, so it could be useful to subdivide the single tablebases, keeping into account the irreversibility of the movement of the pawn. But IMHO in this case, at first sight, it is not possible to work in parallel, and even more the same is true for pawnless endings. >Guido, do you have a TB generator? DTM or DTC? Will it take the 50 moves rule >into account? As said before, I have a TB generator for 3, 4 and 5 men (kppkp excluded), DTM type, that doesn't take into account the 50 moves rule and treats ep-capture in an approximate way. My generator (the old version that uses RAM) contains other functions as: Tablebases checking Single position analysis Extracting positions by single result (white or black moves) Extracting of positions by combined results (white and black move) Memory needs evaluation for tablebases generation Chess endings manual simulation (it permits to play manually a game ending, covered by tablebases, giving the response in any situation for each legal move) I put this program in exe code on my site, but before informing CCC, I asked to g_6 group members (a group of italian programmers) to check the results and the use of my TBs in their programs using a very simple object library present on the same site. I have to revise the explanation in english and to update the program getting it faster, but if you are interested now, I'll send you privately the site address. Ciao, Guido >Cheers, >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.