Author: Tony Werten
Date: 23:24:03 04/09/03
Go up one level in this thread
On April 09, 2003 at 12:25:33, Robert Hyatt wrote: >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. :) Since I program in Delphi I couldn't use that code without conversion ( well..) so I did a lot of this stuff myself. It did give me inderstanding about EGTB but the solution I found later was a little easier: Compile Eugene's code to a dll and call it from my program :( Since my code is quite a lot faster for 4 pieces I use both now, 4 pieces in memory, 5 pieces on disk. 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.