Yes. That's why MCTS prefers the center. Sometimes the playouts let an
invasion work, so corner territory is not evaluated as being as secure as it
should be. It seems easier for MCTS to kill groups in the center in the
playouts.
David
-Original Message-
From:
Hi Jouni,
oh, Zen is drifting more than I expect, when old games are dropping. It did
not look like getting into 6d when she played actively in November. I guess
that I already lost the bet.
indeed you lost the 5-Euro bet today: Zen's rating curve has climbed,
due to clever inactivity, above
On Sun, Jan 08, 2012 at 08:23:08PM -0800, steve uurtamo wrote:
even with the joseki libraries, MCTS prefers center?
Besides what David said, joseki libraries (and even elaborate pattern
libraries) have the major problem that it is tricky to get data on
deviations. Therefore, if your pattern sets
By the way, are we sure it is underestimation of the edges and corners ?
Rather than overestimation of the centre ?
I know those are equivalent for play itself, but the answer suggests
different tries for solution. In the first case, we want to make the bot
more aware that he will keep its
On Sun, Jan 8, 2012 at 7:22 PM, Stefan Kaitschick
stefan.kaitsch...@hamburg.de wrote:
scoring function:
The most successful scoring function sofar is the win/lose function.
Sigmoid functions and other schemes have been tried, but none have
surpassed or even equaled the simple step function.
Is it possible to train a pattern-based engine with known-bad moves, especially
common trick moves, to give it a leg up on this problem?
Terry McIntyre terrymcint...@yahoo.com
Unix/Linux Systems Administration
Taking time to do it right saves having to do it twice.
Just kicking out an idea: when you offer a handicap to a player, the
presumption is that he or she or it is significantly weaker than yourself.
Can that weakness be modeled in the playouts? A 5d player tends to know subtle
things about shape and joseki which a 1d player does not; tends to read
On Mon, Jan 9, 2012 at 2:01 PM, terry mcintyre terrymcint...@yahoo.comwrote:
Just kicking out an idea: when you offer a handicap to a player, the
presumption is that he or she or it is significantly weaker than yourself.
Can that weakness be modeled in the playouts? A 5d player tends to know
On Mon, Jan 9, 2012 at 8:01 AM, terry mcintyre terrymcint...@yahoo.comwrote:
Just kicking out an idea: when you offer a handicap to a player, the
presumption is that he or she or it is significantly weaker than yourself.
Can that weakness be modeled in the playouts? A 5d player tends to know
Hi,
On Mon, Jan 9, 2012 at 13:17, Don Dailey dailey@gmail.com wrote:
Summary:
I believe a more correct scoring function won't be based on how much you win
by OR how often you win but will incorporate some other more relevant
concept and it will be dynamic. And it will not matter if
A very insightful post, I enjoyed reading it and I think it does make some
sense.It's clear that a lot of energy is wasted on playouts when 99% of
them are ending with the same result.
Don
On Mon, Jan 9, 2012 at 10:26 AM, Vlad Dumitrescu vladd...@gmail.com wrote:
Hi,
On Mon, Jan 9, 2012
Remi,
There might be a very simple explanation for the sandbagger - what if it is
actually an account that is shared? In other words, it could easily be a man
around 45 years old playing occasionally on his device. And then allowing his
dad to use it thereby removing all of the noise of trying
On Mon, Jan 9, 2012 at 12:54 PM, Aja Huang ajahu...@gmail.com wrote:
It’s easy to detect “secure” territory by collecting the information of
ownership from the playouts.
I have always called this the ownership map for lack of a better term.
I have heard people refer to is as a futures map.
On Mon, Jan 9, 2012 at 1:16 PM, Stefan Kaitschick
stefan.kaitsch...@hamburg.de wrote:
That was not bothater.
A strong 6d razed many kgs 5ds(me included) with his account.
This is a case of importing rating points to the bot.
I didn't even think of that scenario. So you think he is pumping
On 01/09/2012 11:54 AM, Jim O'Flaherty, Jr. wrote:
Of course I am making this up. The point is that the assumption that
a single account is associated with exactly one human who is the same
human to play on that account. Additionally, there are those out
there in the human world who don't value
I guess your right. I didn't think it through.
You probably have to treat it as a subtree property like RAVE.
Otherwise possession averages out to much.
Global possession would be a reasonable seed before the next move though.
The proper weight function would probably shift with the game phase.
Yes, computer try the win the game, but right now MCTS have problems by
simply using winning rate in 19x19 Go. That’s why we are using “dynamic kom”,
which is collected/computed from average score”, to cure this problem. My
point is that using average score is maybe not enough. We might also
On Mon, Jan 9, 2012 at 1:30 PM, Jeff Nowakowski j...@dilacero.org wrote:
On 01/09/2012 11:54 AM, Jim O'Flaherty, Jr. wrote:
Of course I am making this up. The point is that the assumption that
a single account is associated with exactly one human who is the same
human to play on that
On Mon, Jan 9, 2012 at 7:26 AM, Vlad Dumitrescu vladd...@gmail.com wrote:
Hi,
On Mon, Jan 9, 2012 at 13:17, Don Dailey dailey@gmail.com wrote:
Summary:
I believe a more correct scoring function won't be based on how much you win
by OR how often you win but will incorporate some other
I like that idea - I'm not sure I've fully digested it's implications but
it does deliver more information that could be put to good use.
Don
On Mon, Jan 9, 2012 at 1:53 PM, Zach Wegner zweg...@gmail.com wrote:
On Mon, Jan 9, 2012 at 7:26 AM, Vlad Dumitrescu vladd...@gmail.com
wrote:
Hi,
Concerning _abusive_ players..
After some googling I finally found a log file from kgsgtp ( I haven't
had a bot online for years, thus googling! ). What I've been looking
for is if the name of your opponent is shown in the logs or output of
kgsgtp. It appears this may be the case:
FINER: Got
Interesting. I have observed a problem in the current dynamic komi scheme
especially when there is a big semeai/life-and-death:
Playout 1 B+0.5
Playout 2 B+0.5
Playout 3 B+0.5
Playout 4 B+0.5
Playout 5 B+0.5
Playout 6 B+0.5
Playout 7 B+0.5
Playout 8 B+0.5
Playout 9 B+0.5
I gather that the goal of keeping a histogram is to maximize the median
score. Do I have that right?
It wasn't obvious to me that this would work as a tree exploration policy.
Can you clarify? For example, what move should A explore to ensure that its
value converges to the largest median score?
Lets say there is a semeai and Black wins 6.5 points if it wins the semeai.
Otherwise White wins 3.5 points.
Playout 1B+6.5
Playout 2B+6.5
Playout 3B+6.5
Playout 4B+6.5
Playout 5B+6.5
Playout 6B+6.5
Playout 7B+6.5
Playout 8B+6.5
Playout 9B+6.5
Playout 10 W+3.5
I see the idea. Gather stats for the best go playing programs, put the
figures into CLOP. Hey presto! You now know exactly how many lines of
code the perfect Go playing program needs.
Seriously, when comparing source code sizes for different
implementations of the same thing, it's often helps
Hi,
This is probably very close to useless, but it might be fun in a geeky
kind of way :-) It might not be novel, either.
I ran some playout games without komi (with simple policies: capture
atari, escape atari, simple 3x3 patterns) and plotted the distribution
of scores. I thought that the top
I think the idea could be extended in lots of different ways too. For
example, you could keep territory maps for each final score (quantized
into some buckets as with the histogram, 2*board_size+1 is way too
much information...). That gives you the histogram for each
intersection, so it would
Hi,
I've observed some and found there are several peaks when the positions
are complicated, i.e., there are multiple semeais simultaneously, for
examples, on 19x19. Simple statistics may not work on such positions,
though I've not tried any.
Hideki
Vlad Dumitrescu:
28 matches
Mail list logo
