Author: Tony Werten
Date: 04:39:29 04/10/03
Go up one level in this thread
On April 10, 2003 at 06:06:10, Guido 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 > >Yes, this is also possible, but in this way my solution would be better because >the result is obtained immediately simulating EP capture. >But the problem is not solved correctly, as Uri Blass demonstrated to me with >this easy example: > >[D]1K6/2p5/8/1P6/8/8/8/k7 b - - 0 1 > >If I look for the result in tablebases without EP (black moves), it is a draw, >while the actual situation is a loss, and in this situation no EP capture still >exists. If the tablebases have been generated with the same skip trick, this position would have been assigned the value "loss". ie The position after f5 will be found (without ep square:draw), but since an epsquare exists, it is not accepted. All replies are generated (including the ep capture) and the score will be a win for white. Tony >IMHO the correct solution for EP is to have two different positions for white >pawns in rank 4 and black pawns in rank 5, using rank 1 and rank 8 respectively, >as discussed in another past thread with Bob Hyatt. > >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.