Author: Robert Hyatt
Date: 21:42:55 10/10/98
Go up one level in this thread
On October 10, 1998 at 00:56:05, blass uri wrote: > >On October 09, 1998 at 22:54:49, Roberto Waldteufel wrote: > >> >>On October 09, 1998 at 18:46:36, David Eppstein wrote: >> >>>On October 09, 1998 at 15:24:26, Robert Hyatt wrote: >>>>This doesn't matter however, because *every* possible position must be accounted >>>>for, with an exact distance to mate for the side on move with that specific >>>>piece configuration. So they *all* have to be computed to build the next one >>>>after them... >>> >>>You don't need distance to mate if you are searching from a non-tablebase >>>position trying to reach a tablebase position (and aren't worried about the 50 >>>move rule, but you must not be since you're using distance to mate). >>> >>>If the actual game reaches a won tablebase position, you need some way to force >>>progress, but it doesn't have to be distance to mate. If you can always search >>>deeply enough to find a conversion (capture or pawn move), you can use distance >>>to conversion, and only store win/loss/draw in the tablebase. In any KXP-KP or >>>KX-KPP endgame, searching deeply enough to find a conversion should be easy >>>(there are fewer than a million distinct positions in which at most one pawn has >>>moved, so you can load just that part of the tablebase into memory and use the >>>hashtable to do the search quickly no matter how deep it is). >>> >>>But I agree with your main point, that the heuristics suggested by the poster >>>you were responding to aren't good enough -- the information needs to be exact, >>>and you need to compute lots of other tablebases before you can think about >>>KPP-KP. >> >>Even if the search were too deep to be feasible, eg an ending like KBBKN, it is >>still possible to reduce memory access requirements during the search by storing >>only win/loss/draw information, if we maintain a separate tablebase (not used in >>the search) which simply contains the best move > >You need memory to store the best move for example in KBBKN for the stronger >side the maximal number of legal moves is 8+13+13=34 legal moves >and you need 6 bits for a move so I think you do not save memory by this. >If you have a good order of moves and always 1 of the first 32 moves is best you >can need only 5 bits > I don't want to sound "harsh" but let's not get rediculous. Exactly *how* can we generate moves and *guarantee* that the best move is in the first 32? That is completely *impossible* to do, and discussing it makes no sense at all. Also, in databases, we *do* *not* store "moves". That is a misconception of some sort. Moves are not stored, only the status of each possible position. >If you store distance to conversion with my idea you need only 5 bits >for 1-2,3-4,...49-50,draw,loss >You need to do a search but I do not think there is a problem with small search. > >Uri this kind of statement isn't helping, either. "I do not think..." is not a convincing argument. "I implemented this and can prove that it will work" is going to convince me a lot quicker. "thinking" doesn't cut it here. It *has* to be right or it will certainly be wrong... And wrong we can't stand, because we trust these results *perfectly*...
This page took 0.01 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.