Author: Guido
Date: 06:34:50 04/09/03
Go up one level in this thread
On April 09, 2003 at 02:42:17, Tony Werten wrote: >On April 08, 2003 at 18:15:33, Guido wrote: > >>On April 08, 2003 at 02:57:42, Tony Werten wrote: >> >>>On April 07, 2003 at 14:28:55, Dieter Buerssner wrote: >>> >>>>On April 06, 2003 at 16:09:02, Tony Werten wrote: >>>> >>>>>For simple EGTB: >>>>> >>>>>After placing the white king, there are only 63 squares left, after placing the >>>>>white king there are only 62 squares left. So the index would be calculated >>>>>((((SQWK*64)+SQBK)*63)+SQWR) >>>>> >>>>>SQBK (square black king ) would be adjusted as follows: if SQBK<SQWK then >>>>>dec(SQBK) >>>>>SQWR would be adjusted: if SQWR<SQWK then dec(SQWR); if SQWR<SQBK then dec(SQWR) >>>>> >>>>>That's the trick that saves space (well, to start with) Of course it has 1 nasty >>>>>side effect: You can go from a position to an index, but it's quite impossible >>>>>to get the position back from an index. >>>> >>>>I think it is easy. >>> >>>No it's not. The fact that it works in my simplified example doesn't mean >>>anything, since nobody uses this. >> >>I use this in my EGTBs and it is OK also in a not simplified example. > >Do you include EP as well? That's where my "quite impossible" starts coming in. No, I don't include EP in tablebases generation, at least for now, but EP is considered in my EGTBs utilization, simulating the execution of the possible immediate EP capture. This way of operating is not completely correct, as Uri Blass demonstrated to me in a past thread, but I think that it gives an erroneous result in very few positions. The problem for me is connected to the fact that in the indexing I always suppose that the order of the men, pawns in this case, is fixed and that file dimensions are the same independently from the mover. So for example KPKP occupies 462*48*47 for both the files, while using 56 (48+8 positions for EP), I would have: Move to White = 462*48*55 (kings, white pawn, black pawn) Move to Black = 462*56*47 (kings, white pawn, black pawn) More exactly in the first case the black pawn would have 55 or 54 possible positions depending on the position of the white pawn. For these reasons in my EGTBs I left back the rigorous treatment of EP. The process of indexing can be considered as the computation of a global index in a n-D matrix. In the above mentioned example the matrix would be M[462][48][47] and inversion of the process is not complicate. On the contrary it becomes more difficult (and very expensive in cpu time unless using other tables), if the dimensions of the single indexes are interrelated and not fixed, as I suppose it happens in Nalimov's files. > > >>I use tables for Kings and for 2 identical men; obviously I need of other tables >>for each case if I want to go from a position to index and viceversa. >>For 3 or more identical men I use mathematics for both the transformations. >>In my opinion the difficulty of the inverse process in Nalimov EGTBs depends on >>the fact that, in order to reduce the dimensions of the tablebases, positions >>where there is a check, with the man close to the opponent king, are eliminated >>from the file. > >You mean it becomes "quite impossible" in a real situation instead of a >simplified example ? :) Mind you, I'm not sure it's impossible, it's at least >very hard. I also think it is very hard not impossible. 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.