Re: computer-go: Re: Nullmove

[Vincent Diepeveen <diep@xxxxxxxxx>]

At 02:01 PM 11/18/99 -0800, you wrote:
>
>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.

Nullmove is evaluation independant reducing the tree size.
Basically you allow your opponent to move twice in a row,
so give a more clear bound to cutoff a tree on beta, no matter
the evaluation strength.

Greetings,
Vincent





Vincent Diepeveen
diep@xxxxxxxxxxxxxxxxx

---
... en verder ben ik van ben ik van mening dat Dap het gesticht in moet