Author: Robert Hyatt
Date: 20:29:15 04/10/03
Go up one level in this thread
On April 10, 2003 at 11:51:22, Pavel Blokhine wrote: >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. :) >> >> >>> >>> >>>>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 > > >How much much RAM and GB Hardrive would be recommended if i want to install all >of the Nalimov EGTB on my computer? At the moment, we have over 200 gigs on my ftp machine. A couple of weeks ago he mentioned that he had another 50 gigs done and more in progress. Where it will end is a guess. I'd guess a terabyte. Memory is another issue. I think the current tables (all on my ftp machine) require over 200 megabytes for decompression indices, not counting hash, cache and everything else you would normally use. I'd probably go for a 2 gig machine nowadays...
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.