Author: Tony Werten
Date: 07:25:02 04/09/03
Go up one level in this thread
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 >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.