From 3-Hirn-Verlag at gmx.de Sat Oct 1 04:35:35 2011
From: 3-Hirn-Verlag at gmx.de (=?iso-8859-1?Q?=22Ingo_Alth=F6fer=22?=)
Date: Sat, 01 Oct 2011 13:35:35 +0200
Subject: [Computer-go] Clobber++ in Computer Olympiad?
Message-ID: <20111001113535.14030@gmx.net>
Hello,
of course this is a mailing list for computer go.
Nevertheless I want to ask a question concerning another
board game with simple rules: Clobber.
Clobbr was played in several Computer Olympiads already,
in 2005, 2006, 2010.
http://www.grappa.univ-lille3.fr/icga/game.php?id=14
I would like to present my own Clobber bot in the Tilburg Olympiad.
Several years ago, in 2003, I had designed a variant of Cloober,
named "Cannibal Clobber". The rules are almost identical to that of Clobber,
however any piece (own or foreign) which is directly to the north or east
or south or west, can be captured. See also at
http://www.zillionsofgames.com/cgi-bin/zilligames/submissions.cgi?do=show;id=206
(My bot for Cannibal Clobber is NOT based on Zillions of Games.)
When someone wants to know more about Clobber or Cannibal Clobber, please
feel free to contact me.
Perhaps we might also have a Cannibal Clobber competition in Tilburg?!
Ingo.
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
From nick at maproom.co.uk Sat Oct 1 07:30:23 2011
From: nick at maproom.co.uk (Nick Wedd)
Date: Sat, 01 Oct 2011 15:30:23 +0100
Subject: [Computer-go] October KGS bot tournament - 19x19 boards, fast
In-Reply-To: <4E7F7789.5080206@maproom.co.uk>
References: <4E7F7789.5080206@maproom.co.uk>
Message-ID: <4E8723FF.7010901@maproom.co.uk>
Reminder - it's tomorrow.
Nick
On 25/09/2011 19:48, Nick Wedd wrote:
> The October 2011 KGS computer Go tournament will be on Sunday October
> 2nd, starting at 08:00 UTC and ending at 15:30 UTC.
>
> It will be a 15-round Swiss with 19x19 boards, 14 minutes each of main
> time, and Canadian Overtime of 10 moves in 30 seconds. It will use
> Chinese rules with 7.5 points komi. There are details at
> http://www.gokgs.com/tournInfo.jsp?id=620.
>
> Registration is now open. To enter, please read and follow the
> instructions at http://www.weddslist.com/kgs/how/index.html . The rules
> are given at http://www.weddslist.com/kgs/rules.html .
>
> Please send your registration email (with the words "KGS Tournament
> Registration" in the title) to me at maproom at gmail dot com (converted
> to a valid address by using "@" and ".").
>
> Nick
--
Nick Wedd
nick at maproom.co.uk
From nick at maproom.co.uk Mon Oct 3 12:49:41 2011
From: nick at maproom.co.uk (Nick Wedd)
Date: Mon, 03 Oct 2011 20:49:41 +0100
Subject: [Computer-go] Congratulations to Zen!
Message-ID: <4E8A11D5.1030001@maproom.co.uk>
Congratulations to Zen19, winner of yesterday's bot tournament with 15
wins from 15 games!
My report is at http://www.weddslist.com/kgs/past/76/index.html . It
has little of interest in it, as I can't really comment on the programs'
moves, except to point out that some of them can misread simple ladders.
As usual I look forward to your comments and corrections.
Nick
--
Nick Wedd
nick at maproom.co.uk
From sheppardco at aol.com Tue Oct 4 09:54:17 2011
From: sheppardco at aol.com (Brian Sheppard)
Date: Tue, 4 Oct 2011 12:54:17 -0400
Subject: [Computer-go] CLOP: Confident Local
Optimization forNoisyBlack-Box Parameter Tuning
In-Reply-To: <94A89B42-B6B3-42DE-9880-22A13141DE9F@free.fr>
References: <839E9E6B-69B3-47AF-80B3-CF2414B929BB@free.fr><1431139742D748A2B72CC4CC3BD6439B@InspironE1705> <5E4A0D46-77C1-4C7F-8D4A-828FB9B95F1F@free.fr> <09FCECAA751F4573B76E5D82115091C5@InspironE1705>
<94A89B42-B6B3-42DE-9880-22A13141DE9F@free.fr>
Message-ID: <001001cc82b6$410bc190$c32344b0$@com>
Hi, Remi. I have a question about the "burn-in" process for CLOP.
Normally you need a lot of data to make a decent regression function. For
example, if you have N arguments in your function, then CLOP
(Correlated-All) needs 1 + N * (N+3) / 2 parameters. So if you want 10
observations per parameter, then you need 10 + 5N(N+3) samples.
But even getting *one* sample can be tricky, because the 'logit' for a
sample is +INF if the sample wins all of its games, and -INF if the sample
loses all of its games. So you need a sample that has some wins and some
losses. If the true value of the function is near 0.5, then the average
number of trials required to obtain a sample is around 3, which is fine.
But some of the test functions in your paper are very different. For
example, the Correlated2 function is nearly 0 for most of the domain
[-1,1]^4. When I sample randomly, it takes ~5K samples (that is, ~20K
trials) to turn up enough samples to fit a regression line.
I tried initializing my win/loss counters to epsilon instead of zero. But
that technique was not robust, because any reasonable epsilon is actually
larger than Correlated2 for most of the domain. Consequently, the "reduce
the weights" step does not reduce enough weights, and the logistic
regression ends up fitting epsilon, rather than Correlated2.
So I cannot get a valid measurement with less than 20K trials before the
first regression step. But your paper shows regret curves that start out at
10 trials.
What am I missing?
Thanks,
Brian
From Remi.Coulom at free.fr Tue Oct 4 12:18:04 2011
From: Remi.Coulom at free.fr (=?iso-8859-1?Q?R=E9mi_Coulom?=)
Date: Tue, 4 Oct 2011 21:18:04 +0200
Subject: [Computer-go] CLOP: Confident Local
Optimization forNoisyBlack-Box Parameter Tuning
In-Reply-To: <001001cc82b6$410bc190$c32344b0$@com>
References: <839E9E6B-69B3-47AF-80B3-CF2414B929BB@free.fr><1431139742D748A2B72CC4CC3BD6439B@InspironE1705> <5E4A0D46-77C1-4C7F-8D4A-828FB9B95F1F@free.fr> <09FCECAA751F4573B76E5D82115091C5@InspironE1705>
<94A89B42-B6B3-42DE-9880-22A13141DE9F@free.fr>
<001001cc82b6$410bc190$c32344b0$@com>
Message-ID: <5A15A086-BEA9-4A90-8340-2596295ECEBC@free.fr>
Hi Brian,
On 4 oct. 2011, at 18:54, Brian Sheppard wrote:
> Hi, Remi. I have a question about the "burn-in" process for CLOP.
>
> Normally you need a lot of data to make a decent regression function. For
> example, if you have N arguments in your function, then CLOP
> (Correlated-All) needs 1 + N * (N+3) / 2 parameters. So if you want 10
> observations per parameter, then you need 10 + 5N(N+3) samples.
>
> But even getting *one* sample can be tricky, because the 'logit' for a
> sample is +INF if the sample wins all of its games, and -INF if the sample
> loses all of its games. So you need a sample that has some wins and some
> losses. If the true value of the function is near 0.5, then the average
> number of trials required to obtain a sample is around 3, which is fine.
I deal with +INF/-INF with a prior: the Gaussian prior regularizes the regression, so its tends to remain flat and close to 0.5 when very few samples have been collected.
>
> But some of the test functions in your paper are very different. For
> example, the Correlated2 function is nearly 0 for most of the domain
> [-1,1]^4. When I sample randomly, it takes ~5K samples (that is, ~20K
> trials) to turn up enough samples to fit a regression line.
I am not sure I understand what you mean. If you use regularization, you can perform regression even with zero samples. Of course, it is very inaccurate. But if you are careful to take confidence intervals into consideration, you can still do statistics with very few samples, and determine with some significance that an area is bad.
>
> I tried initializing my win/loss counters to epsilon instead of zero. But
> that technique was not robust, because any reasonable epsilon is actually
> larger than Correlated2 for most of the domain. Consequently, the "reduce
> the weights" step does not reduce enough weights, and the logistic
> regression ends up fitting epsilon, rather than Correlated2.
>
> So I cannot get a valid measurement with less than 20K trials before the
> first regression step. But your paper shows regret curves that start out at
> 10 trials.
>
> What am I missing?
I am not sure what you are missing.
In the case of Correlated2: In the beginning CLOP will sample uniformly at random (if you run the algorithm in the paper with N=0, then w(x)=1 everywhere). As soon at it find its first win, it will start focusing around that first win. You should be able to easily run CLOP on Correlated2. Just edit DummyExperiment.clop and DummyScript.py. You can also take a look at Gian-Carlo's chess data: it is a bit similar, as most games are lost in the beginning.
One important aspect of CLOP is the use of the confidence interval. It does not matter if the regression is very inaccurate. Even with an inaccurate regression, it can get confident that some areas of the search space are below average, so they should not be sampled.
If you sample uniformly at random until you get an accurate regression, then, yes, it will take forever. Maybe what you are missing is that CLOP does not need an accurate regression at all to already focus its sampling on a promising region.
Rémi
From sheppardco at aol.com Tue Oct 4 14:58:58 2011
From: sheppardco at aol.com (Brian Sheppard)
Date: Tue, 4 Oct 2011 17:58:58 -0400
Subject: [Computer-go] CLOP: Confident
Local Optimization forNoisyBlack-Box Parameter Tuning
In-Reply-To: <5A15A086-BEA9-4A90-8340-2596295ECEBC@free.fr>
References: <839E9E6B-69B3-47AF-80B3-CF2414B929BB@free.fr><1431139742D748A2B72CC4CC3BD6439B@InspironE1705> <5E4A0D46-77C1-4C7F-8D4A-828FB9B95F1F@free.fr> <09FCECAA751F4573B76E5D82115091C5@InspironE1705> <94A89B42-B6B3-42DE-9880-22A13141DE9F@free.fr> <001001cc82b6$410bc190$c32344b0$@com>
<5A15A086-BEA9-4A90-8340-2596295ECEBC@free.fr>
Message-ID: <003501cc82e0$d1d7fca0$7587f5e0$@com>
My implementation is missing the Gaussian prior. That seems to explain all
of the issues.
It is especially important that having the prior will focus attention on the
region of success. In the case of Correlated2, where only a tiny fraction of
the space is non-zero, that will massively reduce the burn-in period.
-----Original Message-----
From: computer-go-bounces at dvandva.org
[mailto:computer-go-bounces at dvandva.org] On Behalf Of Rémi Coulom
Sent: Tuesday, October 04, 2011 3:18 PM
To: computer-go at dvandva.org
Subject: Re: [Computer-go] CLOP: Confident Local Optimization
forNoisyBlack-Box Parameter Tuning
Hi Brian,
On 4 oct. 2011, at 18:54, Brian Sheppard wrote:
> Hi, Remi. I have a question about the "burn-in" process for CLOP.
>
> Normally you need a lot of data to make a decent regression function. For
> example, if you have N arguments in your function, then CLOP
> (Correlated-All) needs 1 + N * (N+3) / 2 parameters. So if you want 10
> observations per parameter, then you need 10 + 5N(N+3) samples.
>
> But even getting *one* sample can be tricky, because the 'logit' for a
> sample is +INF if the sample wins all of its games, and -INF if the sample
> loses all of its games. So you need a sample that has some wins and some
> losses. If the true value of the function is near 0.5, then the average
> number of trials required to obtain a sample is around 3, which is fine.
I deal with +INF/-INF with a prior: the Gaussian prior regularizes the
regression, so its tends to remain flat and close to 0.5 when very few
samples have been collected.
>
> But some of the test functions in your paper are very different. For
> example, the Correlated2 function is nearly 0 for most of the domain
> [-1,1]^4. When I sample randomly, it takes ~5K samples (that is, ~20K
> trials) to turn up enough samples to fit a regression line.
I am not sure I understand what you mean. If you use regularization, you can
perform regression even with zero samples. Of course, it is very inaccurate.
But if you are careful to take confidence intervals into consideration, you
can still do statistics with very few samples, and determine with some
significance that an area is bad.
>
> I tried initializing my win/loss counters to epsilon instead of zero. But
> that technique was not robust, because any reasonable epsilon is actually
> larger than Correlated2 for most of the domain. Consequently, the "reduce
> the weights" step does not reduce enough weights, and the logistic
> regression ends up fitting epsilon, rather than Correlated2.
>
> So I cannot get a valid measurement with less than 20K trials before the
> first regression step. But your paper shows regret curves that start out
at
> 10 trials.
>
> What am I missing?
I am not sure what you are missing.
In the case of Correlated2: In the beginning CLOP will sample uniformly at
random (if you run the algorithm in the paper with N=0, then w(x)=1
everywhere). As soon at it find its first win, it will start focusing around
that first win. You should be able to easily run CLOP on Correlated2. Just
edit DummyExperiment.clop and DummyScript.py. You can also take a look at
Gian-Carlo's chess data: it is a bit similar, as most games are lost in the
beginning.
One important aspect of CLOP is the use of the confidence interval. It does
not matter if the regression is very inaccurate. Even with an inaccurate
regression, it can get confident that some areas of the search space are
below average, so they should not be sampled.
If you sample uniformly at random until you get an accurate regression,
then, yes, it will take forever. Maybe what you are missing is that CLOP
does not need an accurate regression at all to already focus its sampling on
a promising region.
Rémi
_______________________________________________
Computer-go mailing list
Computer-go at dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
From Remi.Coulom at free.fr Thu Oct 6 00:55:05 2011
From: Remi.Coulom at free.fr (=?iso-8859-1?Q?R=E9mi_Coulom?=)
Date: Thu, 6 Oct 2011 09:55:05 +0200
Subject: [Computer-go] CLOP: Confident
Local Optimization forNoisyBlack-Box Parameter Tuning
In-Reply-To: <003501cc82e0$d1d7fca0$7587f5e0$@com>
References: <839E9E6B-69B3-47AF-80B3-CF2414B929BB@free.fr><1431139742D748A2B72CC4CC3BD6439B@InspironE1705> <5E4A0D46-77C1-4C7F-8D4A-828FB9B95F1F@free.fr> <09FCECAA751F4573B76E5D82115091C5@InspironE1705> <94A89B42-B6B3-42DE-9880-22A13141DE9F@free.fr> <001001cc82b6$410bc190$c32344b0$@com>
<5A15A086-BEA9-4A90-8340-2596295ECEBC@free.fr>
<003501cc82e0$d1d7fca0$7587f5e0$@com>
Message-ID:
On 4 oct. 2011, at 23:58, Brian Sheppard wrote:
> My implementation is missing the Gaussian prior. That seems to explain all
> of the issues.
Yes, having a prior is very important. In the draft of my paper, I wrote that its choice has little influence on performance of the algorithm. It is correct for low-dimensional problems (ie n < 10), but wrong when the dimension is high. Regularization should be stronger in high dimensions. Maybe using sparse logistic regression is a good idea in high dimensions. I'll research this question more when I have time.
>
> It is especially important that having the prior will focus attention on the
> region of success. In the case of Correlated2, where only a tiny fraction of
> the space is non-zero, that will massively reduce the burn-in period.
Note that CLOP as described in my paper requires no explicit logic for a burn-in period. You can run that CLOP procedure with any number of samples, from zero to ten millions.
Rémi
From jshriver at gmail.com Thu Oct 6 22:21:27 2011
From: jshriver at gmail.com (Joshua Shriver)
Date: Fri, 7 Oct 2011 01:21:27 -0400
Subject: [Computer-go] MyGoFriend
Message-ID:
Was digging around the wikipedia on the Computer Olympiad and saw that
MyGoFriend won the 2010 9x9 tournament? I know Zen is a huge contender
but this caught me off guard.
Anyone have any info on this engine? Open source? Free closed
downloads? 100% proprietary? If completely closed any
hardware/cluster specs on it?
-Josh
From nick at maproom.co.uk Fri Oct 7 12:59:38 2011
From: nick at maproom.co.uk (Nick Wedd)
Date: Fri, 07 Oct 2011 20:59:38 +0100
Subject: [Computer-go] December KGS bot tournament
Message-ID: <4E8F5A2A.6070406@maproom.co.uk>
I had scheduled the December KGS bot tournament (9x9 boards, slow) for
the "EA Eu" time band, that is, starting at 08:00 UTC. But on the
request of Hideki Kato, I have postponed it by eight hours, to start at
16:00 UTC on the same day. This should make it possible to compete in
it after leaving the UEC Cup in Tokyo the same day.
Nick
--
Nick Wedd
nick at maproom.co.uk
From 3-Hirn-Verlag at gmx.de Sat Oct 8 04:24:53 2011
From: 3-Hirn-Verlag at gmx.de (=?iso-8859-1?Q?=22Ingo_Alth=F6fer=22?=)
Date: Sat, 08 Oct 2011 13:24:53 +0200
Subject: [Computer-go] December KGS bot tournament
Message-ID: <20111008112453.160980@gmx.net>
Sorry, but somehow my mail provider seems to reject
mails from the computer-go list.
Nick Wedd wrote:
> I had scheduled the December KGS bot tournament (9x9 boards, slow) for
> the "EA Eu" time band, that is, starting at 08:00 UTC. But on the
> request of Hideki Kato, I have postponed it by eight hours, to start at
> 16:00 UTC on the same day. This should make it possible to compete in
> it after leaving the UEC Cup in Tokyo the same day.
Good idea.
And a wish: I would like to see the December tournament with komi=7.0
Ingo.
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
From ddyer at real-me.net Sat Oct 8 12:49:59 2011
From: ddyer at real-me.net (Dave Dyer)
Date: Sat, 08 Oct 2011 12:49:59 -0700
Subject: [Computer-go] Worthwhile MCTS paper
In-Reply-To: <003501cc82e0$d1d7fca0$7587f5e0$@com>
References: <839E9E6B-69B3-47AF-80B3-CF2414B929BB@free.fr>
<1431139742D748A2B72CC4CC3BD6439B@InspironE1705>
<5E4A0D46-77C1-4C7F-8D4A-828FB9B95F1F@free.fr>
<09FCECAA751F4573B76E5D82115091C5@InspironE1705>
<94A89B42-B6B3-42DE-9880-22A13141DE9F@free.fr>
<001001cc82b6$410bc190$c32344b0$@com>
<5A15A086-BEA9-4A90-8340-2596295ECEBC@free.fr>
<003501cc82e0$d1d7fca0$7587f5e0$@com>
Message-ID:
Pete Bruns has used monte carlo search to make a better robot
player for Tantrix. The specifics for tantrix as a game are
unrelated to Go, but the application of the methods is interesting.
http://tantrix.com/Tantrix/TRobot/doc/MCTS%20Final%20Report.pdf
This new bot will be playable as "monte" at Tantrix.com soon.
From sheppardco at aol.com Sun Oct 9 08:29:54 2011
From: sheppardco at aol.com (Brian Sheppard)
Date: Sun, 9 Oct 2011 11:29:54 -0400
Subject: [Computer-go] CLOP: Confident
LocalOptimization forNoisyBlack-Box Parameter Tuning
In-Reply-To: <5A15A086-BEA9-4A90-8340-2596295ECEBC@free.fr>
References: <839E9E6B-69B3-47AF-80B3-CF2414B929BB@free.fr><1431139742D748A2B72CC4CC3BD6439B@InspironE1705> <5E4A0D46-77C1-4C7F-8D4A-828FB9B95F1F@free.fr> <09FCECAA751F4573B76E5D82115091C5@InspironE1705><94A89B42-B6B3-42DE-9880-22A13141DE9F@free.fr><001001cc82b6$410bc190$c32344b0$@com>
<5A15A086-BEA9-4A90-8340-2596295ECEBC@free.fr>
Message-ID: <8A502205C0674173B1DE3390C6B39B89@InspironE1705>
I changed my implementation to use a Glicko rating system, which
incorporates a Gaussian prior, and now results are much better. My
implementation seems to be getting the same general results as published in
your paper.
The prior works particularly well for game applications, IMO, because it
sets the expectation that there is a way to set parameters that win at least
50%. In a well-designed game experiment that will always be the case. (E.g.,
at worst you can turn your new feature off by setting a weight to 0, or
something.)
But I am curious: have you ever run a test of Correlated5? Your paper has
results for Correlated2 and Rosenbrock5, but not Correlated5.
When I run Correlated5, the run can get stuck in a non-improving state for a
very long time. I don't have the patience to wait it out, so I don't know if
it will eventually detect a gradient.
Thanks,
Brian
>I deal with +INF/-INF with a prior: the Gaussian prior regularizes the
regression, so its tends to remain flat and close to 0.5 when very few
samples have been colle
From nick at maproom.co.uk Mon Oct 10 03:47:00 2011
From: nick at maproom.co.uk (Nick Wedd)
Date: Mon, 10 Oct 2011 11:47:00 +0100
Subject: [Computer-go] December bot tournament on KGS
Message-ID: <4E92CD24.1030003@maproom.co.uk>
(My mailer program claims that I sent the following message out three
days ago, and that I have not received it back via the mailing list.)
I had scheduled the December KGS bot tournament (9x9 boards, slow) for
the "EA Eu" time band, that is, starting at 08:00 UTC. But on the
request of Hideki Kato, I have postponed it by eight hours, to start at
16:00 UTC on the same day. This should make it possible to compete in
it after leaving the UEC Cup in Tokyo the same day.
Nick
--
Nick Wedd
nick at maproom.co.uk
From Remi.Coulom at free.fr Wed Oct 12 00:40:25 2011
From: Remi.Coulom at free.fr (=?iso-8859-1?Q?R=E9mi_Coulom?=)
Date: Wed, 12 Oct 2011 09:40:25 +0200
Subject: [Computer-go] Computer Olympiad reminder: deadline is today
Message-ID: <7CBABFEF-3FB2-4CC8-B19A-FDA6B699E582@free.fr>
Please don't forget to register.
Also: it seems nobody is receiving any message from the list any more. I have not received any message in one week.
Rémi
From 3-Hirn-Verlag at gmx.de Wed Oct 12 01:39:33 2011
From: 3-Hirn-Verlag at gmx.de (=?iso-8859-1?Q?=22Ingo_Alth=F6fer=22?=)
Date: Wed, 12 Oct 2011 10:39:33 +0200
Subject: [Computer-go] List service down
Message-ID: <20111012083933.232780@gmx.net>
Remi wrote:
> it seems nobody is receiving any message from the list any more. I have not
> received any message in
Me, too.
At least, the archive is still functional.
I read regularily from
http://computer-go.org/pipermail/computer-go/2011-October/date.html
Ingo.
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
From veg at dvandva.org Mon Oct 17 14:53:49 2011
From: veg at dvandva.org (Michael Richard aka Roveg)
Date: Mon, 17 Oct 2011 21:53:49 +0000 (UTC)
Subject: [Computer-go] ADMIN list is sending mail again
Message-ID:
Hi,
Things are flowing again. My apologies for the delay,
other email and services have all been smooth. Incoming mail
has been going into the archives.
Thanks,
veg
From slars at upb.de Fri Oct 21 01:44:18 2011
From: slars at upb.de (Lars =?ISO-8859-1?Q?Sch=E4fers?=)
Date: Fri, 21 Oct 2011 10:44:18 +0200
Subject: [Computer-go] Parallel Monte-Carlo Tree Search for HPC Systems
Message-ID: <1319186658.25662.103.camel@gogfx-desktop>
Hi,
for those of you interested in parallel MCTS for distributed memory
machines, I want to point you to our paper "Parallel Monte-Carlo Tree
Search for HPC Systems" recently presented at the EuroPar 2011
conference.
We present a novel approach for the parallelization of MCTS which allows
for an equally distributed spreading of both the work and memory load
among all compute nodes within a distributed memory HPC systems.
This is pretty much the parallelization currently used by our Go Engine
Gomorra (KGS account gomorra4).
You can download the original paper at Springerlink:
http://www.springerlink.com/content/y00906lk33142768/
You can also find an author manuscript on my site:
http://www.cs.uni-paderborn.de/fachgebiete/computer-engineering-group/people/schaefers.html
Any comments, questions or suggestions are of course welcome.
Best wishes,
Lars
From pshotwell at gmail.com Sat Oct 22 15:17:10 2011
From: pshotwell at gmail.com (P Shotwell)
Date: Sat, 22 Oct 2011 16:17:10 -0600
Subject: [Computer-go] Supercomputer Go Articles
Message-ID:
Hello All,
I have reorganized and updated my computer go articles in the AGA's
Bob High e-Library. It's now a separate section with two Appendices
called 'A Timeline of Supercomputer Go: From Temporal Difference
Learning to Monte Carlo Programming' and features (layman)
conversations with some of the leading figures over the last few years
along with the PhD thesis of Shih-Chieh Huang (Aja), Erica's
programmer.
Also, for those who might be interested, it was accompanied by
Appendix VI of my 'Origins' article about Henry Kissinger and Scott
Boorman's failed use of go to illustrate Chinese war and political
strategies in 'On China' and 'The Protracted Game.'
They are at www.usgo.org/bobhighlibrary.
Best,
Peter Shotwell
From ddyer at real-me.net Mon Oct 24 13:45:31 2011
From: ddyer at real-me.net (Dave Dyer)
Date: Mon, 24 Oct 2011 13:45:31 -0700
Subject: [Computer-go] some UCT notes
In-Reply-To: <7.1.0.9.2.20111008124547.07f6d8a0@real-me.net>
References: <839E9E6B-69B3-47AF-80B3-CF2414B929BB@free.fr>
<1431139742D748A2B72CC4CC3BD6439B@InspironE1705>
<5E4A0D46-77C1-4C7F-8D4A-828FB9B95F1F@free.fr>
<09FCECAA751F4573B76E5D82115091C5@InspironE1705>
<94A89B42-B6B3-42DE-9880-22A13141DE9F@free.fr>
<001001cc82b6$410bc190$c32344b0$@com>
<5A15A086-BEA9-4A90-8340-2596295ECEBC@free.fr>
<003501cc82e0$d1d7fca0$7587f5e0$@com>
<7.1.0.9.2.20111008124547.07f6d8a0@real-me.net>
Message-ID:
I've been working with UCT search for other games than Go, and one interesting thing I"ve learned is that the results can change dramatically depending on how the UCT values are manipulated as the tree grows.
Consider the root node; at the beginning of the search it's desirable to sample all the children equally, to be sure each has a fair chance to be noted as winning or losing. However, as the simulations continue, if this egalitarian distribution continues, the simulations from losing nodes dilutes the results (as well as wasting time), so it's necessary to start concentrating on the winning nodes. The exact method of transitioning from broad to narrow focus can have dramatic effect on the results.
From alvaro.begue at gmail.com Mon Oct 24 19:03:28 2011
From: alvaro.begue at gmail.com (=?ISO-8859-1?B?wWx2YXJvIEJlZ3Xp?=)
Date: Mon, 24 Oct 2011 19:03:28 -0700
Subject: [Computer-go] some UCT notes
In-Reply-To: <20111024204548.A4EA8BCDD7@dvandva.org>
References: <839E9E6B-69B3-47AF-80B3-CF2414B929BB@free.fr>
<1431139742D748A2B72CC4CC3BD6439B@InspironE1705>
<5E4A0D46-77C1-4C7F-8D4A-828FB9B95F1F@free.fr>
<09FCECAA751F4573B76E5D82115091C5@InspironE1705>
<94A89B42-B6B3-42DE-9880-22A13141DE9F@free.fr>
<001001cc82b6$410bc190$c32344b0$@com>
<5A15A086-BEA9-4A90-8340-2596295ECEBC@free.fr>
<003501cc82e0$d1d7fca0$7587f5e0$@com>
<7.1.0.9.2.20111008124547.07f6d8a0@real-me.net>
<20111024204548.A4EA8BCDD7@dvandva.org>
Message-ID:
On Mon, Oct 24, 2011 at 1:45 PM, Dave Dyer wrote:
>
> I've been working with UCT search for other games than Go, and one interesting thing I"ve learned is that the results can change dramatically depending on how the UCT values are manipulated as the tree grows.
>
> Consider the root node; at the beginning of the search it's desirable to sample all the children equally, to be sure each has a fair chance to be noted as winning or losing. However, as the simulations continue, if this egalitarian distribution continues, the simulations from losing nodes dilutes the results (as well as wasting time), so it's necessary to start concentrating on the winning nodes. The exact method of transitioning from broad to narrow focus can have dramatic effect on the results.
Doesn't the UCB formula basically encode this behavior? What I think I
learned about UCT from experimenting with dimwit is that, for nodes
other than the root, you need to reduce exploration so scores are not
too polluted by bad moves, but then the principal variation gets
ridiculously deep, which means that more exploration is needed. At the
root you can make the search explore more, since you don't need to
back out a score.
I don't know if go has an equivalent to queen sacrifices in chess, but
it would be very hard to make a UCT program that plays something like
that correctly: The queen sacrifice would look like a horrible move,
with really low score, and if you make the search explore enough to
figure out that it's a good move (by finding several correct
continuation moves) in a practical amount of time, the score will be
horribly polluted in the mean time.
The solution has to be disassociating how much time you spend
exploring a move and how much it contributes to the score of its
parent. I feel that UCT is great for making up a score out of repeated
simulations, but eventually we should end up thinking of it as an
evaluation function and using something much closer to minimax for the
parts of the tree close to the root. Unfortunately, I don't have any
successful experiments to back out this feeling.
From ddyer at real-me.net Mon Oct 24 20:56:53 2011
From: ddyer at real-me.net (Dave Dyer)
Date: Mon, 24 Oct 2011 20:56:53 -0700
Subject: [Computer-go] some UCT notes
In-Reply-To:
References: <839E9E6B-69B3-47AF-80B3-CF2414B929BB@free.fr>
<1431139742D748A2B72CC4CC3BD6439B@InspironE1705>
<5E4A0D46-77C1-4C7F-8D4A-828FB9B95F1F@free.fr>
<09FCECAA751F4573B76E5D82115091C5@InspironE1705>
<94A89B42-B6B3-42DE-9880-22A13141DE9F@free.fr>
<001001cc82b6$410bc190$c32344b0$@com>
<5A15A086-BEA9-4A90-8340-2596295ECEBC@free.fr>
<003501cc82e0$d1d7fca0$7587f5e0$@com>
<7.1.0.9.2.20111008124547.07f6d8a0@real-me.net>
<20111024204548.A4EA8BCDD7@dvandva.org>
Message-ID:
>
>Doesn't the UCB formula basically encode this behavior?
Yes, but the formula is not cast in stone. There are
infinite variations that implement the basic concept.
I guess the lesson I wanted to convey is that this formula,
or perhaps an algorithm too complicated to be expressed as
a simple formula, is part of the space that needs to be
explored.
From ddyer at real-me.net Mon Oct 24 20:56:53 2011
From: ddyer at real-me.net (Dave Dyer)
Date: Mon, 24 Oct 2011 20:56:53 -0700
Subject: [Computer-go] some UCT notes
In-Reply-To:
References: <839E9E6B-69B3-47AF-80B3-CF2414B929BB@free.fr>
<1431139742D748A2B72CC4CC3BD6439B@InspironE1705>
<5E4A0D46-77C1-4C7F-8D4A-828FB9B95F1F@free.fr>
<09FCECAA751F4573B76E5D82115091C5@InspironE1705>
<94A89B42-B6B3-42DE-9880-22A13141DE9F@free.fr>
<001001cc82b6$410bc190$c32344b0$@com>
<5A15A086-BEA9-4A90-8340-2596295ECEBC@free.fr>
<003501cc82e0$d1d7fca0$7587f5e0$@com>
<7.1.0.9.2.20111008124547.07f6d8a0@real-me.net>
<20111024204548.A4EA8BCDD7@dvandva.org>
Message-ID:
>
>Doesn't the UCB formula basically encode this behavior?
Yes, but the formula is not cast in stone. There are
infinite variations that implement the basic concept.
I guess the lesson I wanted to convey is that this formula,
or perhaps an algorithm too complicated to be expressed as
a simple formula, is part of the space that needs to be
explored.
From 3-Hirn-Verlag at gmx.de Tue Oct 25 00:50:48 2011
From: 3-Hirn-Verlag at gmx.de (=?iso-8859-1?Q?=22Ingo_Alth=F6fer=22?=)
Date: Tue, 25 Oct 2011 09:50:48 +0200
Subject: [Computer-go] some UCT notes
In-Reply-To: <20111025035713.0D359BCE1A@dvandva.org>
References: <839E9E6B-69B3-47AF-80B3-CF2414B929BB@free.fr>
<1431139742D748A2B72CC4CC3BD6439B@InspironE1705>
<5E4A0D46-77C1-4C7F-8D4A-828FB9B95F1F@free.fr>
<09FCECAA751F4573B76E5D82115091C5@InspironE1705>
<94A89B42-B6B3-42DE-9880-22A13141DE9F@free.fr>
<001001cc82b6$410bc190$c32344b0$@com>
<5A15A086-BEA9-4A90-8340-2596295ECEBC@free.fr>
<003501cc82e0$d1d7fca0$7587f5e0$@com>
<7.1.0.9.2.20111008124547.07f6d8a0@real-me.net>
<20111024204548.A4EA8BCDD7@dvandva.org>
<20111025035713.0D359BCE1A@dvandva.org>
Message-ID: <20111025075048.63160@gmx.net>
> Von: Dave Dyer
> >
> >Doesn't the UCB formula basically encode this behavior?
>
> Yes, but the formula is not cast in stone. There are
> infinite variations that implement the basic concept.
Right.
Making MCTS (or UCT) a success in practice consists
of 3 % principle-understanding and 97 % fine-tuning.
There are myriads of ways to implement Monte Carlo
in a favorable way.
Ingo.
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
From jacques at dybot.com Tue Oct 25 04:30:52 2011
From: jacques at dybot.com (=?iso-8859-1?Q?Jacques_Basald=FAa?=)
Date: Tue, 25 Oct 2011 12:30:52 +0100
Subject: [Computer-go] some UCT notes
Message-ID: <000301cc9309$8fcc2050$af6460f0$@com>
What you wrote sounds like you re-discovered the importance of progressive
widening PW ;-)
(See: Coulom, Computing Elo Ratings of Move Patterns in the Game of Go,
4.2 Progressive
Widening of the Monte-Carlo Search Tree)
In 19x19 when I implemented (about 1 year ago) RAVE a progressive widening I
had the first
wins against gnugo in 19x19 (I had some 9x9 wins before). But the reason PW
is so good is
somewhat different when you combine it with RAVE:
When the node has few visits, you only explore (say) 3 moves and those moves
are the 3 best
moves according to some a-priori heuristic, but when you widen the tree, you
do NOT include
the 4th move according to the same criterion, but the best non-explored RAVE
candidate. Only
3 nodes are considered for UCT (in the beginning, of course) but ALL nodes
get RAVE updates.
And these RAVE updates are specific for the path in the tree leading to the
node. So all non
explored nodes get high quality RAVE information and when you widen the tree
the 4th
candidate is a good move for whole board position represented by the node.
The way I implemented PW for the first time is the formula by Hiroshi
Yamashita (below)
Jacques.
(I copy/paste from my notes. It is somewhere in the list.)
Aya:
----
(1 - beta) * (win_rate + 0.31 * sqrt( ln(parent_visits) / child_visits)) +
beta (rave_win_rate * 0.31 * sqrt(
ln(rave_parent_visits) / rave_child_visits))
beta = sqrt(100 / (3 * child_visits + 100));
Aya uses Progressive Widening. High order N moves are only considerd.
PW_sort_N = ln(parent_visits/ 40.0) / ln(1.4) +2;
Moves are sorted sometimes by rave value, Criticality, and MC owners.
I also would like to know how to count rave.
UCT searches B(E5),W(D3),B(C5),W(F7), and in this position, playout searches
B(E7),W(E8),B(D8),W(F8),B(D7).. Black win.
In W(D3) positions, Aya updates RAVE and UCT,
Updates C5(UCT)
Updates C5(RAVE)
Updates E7(RAVE)
Updates D8(RAVE)
Updates D7(RAVE)
I think "Updates C5(RAVE)" is strange, but I could not get good result
without this.
Hiroshi Yamashita
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From pasky at ucw.cz Wed Oct 26 02:23:54 2011
From: pasky at ucw.cz (Petr Baudis)
Date: Wed, 26 Oct 2011 11:23:54 +0200
Subject: [Computer-go] Multi-armed bandit problem theory
Message-ID: <20111026092354.GC29324@machine.or.cz>
Hi!
Does anyone have a good source for understanding the theory behind
the multi-armed bandit problem, i.e. the proof behind the exponential
arm play bounds etc.? My only source so far is Auer et al., 2002:
Finite-time Analysis of the Multiarmed Bandit Problem - but I suspect
its description of the original bound is incomplete and/or simplified
with some implicit assumptions (i.e. in case of optimal arm, the bound
would involve division by zero?).
Everyone refers to Lai & Robbins, 1985 and Agrawal, 1995, but I'm
unable to find these papers anywhere (my university JTOR subscription
somehow magically doesn't seem to cover Agrawal, 1995). I'm hoping
that maybe I could grasp the details if I read those, does anyone have
a copy?
Thanks,
--
Petr "Pasky" Baudis
We live on an island surrounded by a sea of ignorance. As our island
of knowledge grows, so does the shore of our ignorace. -- J. A. Wheeler
From 3-Hirn-Verlag at gmx.de Wed Oct 26 04:56:03 2011
From: 3-Hirn-Verlag at gmx.de (=?iso-8859-1?Q?=22Ingo_Alth=F6fer=22?=)
Date: Wed, 26 Oct 2011 13:56:03 +0200
Subject: [Computer-go] Multi-armed bandit problem theory
In-Reply-To: <20111026092354.GC29324@machine.or.cz>
References: <20111026092354.GC29324@machine.or.cz>
Message-ID: <20111026115603.217510@gmx.net>
Not a direct answer, but some bit of information:
Bandit theory started in the early 1950' by Herbert Robbins
(the same Robbins from the 1985 paper). However, he did
not prove best possible bounds in the seminal paper.
Ingo.
-------- Original-Nachricht --------
> Datum: Wed, 26 Oct 2011 11:23:54 +0200
> Von: Petr Baudis
> An: computer-go at computer-go.org
> Betreff: [Computer-go] Multi-armed bandit problem theory
> Hi!
>
> Does anyone have a good source for understanding the theory behind
> the multi-armed bandit problem, i.e. the proof behind the exponential
> arm play bounds etc.? My only source so far is Auer et al., 2002:
> Finite-time Analysis of the Multiarmed Bandit Problem - but I suspect
> its description of the original bound is incomplete and/or simplified
> with some implicit assumptions (i.e. in case of optimal arm, the bound
> would involve division by zero?).
>
> Everyone refers to Lai & Robbins, 1985 and Agrawal, 1995, but I'm
> unable to find these papers anywhere (my university JTOR subscription
> somehow magically doesn't seem to cover Agrawal, 1995). I'm hoping
> that maybe I could grasp the details if I read those, does anyone have
> a copy?
>
> Thanks,
>
> --
> Petr "Pasky" Baudis
> We live on an island surrounded by a sea of ignorance. As our island
> of knowledge grows, so does the shore of our ignorace. -- J. A. Wheeler
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
From sukosuko1 at gmail.com Wed Oct 26 05:48:23 2011
From: sukosuko1 at gmail.com (Scott Christensen)
Date: Wed, 26 Oct 2011 20:48:23 +0800
Subject: [Computer-go] MCTS playouts per second
Message-ID:
Just want to check what the expected playout performance is of well
tuned monte-carlo engines? My MCTS engine is averaging apx 3,500
lightweight playouts per second on a single i5 32 bit cpu. Any
suggestions on very efficient source code examples for fast
monte-carlo playouts?
I've spent a lot of time comparing recursive group formation vs
non-recursive but it doesn't seem to make a big difference. It seems
that updating the list of likely moves after every play with something
similar to the mogo probability rules is the most time consuming part
as I currently recalculate the probabilities of moves at every empty
point on the board each turn. It seems necessary if one doesn't want
to handle all the exceptions to keeping the previous turn's play
probabilities.
Also any thoughts on combining pattern scoring and other conventional
techniques together with a UCT tree? If two branches have very
similar simulated win ratios could one use other factors to choose the
best branch? It seems if there is a very wide branching such as at
the beginning of the game, there is a lot of room to add other
heuristics to choosing the best move when monte-carlo scores are
within range of expected error.
From pasky at ucw.cz Wed Oct 26 05:51:02 2011
From: pasky at ucw.cz (Petr Baudis)
Date: Wed, 26 Oct 2011 14:51:02 +0200
Subject: [Computer-go] Multi-armed bandit problem theory
In-Reply-To: <20111026115603.217510@gmx.net>
References: <20111026092354.GC29324@machine.or.cz>
<20111026115603.217510@gmx.net>
Message-ID: <20111026125102.GD29324@machine.or.cz>
On Wed, Oct 26, 2011 at 01:56:03PM +0200, "Ingo Althöfer" wrote:
> Not a direct answer, but some bit of information:
> Bandit theory started in the early 1950' by Herbert Robbins
> (the same Robbins from the 1985 paper). However, he did
> not prove best possible bounds in the seminal paper.
Yes, I actually have a copy of that paper but it doesn't seem that it
could help me better understand the later results.
Petr "Pasky" Baudis
From pshotwell at gmail.com Wed Oct 26 12:50:31 2011
From: pshotwell at gmail.com (P Shotwell)
Date: Wed, 26 Oct 2011 13:50:31 -0600
Subject: [Computer-go] 2012 International Go Conference at the US
Congress
In-Reply-To:
References:
Message-ID:
Hello All,
**
*CALL FOR PAPERS/PARTICIPANTS*
*at*
*THE 2012 INTERNATIONAL GO SYMPOSIUM*
**
An International Go Symposium will take place August 3rd and 4th, 2012 at
the beginning of the U.S. Go Congress in Black Mountain, North Carolina.
Presentations can include educational, cultural, historical, literary,
artistic and scientific aspects of the game. Depending on the number and
nature of the talks, suggested timing is a half-hour presentation with a 15
minute question and answer period. Additional opportunities for questions
and answers afterwards will be available. Translators can be provided.
We are exploring the idea of expanding the usual opportunities to present
papers at go conferences to include talks via Skype with a large screen and
audience participation along with oral or texting possibilities for extended
questions and answers via the Internet. And to alleviate problems with the
differences in times, we are also thinking about including talks on DVDs or
with other pre-recorded means. Much of this will depend on the number and
quality of papers and the amount of sponsorship, so please indicate whether
you could attend with or without partial travel expenses or if you would be
interested in giving a talk via Skype or pre-recordings.
For those who wish to publish, papers can be included in an e-publication
connected with the American Go Association web site and e-Journal (
www.usgo.org). Another change from the usual proceedings of a conference is
that (again for those who wish to) papers will be put up before the
Symposium which will enable better audience participation and the ability to
write more than is possible to include in the talk.
Please contact: Peter Shotwell pshotwell at gmail.com
For reference, the beta website for the Symposium is at
http://www.gosymposium.org/ and the records of a similar ICOB Conference in
2003 is at http://www.usgo.org/yearbook/2003ICOB.html, while a 2008
Symposium in Sweden is at http://egc2008.eu/en/events/symposium.php.
We are currently reviewing our opportunities and options for sponsorship
and would appreciate any suggestions.
*If you wrote me last spring, please do so again to let me know that you
are still interestedand that there were no miscommunications.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sheppardco at aol.com Wed Oct 26 16:19:56 2011
From: sheppardco at aol.com (Brian Sheppard)
Date: Wed, 26 Oct 2011 19:19:56 -0400
Subject: [Computer-go] Multi-armed bandit problem theory
In-Reply-To: <20111026125102.GD29324@machine.or.cz>
References: <20111026092354.GC29324@machine.or.cz> <20111026115603.217510@gmx.net>
<20111026125102.GD29324@machine.or.cz>
Message-ID: <000c01cc9435$c6795640$536c02c0$@com>
I tried to find those papers once, too, and I also failed. It seems to
predate Internet publishing. Some key results were proved in the 1970's.
I think the following ideas sketch a proof:
- sample each arm infinitely often
- such that the fraction of effort going to sub-optimal arms
decreases to zero
Now look at the form of Hoeffding's inequality:
http://en.wikipedia.org/wiki/Hoeffding's_inequality. The UCB term is like
the functional inverse of the right-hand side. That is why it works for
bandit problems.
To go from bandit theory to UCT, you have to show that recursive application
of the same process converges, which is the proof that you see in the Auer
paper.
Note that there are solutions to the bandit problem that would not be
solutions for MCTS, because they do not converge recursively. E.g., you can
make an epsilon-greedy policy that works for a bandit problem ("works" ==
zero asymptotic regret), but would not converge to optimal in an MCTS
setting.
Hope this helps.
Brian
-----Original Message-----
From: computer-go-bounces at dvandva.org
[mailto:computer-go-bounces at dvandva.org] On Behalf Of Petr Baudis
Sent: Wednesday, October 26, 2011 8:51 AM
To: computer-go at dvandva.org
Subject: Re: [Computer-go] Multi-armed bandit problem theory
On Wed, Oct 26, 2011 at 01:56:03PM +0200, "Ingo Althöfer" wrote:
> Not a direct answer, but some bit of information:
> Bandit theory started in the early 1950' by Herbert Robbins
> (the same Robbins from the 1985 paper). However, he did
> not prove best possible bounds in the seminal paper.
Yes, I actually have a copy of that paper but it doesn't seem that it
could help me better understand the later results.
Petr "Pasky" Baudis
_______________________________________________
Computer-go mailing list
Computer-go at dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
From sheppardco at aol.com Wed Oct 26 16:23:34 2011
From: sheppardco at aol.com (Brian Sheppard)
Date: Wed, 26 Oct 2011 19:23:34 -0400
Subject: [Computer-go] MCTS playouts per second
In-Reply-To:
References:
Message-ID: <000d01cc9436$489411b0$d9bc3510$@com>
So-called "light" playouts might be 10x to 20x that speed. I am not sure,
but a lot faster.
"Heavy" playouts should be 2x at least. Pebbles is ~5k/sec on a single core
of a first-generation dual core CPU. Fuego, Mogo are comparable to Pebbles,
Pachi is slower but probably smarter.
Look at libego for a fast light implementation. Fuego and Pachi for good
heavy implementations.
-----Original Message-----
From: computer-go-bounces at dvandva.org
[mailto:computer-go-bounces at dvandva.org] On Behalf Of Scott Christensen
Sent: Wednesday, October 26, 2011 8:48 AM
To: computer-go at dvandva.org
Subject: [Computer-go] MCTS playouts per second
Just want to check what the expected playout performance is of well
tuned monte-carlo engines? My MCTS engine is averaging apx 3,500
lightweight playouts per second on a single i5 32 bit cpu. Any
suggestions on very efficient source code examples for fast
monte-carlo playouts?
I've spent a lot of time comparing recursive group formation vs
non-recursive but it doesn't seem to make a big difference. It seems
that updating the list of likely moves after every play with something
similar to the mogo probability rules is the most time consuming part
as I currently recalculate the probabilities of moves at every empty
point on the board each turn. It seems necessary if one doesn't want
to handle all the exceptions to keeping the previous turn's play
probabilities.
Also any thoughts on combining pattern scoring and other conventional
techniques together with a UCT tree? If two branches have very
similar simulated win ratios could one use other factors to choose the
best branch? It seems if there is a very wide branching such as at
the beginning of the game, there is a lot of room to add other
heuristics to choosing the best move when monte-carlo scores are
within range of expected error.
_______________________________________________
Computer-go mailing list
Computer-go at dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
From hideki_katoh at ybb.ne.jp Wed Oct 26 16:42:43 2011
From: hideki_katoh at ybb.ne.jp (Hideki Kato)
Date: Thu, 27 Oct 2011 08:42:43 +0900
Subject: [Computer-go] MCTS playouts per second
In-Reply-To:
References:
Message-ID: <4ea89af0.2887%hideki_katoh@ybb.ne.jp>
Zen has very slow (but very smart) heavy playout, about 1 kpo/s on a 3
GHz Intel Core2 core. One important "tenuki" for speed-up is to check
the legality of moves _after_ selecting a move, i.e., don't check the
legality of all moves before choosing a move.
Hideki
Scott Christensen: :
>Just want to check what the expected playout performance is of well
>tuned monte-carlo engines? My MCTS engine is averaging apx 3,500
>lightweight playouts per second on a single i5 32 bit cpu. Any
>suggestions on very efficient source code examples for fast
>monte-carlo playouts?
>
>I've spent a lot of time comparing recursive group formation vs
>non-recursive but it doesn't seem to make a big difference. It seems
>that updating the list of likely moves after every play with something
>similar to the mogo probability rules is the most time consuming part
>as I currently recalculate the probabilities of moves at every empty
>point on the board each turn. It seems necessary if one doesn't want
>to handle all the exceptions to keeping the previous turn's play
>probabilities.
>
>Also any thoughts on combining pattern scoring and other conventional
>techniques together with a UCT tree? If two branches have very
>similar simulated win ratios could one use other factors to choose the
>best branch? It seems if there is a very wide branching such as at
>the beginning of the game, there is a lot of room to add other
>heuristics to choosing the best move when monte-carlo scores are
>within range of expected error.
>_______________________________________________
>Computer-go mailing list
>Computer-go at dvandva.org
>http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
--
Hideki Kato
From ajahuang at gmail.com Wed Oct 26 19:23:21 2011
From: ajahuang at gmail.com (Aja Huang)
Date: Wed, 26 Oct 2011 20:23:21 -0600
Subject: [Computer-go] MCTS playouts per second
In-Reply-To:
References:
Message-ID: <8BC656768F5040B1B96715395B2D859F@ajaPC>
On 19x19, Erica's speed is around 5,500 lightweight playouts per second on a
single i7 cpu. As far as I know, Lukasz Lew's libego, which is open source,
is the fastest implementation of MCTS and can reach around 6,000-7,000
lightweight playouts per second in the same cpu.
Aja
-----原始郵件-----
From: Scott Christensen
Sent: Wednesday, October 26, 2011 6:48 AM
To: computer-go at dvandva.org
Subject: [Computer-go] MCTS playouts per second
Just want to check what the expected playout performance is of well
tuned monte-carlo engines? My MCTS engine is averaging apx 3,500
lightweight playouts per second on a single i5 32 bit cpu. Any
suggestions on very efficient source code examples for fast
monte-carlo playouts?
I've spent a lot of time comparing recursive group formation vs
non-recursive but it doesn't seem to make a big difference. It seems
that updating the list of likely moves after every play with something
similar to the mogo probability rules is the most time consuming part
as I currently recalculate the probabilities of moves at every empty
point on the board each turn. It seems necessary if one doesn't want
to handle all the exceptions to keeping the previous turn's play
probabilities.
Also any thoughts on combining pattern scoring and other conventional
techniques together with a UCT tree? If two branches have very
similar simulated win ratios could one use other factors to choose the
best branch? It seems if there is a very wide branching such as at
the beginning of the game, there is a lot of room to add other
heuristics to choosing the best move when monte-carlo scores are
within range of expected error.
_______________________________________________
Computer-go mailing list
Computer-go at dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
From sheppardco at aol.com Wed Oct 26 19:40:23 2011
From: sheppardco at aol.com (Brian Sheppard)
Date: Wed, 26 Oct 2011 22:40:23 -0400
Subject: [Computer-go] MCTS playouts per second
In-Reply-To: <8BC656768F5040B1B96715395B2D859F@ajaPC>
References:
<8BC656768F5040B1B96715395B2D859F@ajaPC>
Message-ID:
Clarification: the numbers that I quoted on my previous post were on 9x9.
-----Original Message-----
From: computer-go-bounces at dvandva.org
[mailto:computer-go-bounces at dvandva.org] On Behalf Of Aja Huang
Sent: Wednesday, October 26, 2011 10:23 PM
To: computer-go at dvandva.org
Subject: Re: [Computer-go] MCTS playouts per second
On 19x19, Erica's speed is around 5,500 lightweight playouts per second on a
single i7 cpu. As far as I know, Lukasz Lew's libego, which is open source,
is the fastest implementation of MCTS and can reach around 6,000-7,000
lightweight playouts per second in the same cpu.
Aja
-----????-----
From: Scott Christensen
Sent: Wednesday, October 26, 2011 6:48 AM
To: computer-go at dvandva.org
Subject: [Computer-go] MCTS playouts per second
Just want to check what the expected playout performance is of well tuned
monte-carlo engines? My MCTS engine is averaging apx 3,500 lightweight
playouts per second on a single i5 32 bit cpu. Any suggestions on very
efficient source code examples for fast monte-carlo playouts?
I've spent a lot of time comparing recursive group formation vs
non-recursive but it doesn't seem to make a big difference. It seems that
updating the list of likely moves after every play with something similar to
the mogo probability rules is the most time consuming part as I currently
recalculate the probabilities of moves at every empty point on the board
each turn. It seems necessary if one doesn't want to handle all the
exceptions to keeping the previous turn's play probabilities.
Also any thoughts on combining pattern scoring and other conventional
techniques together with a UCT tree? If two branches have very
similar simulated win ratios could one use other factors to choose the best
branch? It seems if there is a very wide branching such as at the beginning
of the game, there is a lot of room to add other heuristics to choosing the
best move when monte-carlo scores are within range of expected error.
_______________________________________________
Computer-go mailing list
Computer-go at dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
_______________________________________________
Computer-go mailing list
Computer-go at dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
From sukosuko1 at gmail.com Wed Oct 26 20:30:55 2011
From: sukosuko1 at gmail.com (Scott Christensen)
Date: Thu, 27 Oct 2011 11:30:55 +0800
Subject: [Computer-go] Computer-go Digest, Vol 21, Issue 16
In-Reply-To:
References:
Message-ID:
Pachi C++ source code (http://pachi.or.cz/) does appears quite
straightforward, Fuego & libego are a bit more challenging. I've
started by using ideas from Wally (available through:
http://www.usgo.org/resources/computer.html) which is probably the
most compact and easy to read code I've seen but is not very
efficient.
Thanks Hideki, I am indeed doing full liberty checks on every move in
the list, I will change to only doing the checks when selected.
Exact probability of moves after the first 6-7 moves in the tree
doesn't seem that important really.
I'm only getting the 3.5k playouts/sec on 9x9, It would seem with apx
5k playouts on 19x19, for 9x9 we should around 50-100k playouts.
From ddyer at real-me.net Wed Oct 26 22:56:37 2011
From: ddyer at real-me.net (Dave Dyer)
Date: Wed, 26 Oct 2011 22:56:37 -0700
Subject: [Computer-go] another UCT bot
Message-ID:
I've deployed a reasonably strong UCT bot at boardspace.net for
Fanorona (the "bestbot").
UCT worked really well in the opening phases of the game, but in endgame
positions (which are very positional) it tended to meander and eventually
draw, even in positions where it had an overwhelming numerical advantage
and an obvious (to humans) line of play.
I tried various things to tweak it's endgame, including various hacks
to prune or shape the move tree; and also (as an experiment) running
the search for an absurd amount of time. None worked reliably.
It seems to be an intrinsic property of this game that end games give a
very weak "win" signal with random playouts. I suspect this is also the
case with the opening phases of Go.
The hack I eventually developed was to add a small top-level bias based
on the static evaluator, which kicks the "all look the same" endgame
moves in the right direction most of the time. Since this is done
only once on root node, this has no impact on the overall speed.
The biggest problem with UCT in general is that there aren't
very many knobs to tweak - there's no obvious way to add knowledge
if you don't like the current results.
From sheppardco at aol.com Thu Oct 27 05:55:56 2011
From: sheppardco at aol.com (Brian Sheppard)
Date: Thu, 27 Oct 2011 08:55:56 -0400
Subject: [Computer-go] another UCT bot
In-Reply-To: <20111027055720.83524BD019@dvandva.org>
References: <20111027055720.83524BD019@dvandva.org>
Message-ID:
> there's no obvious way to add knowledge if you don't like the current
results
You have missed a key point. UCT is an ideal framework for integrating many
potentially incomplete, contradictory, or even potentially wrong, knowledge
sources. There are a zillion ways to add knowledge, and UCT guarantees that
you won't pay an asymptotic price.
Prior to MCTS, GO programmers would build rules and patterns, which would
make their Go programs better but brittle. Inside an MCTS framework,
however, creating new patterns is almost risk-free. If the pattern works,
then it helps the program, and if it doesn't work then UCT quickly ignores
it in *that* position.
Build a rule base that biases move selection in the tree portion of the
playout. Encode all of your human understanding there. Represent the
strength of the rules as your initial W/L counters.
From michaelwilliams75 at gmail.com Thu Oct 27 16:18:34 2011
From: michaelwilliams75 at gmail.com (Michael Williams)
Date: Thu, 27 Oct 2011 19:18:34 -0400
Subject: [Computer-go] MCTS playouts per second
In-Reply-To: <8BC656768F5040B1B96715395B2D859F@ajaPC>
References:
<8BC656768F5040B1B96715395B2D859F@ajaPC>
Message-ID:
Perhaps you meant to say 60,000-70,000 playouts per second for libego?
On Wed, Oct 26, 2011 at 10:23 PM, Aja Huang wrote:
> On 19x19, Erica's speed is around 5,500 lightweight playouts per second on
> a single i7 cpu. As far as I know, Lukasz Lew's libego, which is open
> source, is the fastest implementation of MCTS and can reach around
> 6,000-7,000 lightweight playouts per second in the same cpu.
>
> Aja
>
> -----原始郵件----- From: Scott Christensen
>
> Sent: Wednesday, October 26, 2011 6:48 AM
> To: computer-go at dvandva.org
> Subject: [Computer-go] MCTS playouts per second
>
> Just want to check what the expected playout performance is of well
> tuned monte-carlo engines? My MCTS engine is averaging apx 3,500
> lightweight playouts per second on a single i5 32 bit cpu. Any
> suggestions on very efficient source code examples for fast
> monte-carlo playouts?
>
> I've spent a lot of time comparing recursive group formation vs
> non-recursive but it doesn't seem to make a big difference. It seems
> that updating the list of likely moves after every play with something
> similar to the mogo probability rules is the most time consuming part
> as I currently recalculate the probabilities of moves at every empty
> point on the board each turn. It seems necessary if one doesn't want
> to handle all the exceptions to keeping the previous turn's play
> probabilities.
>
> Also any thoughts on combining pattern scoring and other conventional
> techniques together with a UCT tree? If two branches have very
> similar simulated win ratios could one use other factors to choose the
> best branch? It seems if there is a very wide branching such as at
> the beginning of the game, there is a lot of room to add other
> heuristics to choosing the best move when monte-carlo scores are
> within range of expected error.
> ______________________________**_________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/**mailman/listinfo/computer-go
> ______________________________**_________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/**mailman/listinfo/computer-go
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ajahuang at gmail.com Thu Oct 27 21:30:16 2011
From: ajahuang at gmail.com (Aja Huang)
Date: Thu, 27 Oct 2011 22:30:16 -0600
Subject: [Computer-go] MCTS playouts per second
In-Reply-To:
References: <8BC656768F5040B1B96715395B2D859F@ajaPC>
Message-ID: <2289DDB51148436A8AF3EB8CE84D327C@userPC>
No, I meant 6,000-7,000 playouts per second on 19x19.
Aja
From: Michael Williams
Sent: Thursday, October 27, 2011 5:18 PM
To: computer-go at dvandva.org
Subject: Re: [Computer-go] MCTS playouts per second
Perhaps you meant to say 60,000-70,000 playouts per second for libego?
On Wed, Oct 26, 2011 at 10:23 PM, Aja Huang wrote:
On 19x19, Erica's speed is around 5,500 lightweight playouts per second on a single i7 cpu. As far as I know, Lukasz Lew's libego, which is open source, is the fastest implementation of MCTS and can reach around 6,000-7,000 lightweight playouts per second in the same cpu.
Aja
-----原始郵件----- From: Scott Christensen
Sent: Wednesday, October 26, 2011 6:48 AM
To: computer-go at dvandva.org
Subject: [Computer-go] MCTS playouts per second
Just want to check what the expected playout performance is of well
tuned monte-carlo engines? My MCTS engine is averaging apx 3,500
lightweight playouts per second on a single i5 32 bit cpu. Any
suggestions on very efficient source code examples for fast
monte-carlo playouts?
I've spent a lot of time comparing recursive group formation vs
non-recursive but it doesn't seem to make a big difference. It seems
that updating the list of likely moves after every play with something
similar to the mogo probability rules is the most time consuming part
as I currently recalculate the probabilities of moves at every empty
point on the board each turn. It seems necessary if one doesn't want
to handle all the exceptions to keeping the previous turn's play
probabilities.
Also any thoughts on combining pattern scoring and other conventional
techniques together with a UCT tree? If two branches have very
similar simulated win ratios could one use other factors to choose the
best branch? It seems if there is a very wide branching such as at
the beginning of the game, there is a lot of room to add other
heuristics to choosing the best move when monte-carlo scores are
within range of expected error.
_______________________________________________
Computer-go mailing list
Computer-go at dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
_______________________________________________
Computer-go mailing list
Computer-go at dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
--------------------------------------------------------------------------------
_______________________________________________
Computer-go mailing list
Computer-go at dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Remi.Coulom at free.fr Fri Oct 28 13:33:12 2011
From: Remi.Coulom at free.fr (=?iso-8859-1?Q?R=E9mi_Coulom?=)
Date: Fri, 28 Oct 2011 22:33:12 +0200
Subject: [Computer-go] MCTS playouts per second
In-Reply-To: <2289DDB51148436A8AF3EB8CE84D327C@userPC>
References: <8BC656768F5040B1B96715395B2D859F@ajaPC>
<2289DDB51148436A8AF3EB8CE84D327C@userPC>
Message-ID: <18966BC9-AF68-4F6E-94A2-2E5984D38317@free.fr>
I think it is more like 100k on 9x9, and 25k on 19x19
http://www.mail-archive.com/computer-go at computer-go.org/msg11214.html
Rémi
On 28 oct. 2011, at 06:30, Aja Huang wrote:
> No, I meant 6,000-7,000 playouts per second on 19x19.
>
> Aja
>
> From: Michael Williams
> Sent: Thursday, October 27, 2011 5:18 PM
> To: computer-go at dvandva.org
> Subject: Re: [Computer-go] MCTS playouts per second
>
> Perhaps you meant to say 60,000-70,000 playouts per second for libego?
>
>
> On Wed, Oct 26, 2011 at 10:23 PM, Aja Huang wrote:
> On 19x19, Erica's speed is around 5,500 lightweight playouts per second on a single i7 cpu. As far as I know, Lukasz Lew's libego, which is open source, is the fastest implementation of MCTS and can reach around 6,000-7,000 lightweight playouts per second in the same cpu.
>
> Aja
>
> -----原始郵件----- From: Scott Christensen
>
> Sent: Wednesday, October 26, 2011 6:48 AM
> To: computer-go at dvandva.org
> Subject: [Computer-go] MCTS playouts per second
>
> Just want to check what the expected playout performance is of well
> tuned monte-carlo engines? My MCTS engine is averaging apx 3,500
> lightweight playouts per second on a single i5 32 bit cpu. Any
> suggestions on very efficient source code examples for fast
> monte-carlo playouts?
>
> I've spent a lot of time comparing recursive group formation vs
> non-recursive but it doesn't seem to make a big difference. It seems
> that updating the list of likely moves after every play with something
> similar to the mogo probability rules is the most time consuming part
> as I currently recalculate the probabilities of moves at every empty
> point on the board each turn. It seems necessary if one doesn't want
> to handle all the exceptions to keeping the previous turn's play
> probabilities.
>
> Also any thoughts on combining pattern scoring and other conventional
> techniques together with a UCT tree? If two branches have very
> similar simulated win ratios could one use other factors to choose the
> best branch? It seems if there is a very wide branching such as at
> the beginning of the game, there is a lot of room to add other
> heuristics to choosing the best move when monte-carlo scores are
> within range of expected error.
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>
>
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
From ddyer at real-me.net Fri Oct 28 14:02:28 2011
From: ddyer at real-me.net (Dave Dyer)
Date: Fri, 28 Oct 2011 14:02:28 -0700
Subject: [Computer-go] another UCT bot
In-Reply-To:
References: <20111027055720.83524BD019@dvandva.org>
Message-ID:
>You have missed a key point. UCT is an ideal framework for integrating many
>potentially incomplete, contradictory, or even potentially wrong, knowledge
>sources. There are a zillion ways to add knowledge, and UCT guarantees that
>you won't pay an asymptotic price.
With random playouts, there is no place to add knowledge.
With heavier playouts, the "signal" from the win rate can still
be very weak, or even wrong.
UCT is particularly weak when a timely move is required - making the
correct move 2 moves later looks 99% as good as making it immediately.
From ajahuang at gmail.com Fri Oct 28 14:22:10 2011
From: ajahuang at gmail.com (Aja Huang)
Date: Fri, 28 Oct 2011 15:22:10 -0600
Subject: [Computer-go] MCTS playouts per second
In-Reply-To: <18966BC9-AF68-4F6E-94A2-2E5984D38317@free.fr>
References: <8BC656768F5040B1B96715395B2D859F@ajaPC><2289DDB51148436A8AF3EB8CE84D327C@userPC>
<18966BC9-AF68-4F6E-94A2-2E5984D38317@free.fr>
Message-ID:
Thanks Rémi's clarification. I forgot that 6,000-7,000 playouts per second
is with supporting weighted moves globally and incrementally updating
various data structures, not pure uniform random playouts. If I recall
correctly, Lukasz's implementation was 1,000-2,000 playouts per second
faster than mine.
Aja
-----原始郵件-----
From: Rémi Coulom
Sent: Friday, October 28, 2011 2:33 PM
To: computer-go at dvandva.org
Subject: Re: [Computer-go] MCTS playouts per second
I think it is more like 100k on 9x9, and 25k on 19x19
http://www.mail-archive.com/computer-go at computer-go.org/msg11214.html
Rémi
On 28 oct. 2011, at 06:30, Aja Huang wrote:
> No, I meant 6,000-7,000 playouts per second on 19x19.
>
> Aja
>
> From: Michael Williams
> Sent: Thursday, October 27, 2011 5:18 PM
> To: computer-go at dvandva.org
> Subject: Re: [Computer-go] MCTS playouts per second
>
> Perhaps you meant to say 60,000-70,000 playouts per second for libego?
>
>
> On Wed, Oct 26, 2011 at 10:23 PM, Aja Huang wrote:
> On 19x19, Erica's speed is around 5,500 lightweight playouts per second on
> a single i7 cpu. As far as I know, Lukasz Lew's libego, which is open
> source, is the fastest implementation of MCTS and can reach around
> 6,000-7,000 lightweight playouts per second in the same cpu.
>
> Aja
>
> -----原始郵件----- From: Scott Christensen
>
> Sent: Wednesday, October 26, 2011 6:48 AM
> To: computer-go at dvandva.org
> Subject: [Computer-go] MCTS playouts per second
>
> Just want to check what the expected playout performance is of well
> tuned monte-carlo engines? My MCTS engine is averaging apx 3,500
> lightweight playouts per second on a single i5 32 bit cpu. Any
> suggestions on very efficient source code examples for fast
> monte-carlo playouts?
>
> I've spent a lot of time comparing recursive group formation vs
> non-recursive but it doesn't seem to make a big difference. It seems
> that updating the list of likely moves after every play with something
> similar to the mogo probability rules is the most time consuming part
> as I currently recalculate the probabilities of moves at every empty
> point on the board each turn. It seems necessary if one doesn't want
> to handle all the exceptions to keeping the previous turn's play
> probabilities.
>
> Also any thoughts on combining pattern scoring and other conventional
> techniques together with a UCT tree? If two branches have very
> similar simulated win ratios could one use other factors to choose the
> best branch? It seems if there is a very wide branching such as at
> the beginning of the game, there is a lot of room to add other
> heuristics to choosing the best move when monte-carlo scores are
> within range of expected error.
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>
>
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
_______________________________________________
Computer-go mailing list
Computer-go at dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
From pasky at ucw.cz Fri Oct 28 14:23:25 2011
From: pasky at ucw.cz (Petr Baudis)
Date: Fri, 28 Oct 2011 23:23:25 +0200
Subject: [Computer-go] another UCT bot
In-Reply-To: <20111028210254.491D8BD11B@dvandva.org>
References: <20111027055720.83524BD019@dvandva.org>
<20111028210254.491D8BD11B@dvandva.org>
Message-ID: <20111028212325.GE29324@machine.or.cz>
On Fri, Oct 28, 2011 at 02:02:28PM -0700, Dave Dyer wrote:
>
> >You have missed a key point. UCT is an ideal framework for integrating many
> >potentially incomplete, contradictory, or even potentially wrong, knowledge
> >sources. There are a zillion ways to add knowledge, and UCT guarantees that
> >you won't pay an asymptotic price.
>
>
> With random playouts, there is no place to add knowledge.
Huh, what about node priors?
> With heavier playouts, the "signal" from the win rate can still
> be very weak, or even wrong.
Of course, if it couldn't be wrong, we would have perfect programs. :)
My experience is that RAVE biases moves by knowledge much more strongly
than UCT, since frequent heavy playout choices are greatly magnified.
> UCT is particularly weak when a timely move is required - making the
> correct move 2 moves later looks 99% as good as making it immediately.
I can't remember hitting anything like that much.
It ain't always easy to integrate knowledge in UCT, but while I don't
have much practical experience with other game tree search algorithms,
I'd imagine it's even trickier with the classic evaluation function
approach.
--
Petr "Pasky" Baudis
We live on an island surrounded by a sea of ignorance. As our island
of knowledge grows, so does the shore of our ignorace. -- J. A. Wheeler
From sheppardco at aol.com Fri Oct 28 15:29:12 2011
From: sheppardco at aol.com (Brian Sheppard)
Date: Fri, 28 Oct 2011 18:29:12 -0400
Subject: [Computer-go] another UCT bot
In-Reply-To: <20111028210252.3C512BD118@dvandva.org>
References: <20111027055720.83524BD019@dvandva.org>
<20111028210252.3C512BD118@dvandva.org>
Message-ID: <001001cc95c1$04ff9ff0$0efedfd0$@com>
>With random playouts, there is no place to add knowledge.
In the UCT priors. These are the initial values given to moves in the UCT
tree when a node is created.
Random playouts have significant opportunity to add knowledge. For example,
Erica's skill is largely derived from the probability distribution given to
3x3 patterns.
From hideki_katoh at ybb.ne.jp Fri Oct 28 17:48:33 2011
From: hideki_katoh at ybb.ne.jp (Hideki Kato)
Date: Sat, 29 Oct 2011 09:48:33 +0900
Subject: [Computer-go] Computer-go Digest, Vol 21, Issue 16
In-Reply-To:
References:
Message-ID: <4eab4cb7.2898%hideki_katoh@ybb.ne.jp>
Scott Christensen: :
>Pachi C++ source code (http://pachi.or.cz/) does appears quite
>straightforward, Fuego & libego are a bit more challenging. I've
>started by using ideas from Wally (available through:
>http://www.usgo.org/resources/computer.html) which is probably the
>most compact and easy to read code I've seen but is not very
>efficient.
>
>Thanks Hideki, I am indeed doing full liberty checks on every move in
>the list, I will change to only doing the checks when selected.
>Exact probability of moves after the first 6-7 moves in the tree
>doesn't seem that important really.
Not liberty but legality, right?
Just to clarify: Zen's "heavy" playout speed is evaluated on an empty
19x19 board.
Hideki
>I'm only getting the 3.5k playouts/sec on 9x9, It would seem with apx
>5k playouts on 19x19, for 9x9 we should around 50-100k playouts.
>_______________________________________________
>Computer-go mailing list
>Computer-go at dvandva.org
>http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
--
Hideki Kato