Author: Robert Hyatt
Date: 15:00:21 07/26/98
Go up one level in this thread
On July 26, 1998 at 17:19:41, Pat King wrote: > >On July 26, 1998 at 16:08:19, Robert Hyatt wrote: > > >> >>>Thus stalemates and mates would get stored in the hash, but other draws >>>wouldn't. You only need to examine the history back to the last capture or pawn >>>move, so adding the history search isn't terribly expensive, although whether >>>it's worth the effort in terms of rating points is another matter. >> >> >>the problem above happens even if you don't store draws in the hash table. The >>score in question isn't a draw, it's a real score... try this: >> >> >>.....................X............Y..............Z >> >>at position X you continue searching, past position Y, to reach endpoint Z. >>You back up, and when you back up to X you store the score (say +5). >> >>now you search this path: >> >> >>..............Y............X >> >>when you reach X, you get a hash match, and say +5. > >No, what I proposed was that you reach X, check for draws by repetition/50 move >via the position stack (assuming your program has such a thing), THEN consult >the hash if a draw isn't found. > notice that X has *not* occurred before, so you won't find it. But if you *try* to follow the path from X to Z, you will encounter Y along the way and have a draw. But you won't know you will encounter Y, so you make the choice at X to trust the hash table, play the move, and commit to that variation. ANd a few moves later you are forced to play the move that produces position Y and accept the draw... >It also occurs to me that you are probably using much larger hashes, and >consulting them at every node, whereas I'm only checking at terminal nodes. In >other words, I'm not storing backed up values, and can be sure of the history of >a position. aha.. you aren't using a "transposition table" then... You are only storing evaluations it seems. It seems that the "draft" of all your positions is "0"? which certainly solves the problem. the headache comes when you don't just use terminal probes and stores... > >>But that is wrong, because >>note in your path before X you searched position Y, which means halfway between >>X and the endpoint Z you will encounter a repetition. And get 0 rather than >>+5. > >The 0 score never gets stored, and the +5 store in the hash never gets >consulted. > >>But you have no way of knowing this, and no way of preventing it from >>happening, unless you store all the path information from the 50-move-rule >>counter position to the endpoint... > >Which I'm doing, just not in the hash table. I AM storing the entire game >history and current variation in a stack structure. Draws found via this >structure are NOT entered in the hash table. > >>then you could detect the repetition Y >>in the hash entry and realize it is not an accurate score. But it would make >>the hash table basically useless... > >The hash is only consulted when a repetition/50 move draw did not occur. It >contains only the results from the static evaluator. The only sticking point may >be qsearch interactions, which I'm still pondering. > >>>>(2) does the error in (1) affect the program? > >There's the rub! I know your progam's a LOT stronger than mine is at the moment, >and a lot of that strength is the speed and depth you get from the backed up >values in your hash table. Is the more accurate evaluation of draws in mine >worth what I've thrown away? In the end, probably not, but I didn't start out to >make a world-beater :) > >Pat
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.