Here is a way to make a slightly smarter (and much prettier) random
player. It is good for MC playout games too. For the first 20 or so plys,
restrict the board spaces that can be filled to those commonly seen in human
games.
Below is a table for 9x9 games (trained from SGF
This seems clean and reasonable to me. (Or you could just as easily have
the server do the adjustment and set Komi to 3.5; that would also be consistent
with TT rules). If my bot sees 2 black moves in a row, it can figure out it's
in a handicap game.
A bigger question to me is, how
AntIgo does exactly this and I still get complaints. I think this is
perfect manners on CGOS (none of the other bots have objected) but poor manners
on KGS. It's less annoying, to be sure, but still annoying.
People can get ticked off when it resigns too. They might want to see
It's good that you posted this. I liked the paper. (And I understand
proof number search a little better after reading it too.) But it describes the
epsilon trick in terms of transposition tables which I don't use. I didn't see
how it would apply to a broader range of applications or,
Here is another MC speedup trick. I think it may have been mentioned
before but it's worth repeating.
This applies to the case where my program is going to run N playout games
and then select the most visited node as its move for that turn (which will not
always be the node with the
The answer is yes. Many computer programs (including my own) can beat me
easily on today's hardware and I am, indeed, a human.
Glad I could clear that up for you. ;-)
- Dave Hillis
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Tue,
Handicap stones.
- Dave Hillis
-Original Message-
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: computer-go@computer-go.org
Sent: Sat, 27 Jan 2007 8:07 AM
Subject: Re: [computer-go] early results
On Fri, 2007-01-26 at 20:18 -0800, David Doshay wrote:
I would highly recommend
I agree with what you say here and I'll try to make my point better.
First, my limited experience working with Monte-Carlo simulations involved
photons traveling through scattering media. The sequences of moves described in
the Mogo paper are pleasantly reminiscent of this.
I did
-Original Message-
From: [EMAIL PROTECTED]
...
The earliest MC engines were extremely simple and easily described. It
seems inevitable that someone new to the field will seize on this
description, and then combine it with the success of current Monte-Carlo
engines, leading to
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Wed, 7 Feb 2007 5:34 AM
Subject: [computer-go] MC approach (was: Monte Carlo (MC) vs Quasi-Monte Carlo
(QMC))
On Wed, Feb 07, 2007 at 12:06:40PM +0200, Tapani Raiko wrote:
Let my try again using the
I should have mentioned that I have only tested on 9x9. For larger boards,
I don't know.
- Dave Hillis
`
Intuitively, it seems like this should work. You only give the winning
margin a small weight, or only use it to break ties, or only apply it after the
game
The tests that involved factoring in the margin of victory while the game
was still in play, used pure random playouts (or relatively close to it.)
Later, I did some tests with esthetics as a goal in itself, and for these, I
used what I call a heavy playout. I doubt that the playout type
It's a *weighted* average of all moves. UCT tree search doesn't explore
bad moves as often as good ones, so they don't contribute as much to the
estimation of the worth of a node.
- Dave Hillis
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent:
Sounds like a bug. The randomness of the moves should make infinite loops
fairly rare (though not impossible) and your average game length should be
close to 100 moves.
It's a good idea to step through playout games one move at a time. Also to
run a lot of games, stopping to
Last one, I promise :) If your eye rule doesn't allow the defender to fill
in behind the ko stone (the one in atari), that can set up infinite loop triple
kos.
- Dave Hillis
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Thu, 8 Feb 2007 12:19
Looks like a fractal to me. Easy to test: just calculate the fractal
dimension (using e.g. the box counting method) over a range of board sizes. If
you find a fractal (or mult-fractal) relationship - and maybe compare pure MC
against one of the variants - you could probably get a decent
I've started playing with this too. It may be a missing piece to a puzzle
that interests me. I doubt anyone with a background in fractals could look at a
go board and not see something there.
I'm comparing light MC playouts (pure random, non-eyefilling) and
heavy (it tries to find a
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Fri, 23 Feb 2007 12:03 AM
Subject: Re: [computer-go] Big board, ++physics
Your analogy with physics encourage me to share other physical analogies.
1/ Cooling the simulation could be done by controlling the
But note that I said passing was disallowed so he would have no choice. In
a percolation simulation, you can have quasi-stable regions. To follow the
analogy for go, you could have situations where each color was trading small
regions back and forth, like trading kos or 2 for 1 trades. Even
Chaos theory has been said to suffer from eerily reminiscent syndrome:
you do some tests, generate some graphical results, the significance of it is
uncertain, but the images are so eerily reminiscent of something or other
So, in that fine tradition:, I'm temporarily posting some
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Wed, 28 Feb 2007 11:09 PM
Subject: [computer-go] Re: Big board
This seems to have gotten stuck in various email delays, so I am resending.
Sorry in advance if you get 2, but I did not see it get through.
I think it would make the most sense to make the measurements at the stage
of the game where a human expert would find it easiest to distinguish them by
looking at the board (After the first 30 moves?) Waiting till the end probably
isn't ideal, although it was a perfectly good place to
I think you could run MC playout games in an FPGA, including pattern
matching and whatnot. Mind you, my digital hardware design days were very long
ago. An MC playout game is a go evaluation function, albeit a noisy one.
- Dave Hillis
-Original Message-
From: [EMAIL PROTECTED]
Here are some numbers from AntIgo. Alvaro's suggestion seems like a good
one-we're almost there anyway. (I'm not in favor of permitting suicide, but
that's a minor detail.)
I lose a lot more time in UCT than Don does. I think his data structures
are nicer than mine. I haven't tried
I don't play go, so apply whatever discount seems appropriate.
Go is a zero sum game - except when humans are involved. People are clearly
dealing with a multi-criteria optimization task. Losses can be moral victories;
wins can be humiliating; style and tradition matter. Virtually every KGS
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Tue, 10 Apr 2007 2:43 PM
Subject: Re: [computer-go] The physics of Go playing strength.
On Tue, 10 Apr 2007, Christoph Birk wrote:
On Tue, 10 Apr 2007, Hideki Kato wrote:
According to the report on MoGo
I think I remember that post - with the same level of clarity unfortunately.
I use UCT for life and death. It comes into play at the scoring phase and in
polite games where the engine needs to know when it can pass. (Knowing the
score doesn't necessarily mean one knows the status of every
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Mon, 16 Apr 2007 5:26 AM
Subject: Re: [computer-go] The dominance of search (Suzie v. GnuGo)
[EMAIL PROTECTED] wrote:
I also find this kind of information very interesting and useful. Now I
have a
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Wed, 16 May 2007 5:08 AM
Subject: [computer-go] Idea for a strategy
http://www.regdeveloper.co.uk/2007/05/15/google_translation/page1.html
This is an article on statistical approaches to machine
Very interesting paper: many ideas for me to study. And thanks for giving us an
early look at it.
I'll make one suggestion: in the final version, it deserves some better
salesmanship in the results section. I've read through too many papers, only to
reach the results section at the end and
-Original Message-
From: Eduardo Sabbatella [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wed, 23 May 2007 8:20 am
Subject: Re: [computer-go] KO in Hashtable-UCT?
game biases the results. strongly.
In which direction?
I was comparing my engine with GNUGO 3.6
For the typical person in the U.S. the thing you prune would naturally be a
bush. Unpruning something brings up a humorous mental picture of vainly
trying to stick the clipped branches back on.
I should mention that while the idea is not new (and I've tried it
unsuccessfully myself in the
On Sun, 2007-05-27 at 13:21 -0400, Jason House wrote:
As I get into the home stretch of rewriting the core of my bot, I want
to add a monte carlo player. I've realized that picking a random move
to play is non-trivial since it's such a key element in playout speed.
An array of
My program tends to amplify noise fluctuations. If it's presented with
several equally good moves, it will pick winners and losers early on. It looks
bad. On the other hand, tweaking it up to win more games against Gnugo and on
CGOS, has made it *more* prone to do this. That is my
These are very interesting results. Thanks for doing all this work.
- Dave Hillis
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Mon, 25 Jun 2007 12:34 pm
Subject: [computer-go] scalability study - final results
Someone
Darren Cook wrote:?
I've been toying with the idea of having a set of playout algorithms and?
allowing black and white to choose different algorithms in that playout.?
(The idea came from trying to think how I could apply genetic?
algorithms to UCT playouts.)?
?
Here's how it would work.
If I took a set of game positions, generated by flipping a coin, and
generated a histogram of
x = black_stones - white_stones
I would expect to see the distribution of x looking like a nice Gaussian,
centered at zero. If I looked at positions generated by playing out moves, I
would
-Original Message-
From: Darren Cook [EMAIL PROTECTED]
...
P.S. There is also rec.games.go, but I think people only post there when
they want to argue about something. (Disclaimer: I've not followed
rec.games.go in about 5 years, I suppose it may have mellowed since.)
I have a set of 3x3 patterns trained on a subset of the?~20K games in the NNGS
file that's floating about. I use them in my heavy MC playouts and also for
move prioritization in progressive widening. I think they are very useful, up
to a point.
- Dave Hillis
I neglected the rather important detail that these patterns are trained on 9x9
games. Training on 19x19 games produces different scores than these. I've tried
it both ways (it's much easier to get a large set of 19x19 games for training)
and this set is the one I now use for both 9x9 and 19x19.
Sylvain,
There is nothing to apologize for.
Writing to stderr is fine.
Putting the .dll in the same directory is fine.
Mogo does work from the command line.
No error message.
I can recreate the symptoms with my own engine by adding an
extraneous?printf.
fprintf(stderr, does not cause
Hello Giles,
I downloaded the latest version of Drago (which includes the LibKombilo.dll
file that someone mentioned), copied in your patch, and played Mogo for a few
moves. It seems to work OK. YAY!
I'll mention this here, since others might encounter it. There is a small race
condition
-Original Message-
From: Cenny Wenner [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wed, 19 Sep 2007 11:31 am
Subject: Re: [computer-go] Re: Most common 3x3 patterns
On 9/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I neglected the rather important
-Original Message-
From: Rémi Coulom [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thu, 20 Sep 2007 10:22 am
Subject: Re: [computer-go] Crazystone patterns
Chris Fant a écrit :
Does this mean that you need to calculate the Bradley-Terry
probability for
That should do nicely. Thanks!
-Original Message-
From: Álvaro Begué [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thu, 20 Sep 2007 10:31 pm
Subject: Re: [computer-go] Crazystone patterns
Remi keeps a number that is the sum of all the probabilities (I'll
all them
I'm going to echo Cenny's comment. Small samples like this can be very
misleading. For this kind of test, I usually give each algorithm 5000 playouts
per move and let them play 1000 games on my computer. It takes about a day and
a half.
- Dave Hillis
-Original Message-
From: Cenny
Good information. Thanks.
- Dave Hillis
-Original Message-
From: Jacques Basaldúa [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Fri, 21 Sep 2007 7:44 am
Subject: [computer-go] Random move selection (was) Crazystone patterns
Dave Hillis, wrote:
Suppose I can generate
If the 19x19 CGOS is going to be retired due to lack of interest, I wonder if
there would be interest in trying out an ultra-blitz version for a while: games
as fast as the com. links would permit.?(Game storage would be an issue. Maybe
they just wouldn't get stored.) It could be a limited time
-Original Message-
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Mon, 24 Sep 2007 10:22 am
Subject: Re: [computer-go] ego110_allfirst on CGOS
I just looked at 133684.? ego110_allfirst took all the way until move 18 to
play a move above the
When I try AMAF (including RAVE) my program always wants to make early
moves on the first and second lines. I've come to look at it as a
hallmark of the algorithm.
To combat this, I use a table with a move number for each position on
the board. The program is not allowed to put
LOLCODE
http://lolcode.com/
The future of programing.
-?Dave Hillis
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Mon, 1 Oct 2007 3:45 pm
Subject: Re: [computer-go] Python bindings for libego?
-BEGIN PGP SIGNED MESSAGE-
Couldn't there just be two servers? There were multiple volunteers. A server
with long games might draw more viewers but fewer participants. Shorter games
would be more helpful for those of us working on weak 19x19 programs that other
people are less interested in anyway.
- Dave Hillis
Hi Don,
Sounds like a good idea.
- Dave Hillis
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Sun, 28 Oct 2007 5:05 pm
Subject: Re: [computer-go] 19x19 CGOS
Hi Dave,
Two servers is easy, but 1 server is better.The plan is
G'day guys,
I'm involved in the development of a very powerful and flexible grid
software, which we plan to release in January. It is all java based.
http://www-nereus.physics.ox.ac.uk/ (bear in mind you can't download
it yet and the website is out of date)
One of the things I'd like to do
-Original Message-
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thu, 6 Dec 2007 4:44 pm
Subject: Re: [computer-go] Re: evaluating monte carlo results
On Dec 6, 2007 4:22 PM, [EMAIL PROTECTED] wrote:
My program is riddled with code to
I'd like to start a more specific discussion about ways to combine tactical
information with MC-UCT. Here's the scenario.
It's the bot's turn and, prior to starting any playouts, it runs a tactical
analyzer (for want of a better name) that labels each string as unconditionally
alive,
That's a strong program, and interesting?information.?For clarity, I assume
that you mean something like Benson's algorithm, while my intended meaning was
alive assuming perfect play. Both are relevant, we just need to keep them
sorted out.
- Dave Hillis
-Original Message-
From: John
-Original Message-
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thu, 13 Dec 2007 3:20 pm
Subject: Re: [computer-go] MC-UCT and tactical information
On Dec 13, 2007 2:17 PM, [EMAIL PROTECTED] wrote:
I'd like to start a more specific
Impasse: noun,
1. There is no argument so elegant and compelling that it will prove the
negative that making UCT greedier could not possibly lead to more won games.
2. Everyone who has tried it one way, will have tried some variations. It's not
as if it takes a?lot of code. No one has reported
I got a smile out of that.
_ Dave Hillis
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thu, 13 Dec 2007 8:52 pm
Subject: Re: [computer-go] low-hanging fruit - yose
[EMAIL PROTECTED] wrote:
Impasse: noun,
1. There is no
-Original Message-
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thu, 13 Dec 2007 6:30 pm
Subject: Re: [computer-go] MC-UCT and tactical information
...
Change for the better seems to imply only a one-sided analysis.? I would
imagine
-Original Message-
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Fri, 14 Dec 2007 2:23 pm
Subject: Re: [computer-go] MC-UCT and tactical information
So, what tactical information should be calculated, how should it be used, and
yes how
Depending on your rule set, you might not want to use stones captured.
I use more-or-less Tromp-Taylor rules; same as CGOS.
- Some form of mercy rule: if whiteStonesOnBoard == 0, I know who won. Early in
the game, blowouts are *very* comon.
- I maintain an array of empty spaces. At scoring
Maybe some day computer go will reach the same level of maturity as computer
chess and we will need safeguards against all sorts of churlishness. But so
far, CGOS is very civilized.
I favor encouraging people to make their bots resign, but not penalizing those
who don't. The MC programs are
I've mentioned this before, but hopefully not recently enough to make this
annoying. Computer go people and corewars people overlap somewhat.
Intransitivity is extremely important for corewars, making?corewars a good
domain to study it.
Here is an example of a nice graphical way to visualize
That sounds like it would be weaker than Wally. You could just use Wally,
though, with today's hardware,?I doubt many would find it a challenging
opponent.
- Dave Hillis
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Tue, 8 Jan
Down the road, when I'm ready for it, I'd like for there still to be a 19x19
CGOS much like the one now. But, in the mean time, the current 19x19 CGOS is of
no use at all in helping me get there. Ten minutes per side or faster would be
ideal. Don's plan for 2 speeds on the same server sounds
Thanks Alain. I see I had given up on the paper too soon.
- Dave Hillis
-Original Message-
From: Alain Baeckeroot [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Sun, 13 Jan 2008 11:51 am
Subject: Re: [computer-go] Sylvain Gelly thesis in english
Le dimanche 13
Single stone suicide is much easier to test for. :)
- Dave Hillis
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Tue, 15 Jan 2008 12:11 pm
Subject: Re: [computer-go] On average how many board updates/sec can top Go
programs do
Um, by easier I mean faster. Also, I think single point suicide is more likely
to lead to infinite loops, depending on your eye-filling rule.
- Dave Hillis
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Tue, 15 Jan 2008 12:16 pm
Subject: Re:
Another possible reason could be for SIMD (vector) parallel processing. Years
ago, I was a real-time image processing guy. Some time back, I did a
back-of-the-envelope design for doing?light playouts on multiple go boards at
once, on a dedicated parallel processing card. It meant?tiling all
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
...
For instance since is legal to resign,? we could randomly include this
possibility in the play-outs, but it would not increase the resolving
power of the play-outs.
Hmm... It would speed things up, though. And if you made
From: Don Dailey [EMAIL PROTECTED]
...
Rémi Coulom wrote:
...
Instead of playing UCT bot vs UCT bot, I am thinking about running a
scaling experiment against humans on KGS. I'll probably start with 2k,
8k, 16k, and 32k playouts.
That would be a great experiment. There is only 1
A few trick moves in a row can cause problems. But the cases where I am most
likely to be watching my bot's play through my fingers are when there is an
obvious (to a 20 Kyu like me) situation but it's some plys in the future. (Or
it can be pushed into the future!)
A case of seki is easy for
I'm going to call this the procrastination effect. MY claim is that, when
MC-UCT encounters a critical life and death board situation that its playout
policy consistently gets wrong, the search will naturally tend to skew the tree
so that relevant moves continue to be made during the playouts.
Right you are. Silly me.
-Original Message-
From: Álvaro Begué [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thu, 31 Jan 2008 3:06 pm
Subject: Re: [computer-go] not Go knowledge and UCT
On Jan 31, 2008 2:59 PM, [EMAIL PROTECTED] wrote:
I'm going to call this
That's an interesting story. I just wish I hadn't precipitated it by sharing my
blinding flash of the obvious with the whole list. You are correct, of course.
I got so focused on something that I didn't see the forest for the trees.
- Dave Hillis
-Original Message-
From: Don Dailey
Lots of good information here. In particular, I notice that my program has the
explore needless captures in progressive widening weakness described below. My
thanks to Magnus (and Remi, of course) for pointing it out. I'll fix that and
then, I guess, I'll have to revisit the issue of reading
That's very interesting. RAVE, as described in the Mogo paper, incorporated
some priors and gave a progressive widening effect. Have you looked at
progressive widening with and without RAVE? Could you provide some details
about how you made it work?
-Dave Hillis
-Original Message-
Hi Florian,
?
That sounds like an interesting project. I've looked at this a little. If
it were me, I would start by implementing the simplest possible MC playouts in
gpgpu,?as efficiently as possible, before looking at adding things like
patterns.?
I also heartily encourage you
? -Original Message-
? From: Don Dailey [EMAIL PROTECTED]
? To: computer-go computer-go@computer-go.org
? Sent: Mon, 18 Feb 2008 1:45 pm
? Subject: Re: [computer-go] Re: computer-go Digest, Vol 43, Issue 8
...I have seen widely held beliefs be proven wrong before
(the earth is
An alternative (also maddening to tune) is to make the playout strength
asymmetrical. For a high handicap game, making the playout rules for black
stones lighter (more random) can make the bot play serious moves where
otherwise it would see every move as having the same outcome. The implicit
It's almost always better to just write your own. Or you might want to consider
using a particle swarm optimizer instead.
http://www particleswarm.info/Standard_PSO_2006.c?has source code I found
useful.
http://www.particleswarm.info/Programs.html?has lots of other implementations
to choose
Don,
You may, very well, turn out to be right in the end, but I think you are
getting ahead of the data here. And it isn't at all clear to me to how
meaningfully we can compare strength of playouts with strength of alpha-beta
evaluators.
This continues to be a very interesting study
-Original Message-
From: Magnus Persson [EMAIL PROTECTED]
. ..?
A side note. Is it only me who are a little annoyed when strong programs play
with names that are impossible(for examlple
test-81725) to understand? Do not forget to add an entry on sensei at
Hello,
3) What sort of algorithm is used to match patterns once you have mined them
from some data source?
There are relatively few possible 3x3 patterns, so it is easy to make a look up
table with an entry for every possible pattern.
For larger patterns, it's more complicated. Mined
For those currently coding this up, I think the most important thing about this
playout algorithm is that it is *temporary*. You will almost certainly
be?replacing it with something different and better just a little bit down the
road.
Creating an MC-UCT bot has a well worn path and its kind
-Original Message-
From: Jacques Basaldúa [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Wed, 14 May 2008 6:38 am
Subject: Re: [computer-go] 10k UCT bots
Don Dailey wrote:
[EMAIL PROTECTED] wrote:
For those currently coding this up, I think the most important
I? use proximity in the heavy playouts themselves. I think most (all?)?people
do this.?I have a precalculated table with the 3x3 and 5x5 neighbors for every
position on the board.?
- Dave Hillis
-Original Message-
From: Jason House [EMAIL PROTECTED]
To: computer-go
I've tried both MoGo and CrazyStone style playouts. I find MoGo style playouts
easier to work with. YMMV.
My MoGo style heavy playouts are about 4 times slower than my light playouts.
- Dave Hillis
-Original Message-
From: Jason House [EMAIL PROTECTED]
To: computer-go
The people with stronger programs and more full-board experience will be better
positioned to comment on this. I'll say that the two styles both need a lot of
tweaking, making it hard to establish a fair test between them.
It's good to be able to match a 3x3 pattern very quickly. Since there
Something that has worked well in other games would be to change the third CGOS
every month. Each month, the parameters would be announced and the CGOS started
empty except for the anchor(s). At the end of the month, the bot at the
top?would be?the winner. That would allow us to experiment with
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Mon, 11 Aug 2008 11:09 pm
Subject: Re: [computer-go] Re: What's happening at the European Go Congress?
On Tue, 2008-08-12 at 11:50 +0900, Darren Cook wrote:
Also, if you are
Yes, I tried heavy playouts for N plys, then switching to light.?It didn't
really speed things up all that much but it weakened my bot quite a bit, on a
per playout basis, resulting in a clear net loss.
?
I tried ladder reading for the first N plys, then no ladder reading. The
results were
Raises hand. Chinese rules version for 9x9 and 13x13 would be quite helpful if
that's what you are offering. Different komi would be fine.
- Dave Hillis
-Original Message-
From: Darren Cook [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Sat, 6 Sep 2008 10:33 pm
There is a discussion at godiscussions
http://www.godiscussions.com/forum/showthread.php?t=7154
?The sgf's for the two games played are on page 2
Dave Hillis
-Original Message-
From: mingwu [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; computer-go computer-go@computer-go.org
Sent: Sun, 21 Sep
I agree with much of what you say (to the degree that anyone needs to agree
with questions).
The discussions on this list dealing with ownership maps, RAVE and AMAF have
to do with using additional information from the playouts.
Playouts can't be unbiased. Picking a move with uniform
It depends on your definition of real-time. A play-by-email target, such as the
Dragon Go Server is pretty flexible about scheduling moves. The project could
do what many people do and play several games in parallel. Each participating
computer would get a slice of multiple games to process in
Going from memory, that all looks right. (We've been calling it a pseudo
eye.)
There's no need to do this, but for what it's worth, if you make a histogram of
the scores,
- you should only get odd scores
- there should be big spikes at the tails (+/- 81)
- there should be a Gaussian-looking
I checked my notes. For Light playouts
---
average game length 111 (including final 2 passes)
not counting passes 107
---
When these numbers match, it's a pretty strong sign that the implementation is
correct (particularly the eye rule).
- Dave Hillis
-Original Message-
From: Jason
1 - 100 of 142 matches
Mail list logo
