Author: Pat King
Date: 14:19:41 07/26/98
Go up one level in this thread
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. 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. >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.