bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Joern Thyssen
Subject: Re: [Bug-gnubg] [Q] Full-width search
Date: Fri, 12 Dec 2003 09:25:25 +0000
User-agent: Mutt/1.4.1i

On Thu, Dec 11, 2003 at 04:59:34PM -0700, Thomas Hauk wrote
> 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 } } 
> };

Yes, this should give maximal search. 

> 
> 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?

The move filter looks fine. Can you send some examples where
FindBestMove disagree with your code?

In fact, you can check this yourself if you are able to setup the
position in the GUI. Press "hint", mark all moves, and press "1" (for
depth 3).

Jørn

Attachment: pgpmJp_vnBNHl.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]