I started writing my first go program I think in 1981 or '82. It was
influence based and I threw it away and started over with something that did
tactical search instead, in '82 or '83. I think its first tournament was in
1984, and I started selling it in 1986 (as Cosmos). It was renamed Many
Fa
> It's a new area and the systems are very complicated. What kind of
> theory are you after, and what would you like it to tell you?
Currently, what seems to happen is (no offense intended, and please
correct me if my incomplete view is wildly off!-):
- have an idea for a great improvement (one t
> You'll probably enjoy an article I wrote last year on this theme:
> http://dcook.org/compgo/article_the_problem_with_random_playouts.html
Hi Darren,
yes, I particularly liked that you explained what you were trying to
show and how you think your data supports this - one might agree or
disagree
When bad playouts recommend bad moves to the tree, it isn't quite as
bad as it seems because the fact that we focus on these moves helps
clarify them and we see them for what they are.
Of course that is not an argument against using high quality playouts.
I believe there is clearly a time/quali
Darren Cook wrote:
Of course MCTS, within a few hundred playouts, will discover white
shouldn't tenuki . But when this position is found 20 ply deep in the
tree it will only receive a few playouts, so bad information is being
passed up the tree. The point of the whole article was that these
unbal
>> http://dcook.org/compgo/article_the_problem_with_random_playouts.html
> I admit not reading this thread carefully enough to understand what the
> argument is about. So I just contribute with following statement:
>
> Positions like this are very easy to handle for MCTS based programs that
> uses
If white plays first from this position, Valkyria plays J2 which wins
100% of time.
If black plays first, black has initially sometimes 5% chance to win
for the best move but the chance goes down to 1% rather quickly.
I admit not reading this thread carefully enough to understand what
the
> Darren Cook wrote:
> > What do your program's playouts think when presented with the board
> > position in the article? This is a terminal position, both players have
> > passed, a comfortable white win, yet pure random playouts think black
> > will win more often.
> >
> >>> http://dcook.org/c
> From: Gunnar Farnebäck <[EMAIL PROTECTED]>
>
> Darren Cook wrote:
> > What do your program's playouts think when presented with the board
> > position in the article? This is a terminal position, both players have
> > passed, a comfortable white win, yet pure random playouts think black
> > wil
Darren Cook wrote:
What do your program's playouts think when presented with the board
position in the article? This is a terminal position, both players have
passed, a comfortable white win, yet pure random playouts think black
will win more often.
http://dcook.org/compgo/article_the_problem
Claus Reinke wrote:
>> Just out of curiosity, what did you expect from the playouts?
>
> Nothing in particular, really; at this point I'm just trying to
> build up an intuition about what I can or cannot expect from them.
> At first, I thought light playouts would not fully explore, but at
> least
that light
playouts are quite effective.
David
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:computer-go-
> [EMAIL PROTECTED] On Behalf Of Darren Cook
> Sent: Tuesday, October 14, 2008 7:42 PM
> To: computer-go
> Subject: Re: [computer-go] Go/Games with modifi
> Many Faces uses quite light playouts, and is 1 kyu 19x19 on KGS when run on
> 32 cores. So I think you can make a fairly strong program using light
> playouts. My playouts are certainly far lighter than Crazystone or Mogo.
Hi David,
"quite light" is a bit vague, and I got the impression you we
TECTED] [mailto:computer-go-
> [EMAIL PROTECTED] On Behalf Of Darren Cook
> Sent: Tuesday, October 14, 2008 5:17 PM
> To: computer-go
> Subject: Re: [computer-go] Go/Games with modified scores
>
> > Second, having now looked at some more random "light playouts"
> > ...
> >
Hi Claus,
> In sum, there doesn't seem to be a good basis for understanding playouts
> and their optimisation, other than by trial and error. Those who've been
> through some cycles of trial-and-error probably have at least a vague
> intuition of what works and what doesn't (or didn't when they la
> Second, having now looked at some more random "light playouts"
> ...
> an empty board, but if you look at move 300 and try to compare the
> strings and eyes that almost make it vs those that do, it drives home
> the message that the individual run is nearly meaningless,...
Hi Claus,
You'll proba
> Just out of curiosity, what did you expect from the playouts?
Nothing in particular, really; at this point I'm just trying to build up an
intuition
about what I can or cannot expect from them. At first, I thought light playouts
would not fully explore, but at least randomly cover all possible g
Claus Reinke wrote:
> Second, having now looked at some more random "light playouts"
> (just instrument your engine to output sgf before starting the next run),
> I feel that the name is highly misleading. These simulation runs have
> very little in common with actual play, eg, in a 19x19 run from
On Tue, 2008-10-14 at 15:27 -0200, Mark Boon wrote:
> On 14-okt-08, at 14:02, Don Dailey wrote:
> > Mark Boon went off on a tangent here when he talked about a "swath of
> > information available" and his imaginative discourse on how it
> > might be
> > used. He really launched into a different
On 14-okt-08, at 14:02, Don Dailey wrote:
Mark Boon went off on a tangent here when he talked about a "swath of
information available" and his imaginative discourse on how it
might be
used. He really launched into a different discussion and I don't
disagree with him. It was just something
On Tue, 2008-10-14 at 16:22 +0100, Claus Reinke wrote:
> > .. I think people (me included) feel that replacing a whole swath
> > of relevant information by a single number points to potentially some
> > serious inefficiency and loss of information. The fact that nobody
> > has found how to make use
On Tue, 2008-10-14 at 16:22 +0100, Claus Reinke wrote:
> > .. I think people (me included) feel that replacing a whole swath
> > of relevant information by a single number points to potentially some
> > serious inefficiency and loss of information. The fact that nobody
> > has found how to make use
> .. I think people (me included) feel that replacing a whole swath
> of relevant information by a single number points to potentially some
> serious inefficiency and loss of information. The fact that nobody
> has found how to make use of the excess of information is no proof of
> course that it c
On 11-okt-08, at 20:32, Don Dailey wrote:
I believe there have been many attempts to make this work. These
attempts are based on the intuition that the margin approach should be
better even though it is clearly inferior. So in my opinion they
start
with a wrong premise. And this wrong pr
On Sat, 2008-10-11 at 23:49 +0100, Raymond Wold wrote:
> Don Dailey wrote:
> > Are you speculating that if enough play-outs are done, the idea might
> > prove to be superior?I never actually considered that. So perhaps
> > with 5000 playouts using the win/loss score wins, but at 50,000 usin
Don Dailey wrote:
Are you speculating that if enough play-outs are done, the idea might
prove to be superior?I never actually considered that. So perhaps
with 5000 playouts using the win/loss score wins, but at 50,000 using
the margin might be better? This is easy to test with simple MC
On Sat, 2008-10-11 at 22:33 +0100, Raymond Wold wrote:
> Ingo Althöfer wrote:
> > During the last few days I have been meditating a lot about
> > the questiion whether taking into account the margin of
> > win into MCTS (UCT) may help or hurt.
You are not alone! I think most of us have looked in
Ingo Althöfer wrote:
During the last few days I have been meditating a lot about
the questiion whether taking into account the margin of
win into MCTS (UCT) may help or hurt.
I do not have a go program by my own, so for the moment
I have to believe what programmers are saying, namely
that "MCTS
During the last few days I have been meditating a lot about
the questiion whether taking into account the margin of
win into MCTS (UCT) may help or hurt.
I do not have a go program by my own, so for the moment
I have to believe what programmers are saying, namely
that "MCTS with margin of win as a
29 matches
Mail list logo
