Author: Stuart Cracraft
Date: 18:15:20 01/11/98
Go up one level in this thread
Thanks. On January 11, 1998 at 14:03:20, Robert Hyatt wrote: >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.