Author: Robert Hyatt
Date: 20:12:29 10/18/99
Go up one level in this thread
On October 18, 1999 at 22:13:56, William Bryant wrote: >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 The trick is this: at times you do a hash probe, and you get a score or bound, but the draft is insufficient. However, think about your null-move search. It is going to search this same position, but 2 plies shallower. So if the hash entry isn't good enough to use normally, remember when you get a UPPER bound from the hash table, and see if that bound is < the current alpha value. If so, and the depth is good enough to satisfy the null-move search (draft is at least remaining depth - 3 plies since null-move will reduce depth by 2 and you would normally reduce by one more) then you know that the null-move search won't fail high, since this hash entry says it would fail low. Don't bother trying the null-move search since you know it won't fail high and will just be wasting time... In crafty, hash.c, the "avoid_null" variable holds this. If we can't fail high or low or return an exact score, I return this value which says "no good hash info, but avoid trying null move here anyway..." Bob
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.