[Bug-gnubg] [Q] Full-width search

[Thomas Hauk]

I am trying to get Gnubg to perform a full-width search with a depth of 3 
(aka gnu1-ply).

Since all of the move filter settings I've seen do at least some trimming 
of the candidates, I thought I could make my own movefilter array that is 
"maximal":
   movefilter gnu_mfs[MAX_FILTER_PLIES][MAX_FILTER_PLIES] = {
      { { 9999, 0, 0.0 }, { 9999, 0, 0 }, { 9999, 0, 0.0 }, { 9999, 0, 0 } },
      { { 9999, 0, 0.0 }, { 9999, 0, 0 }, { 9999, 0, 0.0 }, { 9999, 0, 0 } }, 
      { { 9999, 0, 0.0 }, { 9999, 0, 0 }, { 9999, 0, 0.0 }, { 9999, 0, 0 } }, 
      { { 9999, 0, 0.0 }, { 9999, 0, 0 }, { 9999, 0, 0.0 }, { 9999, 0, 0 } } };

I then am passing this to FindBestMove.

To test if this is working, I am comparing the resulting move FindBestMove 
returns with the move returned when I do a search using my own code (using 
Expectimax, just to be safe). However, their results sometimes disagree.

Since I know my code is doing full-width search, the problem must be with 
how I am doing the movefilter.

It was my understanding that if the initial call to FindBestMove had a 
move filter which kept all candidates, this would create a full-width 
search at depth=1 or depth=3 (gnu0-ply or gnu1-ply). With depth=1 this is 
obvious. At depth=3, I thought move nodes before the horizon would perform 
a depth=1 search to find the best candidate, which was then searched 
"fully" and then its value returned. Since the move nodes in a depth=3 
search are just before the horizon and they are searching a single ply to 
determine the best successor, this should be fine.

So what am I doing wrong?

-- 
Some people, when confronted with a problem, think "I know, I'll use 
regular expressions."  Now they have two problems.
  --Jamie Zawinski, in comp.lang.emacs