Author: blass uri
Date: 08:48:50 10/11/98
Go up one level in this thread
On October 11, 1998 at 10:47:07, Robert Hyatt wrote: >On October 11, 1998 at 03:07:04, blass uri wrote: > >> >>On October 11, 1998 at 00:42:55, Robert Hyatt wrote: >> >>>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. >> >>I know that we store a number for every position and the numbers represent moves >>but I understand that the idea of roberto is to to store numbers that represent >>moves and to store the result(only in win,draw,loss) instead of storing numbers >>that represent exact results >> >>In KBBvs KN we can do for every position a list of legal moves such that the >>moves that lose a bishop without giving the oppoent to mate in 1 or causing the >>distance of the kings to be longer are in the end of the list. >> >>If in all the positions there is a best move from the 32 first moves in the list >>we can store the right move by 5 bits. > > > >but that's the problem and that's where this falls into oblivion. *if* I could >do this, I would be doing forward pruning in the tree, because I would "know" >that the first 32 moves contains the best move... But neither I nor anyone >else knows how to do this. If I did, I would improve the algorithm to ensure >that the best move is #1 in the list, and then I'd avoid searching anything. > > >>> >>> >>> >>> >>>>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. >> >>you need to search only to improve the score. >>and if 2 plies are not enough you search for 4 plies >> >> "I implemented this and can prove that it will work" >>is >>>going to convince me a lot quicker. >> >>I did not try to implement it but I see no problems with the idea. > >I see lots of problems. Alpha/Beta needs a way to compare positions >accurately. I want to know which position is best, not which group of >positions are "equal"... If I have conversion in 97-100 plies my target is to force a conversion in 93-96 plies if I cannot in 1 move against every reply of the opponent then I force it by 2 moves after 2 moves(4 plies) I did a progress of 4 plies in the distance to conversion so there is no problem. It is only important to get closer to conversion and I do it Uri
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.