I did this, stopping search if other moves mathematically couldn't
catch up. I found that the savings in percentage of total nodes
depended on how many playouts the program did. The larger the number
of playouts, the larger the savings. I also made a rule where after a
certain percentage of the tot
Subject: Re: [computer-go] Tweak to MCTS selection criterion
The policy is only risk free on a per-move basis. For the game as a whole,
using more time on one move means there will be less time available for later
moves. Back when I tested this rule in my own program, I didn't see any
signif
illis
-Original Message-
From: Brian Sheppard
To: computer-go@computer-go.org
Sent: Sun, 7 Jun 2009 6:05 pm
Subject: [computer-go] Tweak to MCTS selection criterion
> check if overtaking the leading move is mathematically impossible?
Yes. Pebbles does this.
Please note that the discussion ha
> It's interesting with UCT because of the interplay between the time
> management algorithm and the exploration parameter. Suppose you are
> early in the game, and your time management algorithm says you should be
> spending 10 seconds on a move. After six seconds, because your parameter
> is skew
On Sun, Jun 7, 2009 at 6:05 PM, Brian Sheppard wrote:
> > check if overtaking the leading move is mathematically impossible?
>
> Yes. Pebbles does this.
>
> Please note that the discussion has veered into time control policy,
> which is not the subject of the original post.
The original post di
> check if overtaking the leading move is mathematically impossible?
Yes. Pebbles does this.
Please note that the discussion has veered into time control policy,
which is not the subject of the original post.
The original post discusses move selection policy: when your program
stops, for whateve
If the
> > move is a result of just a few lucky playouts, then it will quickly be
> > revealed and you can still stop early.
> >
> > - Don
> >
> >
> >
> >
> >
> > - Dave Hillis
> >
> >
> >
> > -Origin
2009/6/6
> > I had the early stop rule and didn't know if anyone else had thought of
> it. But I never considered the pebbles rule,
> > which somewhat conflicts with the early stop rule. But as I layed out
> above I think you could do both.
>
> > This is probably one of those things that adds
I think all principles I use in the time management for Valkyria came
up in this thread more or less.
1) Valkyria selects move that has been searched the most.
2) It is given a base time for example 20 seconds early on on 9x9 CGOS
3) The base time is adjusted down if the program is winning big.
it will quickly be
revealed and you can still stop early.
- Don
- Dave Hillis
-Original Message-
From: Michael Williams mailto:michaelwilliam...@gmail.com>>
To: computer-go mailto:computer-go@computer-go.org>>
Sent: Sat, 6 Jun 2009 5:07 pm
> I had the early stop rule and didn't know if anyone else had thought of it.??
> But I never considered the pebbles rule,
> which somewhat conflicts with the early stop rule.?? But as I layed out above
> I think you could do both.
> This is probably one of those things that adds a little bit b
2009/6/6
> > -Original Message-
> > From: Don Dailey
> > To: computer-go
> > Sent: Sat, 6 Jun 2009 5:59 pm
> > Subject: Re: [computer-go] Tweak to MCTS selection criterion
>
> > 2009/6/6
>
>> > I think this is one of those design deci
> -Original Message-
> From: Don Dailey
> To: computer-go
> Sent: Sat, 6 Jun 2009 5:59 pm
> Subject: Re: [computer-go] Tweak to MCTS selection criterion
> 2009/6/6
> I think this is?one of those?design decisions that nobody takes on faith. We
> all wind up tes
ll quickly be revealed and you can still stop early.
- Don
> - Dave Hillis
>
>
>
> -Original Message-
> From: Michael Williams
> To: computer-go
> Sent: Sat, 6 Jun 2009 5:07 pm
> Subject: Re: [computer-go] Tweak to MCTS selection criterion
>
> Another str
allows the search to be stopped early. It can save a lot of time for forced
moves.
- Dave Hillis
-Original Message-
From: Michael Williams
To: computer-go
Sent: Sat, 6 Jun 2009 5:07 pm
Subject: Re: [computer-go] Tweak to MCTS selection criterion
Another strategy to be considered is to
On Sat, Jun 6, 2009 at 5:07 PM, Michael Williams <
michaelwilliam...@gmail.com> wrote:
> Another strategy to be considered is to not allow the thinking to cease
> until the maximum win rate and the maximum visit count agree on the same
> move. Obviously this requires some extra code to make sure y
Another strategy to be considered is to not allow the thinking to cease until the maximum win rate and the maximum visit count agree on the same move.
Obviously this requires some extra code to make sure you don't lose on time, etc.
Brian Sheppard wrote:
When a UCT search is completed, the usua
When a UCT search is completed, the usual selection criterion is
"choose the move that has the most trials." This is more stable
than choosing the move that has the highest percentage of wins,
since it is possible to have an unreliably high percentage if the
number of trials is small.
I have a sma
18 matches
Mail list logo
