Author: Robert Hyatt
Date: 11:03:20 01/11/98
Go up one level in this thread
On January 11, 1998 at 11:14:59, Stuart Cracraft wrote: >On January 11, 1998 at 10:45:20, Robert Hyatt wrote: >>I do recursive null-move, but *never* two null-moves back to back, so >>that >>this isn't a problem. For me, turning this on (plus the hashing >>enhancement >>I described after Bruce explained his basic idea > >What is this hashing enhancement? Sounds like I need that one. > >Missed your explanation. Can you copy/paste it over or put in >a line or two describing? Thanks. > >Stuart Cracraft The problem is this: we are using a null-move search, and when it fails low with a "mated in N" score, we extend. But if you do null-move right, and use the hash table properly, you can avoid doing a null-move at times. IE suppose you do a probe (before the null-move search) and you get a hit that says "fail low", but with insuficient depth to be able to stop. If you look at the reduced depth the entry has, and compare it to the depth after searching a null (R=2) you might note that there is no point in doing a null-move search. Or, in a different circumstance, a null-move search when you are searching a root move with alpha=beta-1, might fail high, but when you re-search the move (assuming it is going to become a new best move) the null-move can't fail high or low, because of the wide alpha/beta window. In either case, if you avoid doing a null-move search, you avoid noticing the threat condition. I simply save this threat indicator in the hash table and extend when it is set, regardless of the outcome of the null-move search. prevents some fail-high followed by a fail-low search anomolies...
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.