I ran some tests with 500k games each and came to this result:
with komi 0.5, white has 47.5 winn. perc.
with komi 1.5, white has 50.7 winn. perc.
with komi 2.5, white has 50.9 winn. perc.
with komi 3.5, white has 54.0 winn. perc.
with komi 4.5, white has 53.8 winn. perc. <-- ?
with komi
I'm a bit confused about the difference between AMAF and RAVE (if there's one).
As far as I understand, with AMAF, you sample in each playout (after it leaves
the tree) the moves played (by both players), but only the first move at any
position, then you reward all moves played either by a win or l
Hi Sylvain,
Thanks for your quick answer.
> in a nutshell RAVE is basically AMAF adapted for Monte Carlo Tree Search.
> The original paper describing it is
> http://www.machinelearning.org/proceedings/icml2007/papers/387.pdf and a
> paper for "broader audience" can be found here:
> http://www.lr
Hi Sylvain,
I think it's starting to make sense now. :-)
> Sorry to be unclear. I wish we have a white board where we could discuss
> and
> that would sorted out in a few minutes :).
Several results turn up in a google search ;p
http://www.google.com/search?q=online+white+board
> What I tried
> Hi,
>
> I'm also interested at the same thing.
Glad I'm not alone. ;)
> > It sounds good but it seems to lack the check of whether a given move is
> > first played in a given intersection. When you add that, it because a
> little
> > more tricky to update in the tree.
I see, I missed that. I
> Hi,
>
> Sorry for the slow reply.
Hi
I'd prefer quality over speed anytime. ;)
Your pseudo code is excellent and helped me to understand some of the trickier
things. Thanks again!
I think I will now be able to implement my own version. :)
Regards,
Isaac
--
Pt! Schon vom neuen GMX MultiM
Thanks again for your pseudo-implementation, Sylvain.
At the moment I have a program that uses plain MCTS. With every genmove, it
creates a certain number of
threads (2), gives them some starting data, and lets them think for a while,
then rejoins them, extracting the
best move. During the think
hat have been played in the playout). It really speeds up
> things
> a lot.
>
> Apart from that, I did the same as you, creating the thread after the
> genmove and joining them at the end of the thinking time.
>
> Sylvain
>
> 2009/1/20 Isaac Deutsch
>
> > Tha
Hello,
There is lots of information about heavy (heavier) playouts on this mailing
list. It looks like the main purpose of them is to make the evaluation
better by killing dead groups with a high probability, connecting groups
that are connected with high probability, etc. However, it looks like s
ould get q_ur from the current UCT-RAVE mean value,
and that it is used like that?
Regards,
Isaac Deutsch
--
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
http://www.gmx.net/de/go/multimessenger
___
computer-go mailin
At the moment I'm also tuning this constant in the range 0.001-0.1. Given
uniformly random (light) playouts, is the bias expected to be bigger than with
heavy playouts, meaning the constant has to be bigger aswell?
--
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
http:/
Hi,
The "criticality" stuff looks really interesting. Do you apply it with the
offline knowledge, or as a RAVE prior value, or otherwise? It looks like
you precalculate (before the MTCS) the ownership + criticality map, maybe
it can be extracted from playouts in the MTCS as well?
ibd
O
By the way, I got about 75 ELO points (1650->1720) with light playouts out of
RAVE. Do you think this is in the expected range? It's not really similar to
the 20%->60% win rate rise vs. GnuGo described in some papers...
> At the moment I'm also tuning the bias in the range 0.001-0.1. Given
> uni
Wow, thanks for all the answers! You're being really helpful.
"Do you use UCT with a too large exploration term?"
That's a good idea. I actually use a rather big value for c=0.5. I might try
lowering it. Thanks! (Precisely, the formula is c*sqrt(log(p)/c).)
"My first (braindead) multi-threaded UC
I have about 200-300k games/move, so maybe the effect is even less. But,
maybe I still have a grave bug somewhere. I will check again.
Cheers, ibd
> On Feb 2, 2009, at 9:57 AM, Isaac Deutsch wrote:
>
> > They are not pattern based playouts, but as I said uniformly random.
>
> Hi Issac,
> You should be more in the range of +200-300 ELO, at least with pattern
> based
> playouts.
>
> Sylvain
Isaac. They are not pattern based playouts, but as I said uniformly random.
I reckon the effect of RAVE is less with these?
"How many playouts per second do you get with each ver
I actually tried leaf parallelization first, but after reading the
mentioned paper I switched to an implementation of root parallelization (as
described). I'm not sure if I implemented it correctly (like in my
description), but after testing a 2-core-version against a single-
core-version with a fe
Hi Jason,
Thanks for your numbers. I might try to limit my bot to 50k playouts and 1
core, but I usually simulate as long as time permits. Do you suspect my
pure UCT version has bugs, too, judging from its rating? I find it hard to
find good tests for the correctness of a program depending on "ran
Thanks Christoph.
I've changed my bot to play 50k games. I know the results aren't very
statistically meaningful yet, but the 2 bots look close to each other
already. ;-) I will let it run for some more days if I can.
http://img145.imageshack.us/img145/3586/bild3bk3.png
-ibd
> I have started t
The rating of the bot still seems to be drifting upwards, but I think I can
conclude my UCT implementation is OK afterall. Many thanks to the bots
provided. Does someone have a bot that does 50k light playouts + RAVE? I
would be most grateful if you could put them online for a few days of
testing.
> I'm currently tied up but you can get my MCTS implementation, which
> includes RAVE, and set it up to play 50K playouts. It's only a matter
> of setting the right number in the configuration file.
>
> You can also use it to play through two-gtp, that way you can test an
> awful lot faster.
>
>
ed yet. But I won't be able to commit that for a few
> more days as I'm not at home. But if you implemented RAVE correctly
> your bot should do at least as well as this one.
>
> Hopefully it's any help.
>
> Mark
>
>
> On Sat, Feb 7, 2009 at 7:18 AM, Isa
No hurry, I will be away for a week next week. :-)
> Isaac,
>
> I haven't looked at this stuff for a while. I'm not at home so I can't
> look at it now.
>
> >>From the error I understand that tesuji/games/general/MoveIterator is
> missing. It is there in the Subversion source-tree however. So I
u may have to experiment a little to find the
> optimal settings.
>
> Mark
>
>
> On Feb 8, 2009, at 7:06 AM, Isaac Deutsch wrote:
>
> > No hurry, I will be away for a week next week. :-)
> >
> >
> >> Isaac,
> >>
> >> I haven&#x
> Probably the most original part of Zen is in the playout. I don't think MC
> simulations must be always fast, so it has a lot of hard-coded Go
> knowledge.
> Yamato
Hello
Are your playouts simple enough so you could publish the exact algorithm in
(pseudo) source code? I'm sure many will be
Hi
I'm currently using the method described here to detect if a group is in
atari (1 real liberty):
http://computer-go.org/pipermail/computer-go/2007-November/012350.html
Thus I store the number of pseudo libs, the sum and the sum of squares for
each group.
Now for heavy playouts, it would be u
> Many Faces also counts real liberties, and is quite fast enough.
>
> > I can confirm, with a bit of optimization, counting real liberties is
> > only marginally slower than counting pseudo-liberties. So there's
> > really no benefit that I can see from using pseudo liberties.
> >
> > Mark
> >
> On Thu, Apr 2, 2009 at 5:14 AM, wrote:
> > Isaac,
> >
> > I implemented about 6 way to track liberties,
> > a couple years ago, and measured the running
> > performance, and by far the best is also the
> > simplest: keep an array of liberties for each
> > chain, and do a simple linear search
I made some artificial tests where I do x inserts, 1 delete, 10 counts and
1 merge. For x=4 inserts, linear arrays are about 4 times faster. For x=8
inserts, linear arrays are about 3 times faster. From your data I calculated
an average liberty count of 2.8 (which seems low to me). This means that
I actually found a bug in my test, and corrected it. The gap is far less
large now. I found that for 10 inserts (and 1 delete, so 9 total libs),
The arrays are faster by a small amount. For 11 inserts (10 libs), bit
arrays are faster. This leads us to the question if groups in average have
<=10 or
Hi Lukasz,
I think I understand the way it is done for storing the stones; I do it
exactly the same way.
For the liberties: Does the index of the direction (NWSE) state where the
chain is in respect to the liberty? So if you place a single stone on the
board at "position", you add 4 liberties and
> Yep.
> I'm thinking about implementing it in libego with heavy playouts for
> demonstration.
> Maybe It will get libego some attention. :)
Thanks for your answers. I'm impressed with the speed of your library.
> I use zobrist hashing as well. But the random base is separated from
> board and
> Like any hash function, multiple board positions can hash to the same
> value. The idea is that the probability of encountering two board
> positions in the same game that have the same hash value is so low,
> that if you get a duplicate hash value you are practically guaranteed
> that it's a s
> Does my session on
> CGOS eventually time out?
Yes, you'll have to wait until it times out before you can log in again.
This is a bit annoying because you can't immediately reconnect after a
disconnect.
--
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss
für nur 17
Hello,
I'm about to work on heavy playouts, and I'm not sure how to choose a move
during the playout. I intend to have weights for various features. I thought
about 3 versions:
1. In a position, calculate all the weights and the total weight. Then, play
one move i with the probability weight_i/to
Wow, you're fast to congratulate. ;)
Congratulations from me, too.
Isaac
--
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss
für nur 17,95 Euro/mtl.!*
http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a
_
Hi.
I've been thinking about pondering, and the way the tree has to be built to
support pondering. Because with pondering, the thinking time for a move can
be very big theoretically, I would like to handle automatic pruning of the
tree to avoid running out of memory. Right now I have a fixed size
> In dimwit we simply increase the number of visits to a node before it
> is added to the UCT tree, to slow down its growth. I wasn't too happy
> about how selective the tree got with a long time to think, but it's
> unclear if this particular hack had anything to do with that.
>
> Álvaro.
I al
> No. We use a threshold that is a function of how large the tree
> already is. It starts at 5 and then we increase it as the tree grows
> larger. I think the exact formula scaled with something like the
> log(tree_size)^2, but I would have to check when I get home.
>
> Álvaro.
Ah, now I underst
> Well, I'll take that over crashing with an out-of-memory error. :)
Still, pruning seems better to me and has the same effect. ;p
--
Nur bis 31.05.: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und
Telefonanschluss nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
> But is it better? I think it's not so obvious without thorough testing.
> - Don
OK. It seems difficult to find a good rule to prune moves/nodes.
I just had an additional idea. You could make the treshold for expanding a
node a function of the tree size AND the depth the node is at in the t
Congrats to stv.
> But I would prefer more, and would like to know what I
> might do to attract more entrants.
>
> Nick
What about a Rengo tournament? :) I don't know how feasible that would be,
but it could be fun to have programs cope with someone else on their team.
--
GMX FreeDSL mit DSL
Hi,
I did some tests with my program about how well it does using 2 threads
instead of using only 1 thread. I played 200 games of 9x9 with 5 min SD using
gogui's twogtp. Here's the results:
rango (my program), 1 thread vs. gnugo: 46.7 +-3.5% wins
rango, 2 threads vs. gnugo: 54.5 +-3.5% wins
rango
> Pebbles prunes least recently used nodes. This eliminates nodes
> from previous searches first, and then nodes from the current search.
Why do you keep nodes from previous searches? By search, do you mean a
"genmove"? How do you store which nodes are oldest (queue, heap)?
--
GRATIS für alle GM
Thanks for the input. It is a very interesting idea. Since I don't have a
transposition table but only a stupid tree, I can't apply the same mechanic.
I can image that with a transposition table, nodes are very equally distri-
buted, so pruning one of the 16 moves almost always is a good choice.
B
I'm voting for 2 time settings: One normal and one fast (so maybe 5 min and 1
min on 9x9).
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
computer-go mailing list
computer-go
Sounds interesting. Have you considered learning these "temperatures" from pro
games?
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
computer-go mailing list
computer-go@comp
Has anyone tried this algorithm improvement on bigger boards and can give us
a result?
Link to original message:
http://computer-go.org/pipermail/computer-go/2009-April/018159.html
Thanks,
ibd
> > So maybe I could get 600 more Elo points
> > with your method. And even more on 19x19.
> > I notice
Okay, I've almost got it.
I'm also looking into implementing a transposition table. Some things
are still unclear to me.
If you're hashing by chaining, you presumably go to the appropriate
slot in the table, then traverse the (short) linked list of nodes
hanging from that slot. If the
Hello,
I'm thinking about wether it's better to keep a list of stones for
each group in the board state or not.
I'm keeping a linked list of liberties like Lukasz suggested and it is
useful in many cases, but the only case that access to all stones in a
group is handy is when removing it
Isn't 4. similar to doubly linked lists? You have to keep almost as
many pointers as there are points on the board at most. How do you
effectively store the pointers to only use as few as possible?
I don't see how 5) is good for removing groups. Are there other uses
for the bitmaps?
Am 11
Am 13.07.2009 um 17:36 schrieb Carter Cheng:
Hi,
I have again been considering trying my hand at implementing a
simple go program. The question I have pertains to checking for the
edge of the board in capture situations and so on. For a modern CPU
(given what limited information I have
For KGS, there is kgsgtp.jar, CGOS provides scripts that connect your
engine to the server, too.
Am 15.07.2009 um 15:41 schrieb Carter Cheng:
Where can I find information on these bridging protocols or are
libraries provided for this (to the 9x9 & 19x19 servers)?
--- On Wed, 7/15/09, Hell
I'm about to implement this. Since I have multiple features (patterns,
is in atari, is adjacent to last play, etc.), the weight is the
product of the weight of all matching features.
I'm thinking about having a table of weights, storing the sum of each
row and the total (like Rémi suggested
In my example, #=border/edge of the board, not black. I was just
trying to come up with an example feature that might have weight zero
to illustrate my problem.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailm
Thanks to both for the elaborate feedback! I was wondering about
pattern symmetry, too, and I also had a lookup table in mind since
there are only about 65000 combinations (and only a fraction of them
legal).
I had another idea for the zero weight problem: Keep a counter of how
many times
Hello,
I have a question regarding the paper by Rémi Coulom. There is a link
to it here:
http://computer-go.org/pipermail/computer-go/2007-December/012557.html
My first question also relates to that mailing list post. Rémi says:
"My suggestion would be to test your code with very small amoun
Am 24.07.2009 um 16:25 schrieb Jason House:
Adding a prior through a 3rd player should alter your results.
There's minimal data on how A compares to B, so since the data for
dummy says they're equal, you should expect results closer to one.
You could do priors that simply set the initial g
An overall drift in the numbers might be nothing. Some pattern
(sub)sets can be multiplied by a constant value without affecting
overall prediction accuracy. Fixing one or more gamma values may fix
your drift issue. I think Remí's paper forced the average gamma to
be 1 after each itera
To answer exactly, I need to know more about how you set up your
patterns. If every point gets one, and exactly one 3x3 pattern, then
fixing one 3x3 pattern is required. If some points have no 3x3
pattern, then you're implicitly fixing an "other" pattern to a value
of 1 and then no fixing
It sounds to me like your 3x3 patterns are an orthogonal set
relative to everything else. Because of that, you must pin on 3x3
gamma. You may need to pin a few more... Note that any set of
features where you don't pick one for every legal move doesn't
require pinning because you implicitly
My program performed worse with this (about 50 elo), but I didn't
combine it with RAVE (just pure UCT with this).
Am 25.07.2009 um 00:38 schrieb Peter Drake:
Is anyone also using a global table of moves made after ALL nodes in
the search, a sort of global RAVE table? It would be noisier st
24, 2009, at 3:50 PM, Isaac Deutsch wrote:
My program performed worse with this (about 50 elo), but I didn't
combine it with RAVE (just pure UCT with this).
Am 25.07.2009 um 00:38 schrieb Peter Drake:
Is anyone also using a global table of moves made after ALL nodes
in the search, a so
Welcome. :)
Consider implementing GTP so that your program can be used with nice
GUIs such as GoGui.
Regards, Isaac
Am 29.07.2009 um 13:49 schrieb Folkert van Heusden:
I started yesterday to create a new Go program. It is called 'Stop'
and
is written in Java. The .jar-file can be found o
I planned to enter the august tournament but development progressed
slower than expected. I plan to enter the september tournament. You'll
have 1 weak bot more ;)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mai
I only
use the 3x3 patterns for eye knowledge.
Thanks and regards,
Isaac Deutsch
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Congrats for a good 19x19 game and a won 9x9 game.
-ibd
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Did you think the bot would not benefit much from additional time usage?
Am 10.08.2009 um 15:46 schrieb Yamato:
Thank you all for watching the games against O Meien 9p.
He was very strong. I am sorry that Zen did not play very good.
Ingo Althöfer wrote:
Why did Zen play so quickly in the 19x1
Congrats for breaking the 1000 elo mark on cgos. ;) Some things I
noticed when watching 2 games:
-stop plays on the first line/corner in the beginning. maybe this
helps: http://computer-go.org/pipermail/computer-go/2008-December/017340.html
or this: http://computer-go.org/pipermail/computer-
I admit I had trouble understanding the details of the paper. What I
think is the biggest problem for applying this to bigger (up to 19x19)
games is that you somehow need access to the "true" value of a move,
i.e. it's a win or a loss. On the 5x5 board they used, this might be
approximated
With crazystone-like playouts, you can just put "noise" over the
possibilites. the more noise, the more random the playout is, which is
weaker. The best move in the tree is then the one that requires the
least amount of noise for the other player to reach 50% win chance if
behind, or the on
Yes, I'm one. Haven't upgraded to SL yet, though.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
I watched a game of your bot, and it still fills its own eyes, killing
alive groups. I suggest you strictly forbid eye-filling moves until
the bot is much stronger (I think it is needed in very few cases to
kill groups). Also it plays many, many bad self-atari moves into the
tiger mouth sha
The article is a very good read! GDC, blocks and OpenCL sound exciting.
When I tried LLVM, I got a performance drop, too (but still not using
Snow Leopard, and the new versions might be better).
-ibd
___
computer-go mailing list
computer-go@computer
That's only possible in free games, but not possible in rated games.
Am 09.09.2009 um 11:56 schrieb Erik van der Werf:
Last time I tried my program on kgs human players could simply declare
all bot stones dead and win regardless of the position. Did this
change?
Erik
On Wed, Sep 9, 2009 at 8
maybe some divide & conquer algorithm?
Am 10.09.2009 um 14:43 schrieb Petr Baudis:
On Thu, Sep 10, 2009 at 08:29:31AM -0400, Jason House wrote:
I've thought of something similar in the past, but with a twist:
pre-compute a subset of moves that could be safely played in
parallel. Even if you c
I always see this message when booting up CGOS. However, my program
supports "time_left" and I also state this in "list_commands". Time
control would be much better if I got feedback from the server. How
can I use it? Is there a special command I'm missing?
Thanks,
Isaac
___
thanks, it works!
Am 10.09.2009 um 18:49 schrieb Go Fast:
I think it needs time_settings
On Thu, Sep 10, 2009 at 12:37 PM, Isaac Deutsch wrote:
I always see this message when booting up CGOS. However, my program
supports "time_left" and I also state this in "list_commands&q
I now have playouts based on 3x3 pattern weights.
When I tested it on CGOS it seemed to be weaker than my old engine
which used light playouts only. I used a comparable setup, and the elo
difference is about 100 after more than 150 games.
I can also seem some weird RAVE value patterns (not
50k playouts. they apply globally.
Am 13.09.2009 um 01:22 schrieb Jason House:
Same number of playouts? What are your pattern weights? Do they
apply around the last move played or for all board areas?
___
computer-go mailing list
computer-go@computer
Did you learn weight for every possible pattern using the crazystone
algorithm, or are you just using the basic mogo patterns?
No, all 1000 and something weights are learned using the algorithm.
Are you using global patterns as UCT priors, or to choose moves
during playouts? During playout
It looks like zengg19 on KGS has to be restarted with the new version, it keeps
crashing, or so it seems.
Am 27.12.2009 um 13:09 schrieb Hiroshi Yamashita:
> It seems KGS client has changed.
>
> Old kgsGtp does not work.
> Latest version (kgsGtp-3.3.27) is ok.
>
> kgsGtp-3.3.27.zip
> http://
Fuego_9x9_1h (or a variation of this name) played on OGS a couple of handicap
9x9 games. It used dynamic komi. I think it was manually adjusted after every
move, and worked well.
-ibd
Am 17.02.2010 um 22:51 schrieb Ingo Althöfer:
> Hello,
>
> I informed the German go scene that there is (some
83 matches
Mail list logo
