Author: Guido
Date: 14:33:01 05/31/02
Go up one level in this thread
On May 30, 2002 at 18:38:52, Dieter Buerssner wrote: >On May 30, 2002 at 08:43:06, Guido wrote: > >>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. > >I think, I understand, at least partitially. I wonder however, how one could >know the number of bits needed in advance. To give a simple example. KRK is at >most a mate in 16 and obviously never lost. So we need (ingoring illegal >positions, which we could code as draw) a bit more than 4 bits :-). Without >going through the complications of coding (say) 15 values in 8 bytes, 5 bit >would be a good start. But when you start generating the TB, how can you know >this (without doing the work twice)? This point had been already foreseen by me, and computation of KPPKP ending would have permitted to me to check it. I think to have a solution of this problem without repeating the calculation, but I prefer to speak only after having achieved the result. Your example of KRK ending is a little different because in this case, in order to know the minimum number of bits per position, you need to have already computed the TBs. But I think that your idea could be very interesting in general for reducing the space for uncompressed TBs. This could be a good solution in using TBs, even if not useful for their generation. >>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. > >Hmmm. As an example the perhaps most useful of all TBs - KRPKR (at least for >programs, that do not have sophisticated knowledge of this ending). When KQRKR, >KRRKR, KRBKR and KRNKR are available, one could start to calculate KR(Pa7)KR, >KR(Pb7)KR, etc. in parallel. Why not? When the "rank 7" TBs are available, one >could calculate the rank 6 TBs in parallel, and so on. After all, there can only >be a conversion to the higher rank TBs. Yes, you are right! Probably something of similar has also been done, but it seems to me very complicated. I never thought about this possibility, while in the past I tried to generate ending with pawns where two values defined the first squares occupable respectively by the white and black pawns, but afterwards I abandoned this attempt. >>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. > >Thanks for your offer. I am a patient man, and can wait (and experiment myself). > >Ciao, >Dieter Ciao Guido
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.