Hi;
C*RAVE+(1-C)*UCT
This has been my understanding. However, I am surprized to find out that
people have been setting C close to one, according to Petr and Oliver's
postings, which is essentially AMAF. MF apparently is doing something
different.
As explained by Aja, I did not mean
Olivier Teytaud: aanlktinf9u93g--naoe2u+h4utvkow1kgcrvgssxk...@mail.gmail.com:
The GTP script for NNGS was available for testing weeks before the
competition. I was surprised that the Mogo team showed up for the
competition with having done any testing before hand.
Only the operator was
In your survey, the spread for a super-human program, from those that
correctly predicted 2010 for shodan,
is from 2023 to 2150.
So even between the best predictors sofar, there was huge disagreement
when it comes topling humanity ...
I guess current knowledge of the effectiveness and
Hi!
On Sun, Jan 02, 2011 at 03:53:32PM +0800, Aja wrote:
I guess it should be not * 3000 but / 3000.
Zen also uses this type of formula, but the constant value is rather
small. I use 400 for the latest version of Zen.
If you are right, then it makes sense. For /3000, bias is around
Hi Olivier,
Thanks for all your corrections and detailed replies. I agree with them. If you
think it's OK, I would like to describe Mogo's contributions in my thesis
according to what you enumerated and explained.
Considering and responding to the previous move in simulation, especially
These days, programs of Crazy Stone thread, like Zen, Erica, Aya...etc, do
stochastic simulation, different with Mogo-type, fixed-sequence simulation.
I think CrazyStone's update formula allows more flexibility than the
pattern-based approach of MoGo. So it has better potential;
I have no idea
Hi Olivier,
I forgot that you also contributed to Mogo's pattern design, besides Sylvain
and Yizao. Sorry for neglecting your contribution. :)
Actually I make fillboard and nakade as features in Erica and they work
fine. But indeed, efficiency is a problem in our probabilistic simulation.
On 1 janv. 2011, at 23:11, Erik van der Werf wrote:
Mogo's biggest contributions, so far, in my view, are
1.Applied UCT to computer Go, and such application came from the idea
MCTS that proposed in 2006 by Remi Coulom.
No, it came directly from Levente. Several people got access to his
Sorry for neglecting your contribution. :)
You can neglect mine, no problem with that, it's a reality :-)
Actually I make fillboard and nakade as features in Erica and they work
fine. But indeed, efficiency is a problem in our probabilistic simulation.
For us fillboard = around 80% with
Hi Aja,
On Sun, Jan 2, 2011 at 1:29 AM, Aja ajahu...@gmail.com wrote:
Hi Fuming,
C*RAVE+(1-C)*UCT
C is computed dynamically in search, but not set to a fixed value. Maybe
you mean UCT_C,
UCT=UCT_mean+UCT_C*exploration_term
What Petr and Olivier do, I think, is set UCT_C to 0, to
80% is a big improvement. Indeed, I don't get that much in Erica.
Aja
- Original Message -
From: Olivier Teytaud
To: Aja ; computer-go
Sent: Sunday, January 02, 2011 9:04 PM
Subject: Re: [Computer-go] Fwd: News on Tromp-Cook ?
Sorry for neglecting your contribution.
Hi Fuming,
I agree with your understanding. As for the naming of UCT, I think it's fine,
because we can just view such formula as assigned with zero coefficient of the
exploration term.
Aja
- Original Message -
From: Fuming Wang
To: Aja
Cc: computer-go@dvandva.org
Sent:
On Sun, Jan 2, 2011 at 1:20 AM, Aja ajahu...@gmail.com wrote:
Do you mean the whole MCTS scheme combined with UCB formula
proposed by Mogo is completely inspried by Levente's work?
I cannot speak for the Mogo team, but it is clear to me that the idea
was simply 'out there' when Mogo started and
Yamato and I have independently started development of Zen and FudoGo
(resp) with sharing the same idea*, combining MoGo's sequence-like
simulation policy and CrazyStone's larger patterns, though later Zen
uses more complicated policy.
*This is one of the reasons I have started the joint project
On Sun, Jan 2, 2011 at 10:31 AM, Olivier Teytaud olivier.teyt...@lri.fr wrote:
mogo's MC was implemented in many
strong programs, and influenced the MC of all other
strong programs. I think there's no exception to this. I was personally of
little influence on that, but I was here for clearly
Aja wrote:
Yamato and I have independently started development of Zen and FudoGo
(resp) with sharing the same idea*, combining MoGo's sequence-like
simulation policy and CrazyStone's larger patterns, though later Zen
uses more complicated policy.
*This is one of the reasons I have started
On Sun, Jan 2, 2011 at 4:41 PM, Olivier Teytaud olivier.teyt...@lri.fr wrote:
The playout policy I used in the 2007 version of Steenvreter was
developed independently of the Mogo policy. However, some time after
the olympiad I also implemented Mogo's version for comparison. IIRC
the policy
Is there the interest or possibility of a Web-bot tournament?**
regards
Jonathan Chetwynd
http://www.peepo.com is temporarily stable,
hosting a recent version of Fuego,
with territory visualisation as subtle colour gradients.
**benefits would be around searchability and profile,
ie enabling
When searching for start-of-the-art of Computer Go for my thesis, I
discovered a very interesting paper Combinatorics of Go by John Tromp and
Gunnar Farneback. I wonder if it is the same John Tromp that played with
Many Faces. If I understand correctly, they computed the State-space
How then, under Japanese style rules, do you detect an occurrence of a long
cycle for the sake of applying the no result rule(s)?
Maybe I don't know exactly the rules :-) I believed that the game can
cycle and we just stop if both players agree for stopping.
If the rules state that in case
On 01/02/2011 10:17 AM, Erik van der Werf wrote:
The playout policy I used in the 2007 version of Steenvreter was
developed independently of the Mogo policy.
Did this policy include the idea of sequences (playing near the last
move), and if so, was that developed independently?
Memories
I cannot speak for the Mogo team, but it is clear to me that the idea
was simply 'out there' when Mogo started and they had access to it
through the various research communities (Machine learning, Computer
games, etc.). I guess at least one of their supervisors most have had
some contacts with
On Sun, Jan 2, 2011 at 8:15 PM, Robert Jasiek jas...@snafu.de wrote:
On 02.01.2011 18:26, Olivier Teytaud wrote:
In japanese rules, there's only the ko to be kept in the state space.
How then, under Japanese style rules, do you detect an occurrence of a long
cycle for the sake of applying
On Sun, Jan 2, 2011 at 8:52 PM, Jeff Nowakowski j...@dilacero.org wrote:
On 01/02/2011 10:17 AM, Erik van der Werf wrote:
The playout policy I used in the 2007 version of Steenvreter was
developed independently of the Mogo policy.
Did this policy include the idea of sequences (playing near
Hi Erik,
My reason for posting was not to brag. It was my own choice not to
publish, so I accept it when laymen forget about Steenvreter. However,
I think a guy like Jan Willemson, who's now almost entirely written
out of the history of MCTS, really deserved some credit.
Many people will
Hi Aja,
On Mon, Jan 3, 2011 at 1:28 AM, Aja ajahu...@gmail.com wrote:
Many people will be very interested if you publish something about
Steenvreter. Beating Mogo without learning Mogo's paper at that time? That's
incredible. :)
Well, that's not exactly true either. I did of course read some
On 01/02/2011 05:24 PM, Erik van der Werf wrote:
Agreed, as long as you don't deny things that were out there long
before someone wrote 'the' paper. I have seen a rather natural
progression from work of Brugman, Kaminski, Bouzy, Helmstetter,
Hamlen, etc. to where we are today. Pinpointing the
Aja wrote:
Zen uses sequence-like AND probabilistic simulation.
Basically it plays around the previous move randomly like MoGo, and these
moves are biased by gamma values like Crazy Stone.
I am also trying to use probabilistic simulation on the whole board, but
it does not yet succeed. The
Hi Erik,
From your words, I think the main reason that Steenvreter defeated Mogo and
Crazy Stone is that Steenvreter handled life and death, seki and nakade much
better than them. Still, many people will be interested if you publish
something about I had a bit different philosophy on what the
Aja wrote:
I suppose that probabilistic simulation on the whole board is not suitable
for some sort of heuristics, like seki, long semeai or ladder-safe.
Does Erica handle those in the playouts correctly?
It's not true. Erica handle seki, semeai and ladder in the playouts combined
with
On 02.01.2011 22:04, Erik van der Werf wrote:
to 'not return a result' you don't need the history.
How? A cycle is a presupposition for the result No Result (or long cycle
tie). (Of course, hashing by numbers of stones on the board or Cycle
Law's prisoner difference etc. may often be
31 matches
Mail list logo
