Author: Robert Hyatt
Date: 09:25:33 04/09/03
Go up one level in this thread
On April 09, 2003 at 10:25:02, Tony Werten wrote: >On April 09, 2003 at 09:34:50, Guido wrote: > >>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. > >Probably the safest way (I used to use) is jump out of the probing code with a >"position not found" result. Your search will continue and find the correct >result 1 ply later. > >Tony Or use Eugene's code which handles EP correctly. :) > > >>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.