computer-go: Re: Nullmove

[Dave Dyer <ddyer@xxxxxxxxxxx>]

I think nullmove, while valid, is not all that useful for Go.  
The problem is that nullmove is useful only if it can give
a strong signal "ignore this threat at your peril".  This works
well for chess, where the refutation for most stupid moves is that
a piece gets captured.

In Go, there is no strong signal in almost all cases, so nullmove
is not going to produce much useful information.

In my problem solver, the standard way to run a problem is to run
it twice, once with "black moves first" and then with "white moves 
first".   Running black-first, then feeding the result of
that search into the white-first search, is roughly equivalent to nullmove.

The upshot is that searching black-moves-frist first takes just as 
long as searching white-moves-first, and even when run to completion,
doesn't usually change the effort required to run the white search.

There certainly is a space where nullmove-type tricks are useful, but
it's not a dramatic improvement.  The real problem is weak evaluators.