You can also add a layer of checking moves at the first q-search ply (which is what I do) to avoid most of the problems you'd get from collapsing the tree and dropping right into a capture-only search which might not be able to properly refute the null-move and lead to a ton of errors.Sven Schüle wrote:Yes, the code in blue requires some "if (depth >= ...)" guard. If you want to allow your null move search to start directly with qsearch, i.e. with zero plies of full-width search, then the condition should be "if (depth - 1 - R >= 0)" which is equivalent to "if (depth >= R + 1)". Otherwise (which is what I would prefer since I think a null move search that does only qsearch can be dangerous),cms271828 wrote:Looking at the code again in blue http://web.archive.org/web/200404270146 ... llmove.htm
I'm concerned about the depth, since say D=1, this wouldn't call alphabeta (or qs in my case) with depth 0, but with depth -2.
So perhaps we need to surround that block with 'IF D >= 3...' so that alphabeta (or qs) gets called by passing in 0 or greater depth.
the condition should be "if (depth - 1 - R >= XX)" or "if (depth >= R + 1 + XX)" where XX denotes the minimum number of plies above the horizon that you allow to start a null move search.
SvenCode: Select all
if (depth >= R + 1 + XX) { MakeNullMove(); val = -AlphaBeta(depth - 1 - R, -beta, -beta + 1); UnmakeNullMove(); if (val >= beta) return beta; }