Author: William Bryant
Date: 19:13:56 10/18/99
Go up one level in this thread
On October 18, 1999 at 22:01:50, Robert Hyatt wrote: >On October 18, 1999 at 21:17:29, William Bryant wrote: > >>I may not ask this question right, so allow me the luxury of a long winded >>question to try and explain the question completely. >> >>When starting a new iteration, the PV holds the best moves searched to the depth >>of n-1 (the previous depth). These moves form the far left (or far right?) of >>the search tree and make the first moves searched. Now the question, since >>these moves have already been searched, is there any point in stopping along the >>way and doing a null move until this line has been extended initially to the new >>depth. IE the first leaf evaluated should be at the end of the old pv, should >>it not. >> >>My Null move code starts checking null moves while depth is sufficient. >>Therefore, it will start null moves as soon as the first few moves of the pv >>have been made on the way to the first leaf. I empirically think that this will >>simply waste time because this line has already been searched, and that null >>moves should be postponed until after the first leaf has been searched or until >>the tree has been extended initially down the first branch following the pv to >>it's first. >> >>Am I close? Is there any advantage in doing the null moves while still >>following the pv to the first leaf? >> >>William >>wbryant@ix.netcom.com >> >>//my code idea goes like this >> >>if (pv_move) >> do_Null = false; >> >>pv_move is set to false as soon as search at any iteration moves beyond the >>bestmove phase and generates moves for the ply. > >I used to do similar things years ago... but I found that trying null-moves >_everywhere_ helps in a lot of cases, hurts in only a few cases, and overall >is better. Not to mention making the code simpler, using one less register to >pass that flag from one Search() call to another, etc... > >However, that was _my_ results. That doesn't mean it will be _your_ results. >You ought to try it both ways. BTW are you doing the hash table trick that >lets you avoid null-move searches in the right place? It effectively prevents >trying null-moves in the PV positions you gave anyway... I would love to say yes, but in truth probably not. I am stuffing the PV into the hash table, but the best move is searched after trying a null move -- should I search the best move before trying a null move? I currently: 1) try for a hash table cutoff 2) try for a null move cutoff 3) try for a best move cutoff 4) generate and start searching moves at this ply I also followed Crafty's example and do hash the threats? finally, I see if a null move is pointless with the following code: //check to see if doing a null move is pointless if ((theHashRecord->Type == hash_Upper) && (curDepth - NullRDepth - 1 <= theHashRecord->Draft) && (theHashRecord->Score < beta)) doNull = false; A little enlightenment would be helpful and, as always, appreciated. I am sure I am missing something at this point. Thanks, William wbryant@ix.netcom.com
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.