Rollout policy is a black art. Lots of trial and error. That said, you are on
the right path if you use the published papers as the starting point for your
own experiments.
Two board representation details are very important. If your board
representation has these capabilities then you can represent an astounding
amount of Go theory. In Pebbles, the following properties are incrementally
updated as part of the make-move operation:
- the number of liberties for any string
- the index of the 3x3 neighborhood of every point.
Best,
Brian
-----Original Message-----
From: Roel van Engelen <ich.bun...@gmail.com>
To: computer-go <computer-go@computer-go.org>
Sent: Tue, Jan 31, 2017 12:55 pm
Subject: Re: [Computer-go] AlphaGo rollout nakade patterns?
@Gian-Carlo Pascutto, thanks! but identifying the shapes is not the problem=)
@Brain Sheppard, Sorry it was not my goal to make you start guessing any
implementation details, somehow from your first explanation i got the
impression that you where familiar with it and i was wondering whether anybody
wrote something about it.
right now i am sticking to the paper as much as possible and reading, trying to
understand how others improve their rollouts. I hope that i will be able to
improve the rollouts at some point.
Roel
On 31 January 2017 at 17:21, Brian Sheppard via Computer-go
<computer-go@computer-go.org> wrote:
If a "diamond" pattern is centered on a 5x5 square, then you have 13 points.
The diagram below will give the idea.
__+__
_+++_
+++++
_+++_
__+__
At one bit per cell, this would be 8192 patterns, so this is why I am guessing
that this is the pattern set. (You would set one bit for each captured stone,
then look up in a table.)
I feel like I am engaging in a lot of guesswork regarding implementation
details. I want to emphasize that the implementation details are not
particularly important. The important point is that you can add this capability
("reply on the vital point after the capture of a nakade group, provided that
the opponent's surrounding stones have no additional eyes") to your rollout,
and the implementation should take less than 1% of total time. Any
implementation that achieves that goal will make a noticeable difference to
strength.
-----Original Message-----
From: Roel van Engelen <ich.bun...@gmail.com>
To: computer-go <computer-go@computer-go.org>
Sent: Tue, Jan 31, 2017 10:42 am
Subject: Re: [Computer-go] AlphaGo rollout nakade patterns?
@Brain Sheppard
Thanks that is a really useful explanation!
the way you state: "and therefore a 8192-sized pattern set will identify all
potential nakade." seems to indicate this is a known pattern set? could i find
some more information on it somewhere? also i was unable to find Pebbles, is it
open source?
@Robert Jasiek
what definitions/papers/publications are you referring to?
m.v.g. Roel
On 24 January 2017 at 12:57, Brian Sheppard via Computer-go
<computer-go@computer-go.org> wrote:
There are two issues: one is the shape and the other is the policy that the
search should follow.
Of course the vital point is a killing move whether or not a group was just
captured. So it is possible to detect such shapes on the board and then play
the vital point.
It is an entirely different thing to say when a rollout should look for such
features. Rollouts are complicated; playing the "best" play does not always
make your search engine stronger. Of course, there is a question of the time
required for analysis. And then there is the question of "balance".
"Balance" means that the rollout should play "equally well" for both sides,
with the goal that the terminal nodes of the rollout are accurate evaluations
of the leafs of the tree. If you incorporate all moves that punish tactical
errors then sometimes you can get unbalanced results because you do not have
rules that prevent tactical errors from happening.
A common rule for nakade is to only check after a group is captured. The point
is that the vital point is otherwise not motivated by any heuristics, whereas
most other moves in capturing races are suggested by local patterns. My
understanding of Alpha Go's policy is that they were only checking for nakade
after captures.
The "center of a group of three" rule is a separate issue. My recollection is
that this pattern should be checked after every move, and that was a discovery
by the Mogo team.
Note that there are often subtle differences for your program compared to the
published papers.
Best,
Brian
-----Original Message-----
From: Computer-go [mailto:computer-go-boun...@computer-go.org] On Behalf Of
Gian-Carlo Pascutto
Sent: Tuesday, January 24, 2017 3:05 AM
To: computer-go@computer-go.org
Subject: Re: [Computer-go] AlphaGo rollout nakade patterns?
On 23-01-17 20:10, Brian Sheppard via Computer-go wrote:
> only captures of up to 9 stones can be nakade.
I don't really understand this.
http://senseis.xmp.net/?StraightThree
Both constructing this shape and playing the vital point are not captures. How
can you detect the nakade (and play at a in time) if you only check captures?
--
GCP
_______________________________________________
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
_______________________________________________
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
_______________________________________________Computer-go mailing
listComputer-go@computer-go.orghttp://computer-go.org/mailman/listinfo/computer-go
_______________________________________________
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
_______________________________________________Computer-go mailing
listComputer-go@computer-go.orghttp://computer-go.org/mailman/listinfo/computer-go
_______________________________________________
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
