Hello all.
I've been lurking on the list for a few years now. In amongst the usual musings
on the meaning of AI and social justice, etc., there's been a sharp increase in
the amount of useful information posted here of late. I'll try to contribute.
My engine is AntIgo. It's been a speed bump
I should clarify here
//4. At every move, I update the pseudo liberties, group membership, stone
counts,
//and empty spaces list. When a stone is removed due to capture, I place that
position
//at the end of the empty spaces list. When a stone is added, the space it's
about to
// occupy is
I would like to see handicap games on CGOS.
AntIgo-4, playing on CGOS, uses MC/UCT and considers only win vs. loss,
ignoring margin of victory. I used a faster, dumber version of it to play a
number of handicap games against even weaker engines on 9x9 boards. To make a
long story s
Here is a way to make a slightly smarter (and much prettier) random
player. It is good for MC playout games too. For the first 20 or so plys,
restrict the board spaces that can be filled to those commonly seen in human
games.
Below is a table for 9x9 games (trained from SGF files)
File attached. And also inline below
Dave Hillis
antminder on KGS
1| 21 21 21 21 21 21 21 21 21 21 21 21 21 21
21 21 21 21 21
2| 21 18868 12 17 17 21 21 21 17 17 12
868 18 21
3| 218.
A more detailed version.
1| 208 110 63 89 93 104 106 98 117 139 117 98 106 104
93 89 63 110 208
2| 110 18868 12 17 17 22 39 22 17 17 12
868 18 110
3| 638...26645
This seems clean and reasonable to me. (Or you could just as easily have
the server do the adjustment and set Komi to 3.5; that would also be consistent
with TT rules). If my bot sees 2 black moves in a row, it can figure out it's
in a handicap game.
A bigger question to me is, how l
AntIgo does exactly this and I still get complaints. I think this is
perfect manners on CGOS (none of the other bots have objected) but poor manners
on KGS. It's less annoying, to be sure, but still annoying.
People can get ticked off when it resigns too. They might want to see the
An alternative (also maddening to tune) is to make the playout strength
asymmetrical. For a high handicap game, making the playout rules for black
stones lighter (more random) can make the bot play serious moves where
otherwise it would see every move as having the same outcome. The implicit
as
It's almost always better to just write your own. Or you might want to consider
using a particle swarm optimizer instead.
http://www particleswarm.info/Standard_PSO_2006.c?has source code I found
useful.
http://www.particleswarm.info/Programs.html?has lots of other implementations
to choose from
Don,
You may, very well, turn out to be right in the end, but I think you are
getting ahead of the data here. And it isn't at all clear to me to how
meaningfully we can compare strength of playouts with strength of alpha-beta
evaluators.
This continues to be a very interesting study a
AntIgo
light playouts
1K 14 / 50
10K 25 / 50
100K 29 / 50
heavy playouts
1K 25 / 50
10K 32 / 50
100K 35 / 50
The numbers are noisey, because I'm too lazy to average multiple trials. In
some cases, my engine picks the correct move (and I score it as correct), but
it also thinks that blac
> -Original Message-
> From: Magnus Persson [EMAIL PROTECTED]
.> ..?
> A side note. Is it only me who are a little annoyed when strong programs play
> with names that are impossible(for examlple
> test-81725) to understand? Do not forget to add an entry on sensei at
> http://senseis.xmp
Hello,
> 3) What sort of algorithm is used to match patterns once you have mined them
> from some data source?
There are relatively few possible 3x3 patterns, so it is easy to make a look up
table with an entry for every possible pattern.
For larger patterns, it's more complicated. Mined pat
For those currently coding this up, I think the most important thing about this
playout algorithm is that it is *temporary*. You will almost certainly
be?replacing it with something different and better just a little bit down the
road.
Creating an MC-UCT bot has a well worn path and its kind of
> -Original Message-
> From: Jacques Basaldúa <[EMAIL PROTECTED]>
> To: computer-go@computer-go.org
> Sent: Wed, 14 May 2008 6:38 am
> Subject: Re: [computer-go] 10k UCT bots
> Don Dailey wrote:
> > [EMAIL PROTECTED] wrote:
> >> For those currently coding this up, I think the most i
You can use a windowed average where the window is a fixed fraction (say the
last third) of the total times the move was made. I have often used an IIR
filter and have never yet been able to prove that it actually helped. If I
could write a decent Kalman filter, I would give that a try.
- Dave
Cool! Now for the cases where I'd want a Kalman filter, I'd need it to predict
the future state of a non-stationary, multimodal distribution. A typical
pattern is for a node to start out with optimistic scores but to experience a
strong pessimistic trend later as UCT starts to focus more on effe
> -Original Message-
> From: Jason House <[EMAIL PROTECTED]>
> On Jun 26, 2008, at 3:23 PM, [EMAIL PROTECTED] wrote:
Cool! Now for the cases where I'd want a Kalman filter, I'd need it to predict
the future state of a non-stationary, multimodal distribution. A typical
pattern is for
I? use proximity in the heavy playouts themselves. I think most (all?)?people
do this.?I have a precalculated table with the 3x3 and 5x5 neighbors for every
position on the board.?
- Dave Hillis
-Original Message-
From: Jason House <[EMAIL PROTECTED]>
To: computer-go
Sent: Mon, 21 Jul
I've tried both MoGo and CrazyStone style playouts. I find MoGo style playouts
easier to work with. YMMV.
My MoGo style heavy playouts are about 4 times slower than my light playouts.
- Dave Hillis
-Original Message-
From: Jason House <[EMAIL PROTECTED]>
To: computer-go
Sent: Mon, 21
The people with stronger programs and more full-board experience will be better
positioned to comment on this. I'll say that the two styles both need a lot of
tweaking, making it hard to establish a fair test between them.
It's good to be able to match a 3x3 pattern very quickly. Since there are
That was a great page while it lasted! Sure it could have been tweaked some
more;?probably the ultra-blitz games shouldn't?be counted. The fundamental
problem with deriving a bot's rating from 9x9 KGS games is that the people
involved tend not to play seriously. But it was still fun.
- Dave Hil
Something that has worked well in other games would be to change the third CGOS
every month. Each month, the parameters would be announced and the CGOS started
empty except for the anchor(s). At the end of the month, the bot at the
top?would be?the winner. That would allow us to experiment with
> -Original Message-
> From: Don Dailey <[EMAIL PROTECTED]>
> To: computer-go
> Sent: Mon, 11 Aug 2008 11:09 pm
> Subject: Re: [computer-go] Re: What's happening at the European Go Congress?
> On Tue, 2008-08-12 at 11:50 +0900, Darren Cook wrote:
> > > Also, if you are down 8 or 9 stone
Yes, I tried heavy playouts for N plys, then switching to light.?It didn't
really speed things up all that much but it weakened my bot quite a bit, on a
per playout basis, resulting in a clear net loss.
?
I tried ladder reading for the first N plys, then no ladder reading. The
results were muddl
Raises hand. Chinese rules version for 9x9 and 13x13 would be quite helpful if
that's what you are offering. Different komi would be fine.
- Dave Hillis
-Original Message-
From: Darren Cook <[EMAIL PROTECTED]>
To: computer-go
Sent: Sat, 6 Sep 2008 10:33 pm
Subject: Re: [computer-go] se
There is a discussion at godiscussions
http://www.godiscussions.com/forum/showthread.php?t=7154
?The sgf's for the two games played are on page 2
Dave Hillis
-Original Message-
From: mingwu <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]; computer-go
Sent: Sun, 21 Sep 2008 9:22 pm
Subject: Re:
I agree with much of what you say (to the degree that anyone needs to "agree"
with questions).
The discussions on this list dealing with "ownership maps", RAVE and AMAF have
to do with using additional information from the playouts.
Playouts can't be "unbiased." Picking a move with uniform prob
It depends on your definition of real-time. A play-by-email target, such as the
Dragon Go Server is pretty flexible about scheduling moves. The project could
do what many people do and play several games in parallel. Each participating
computer would get a slice of multiple games to process in a
Going from memory, that all looks right. (We've been calling it a "pseudo
eye".)
There's no need to do this, but for what it's worth, if you make a histogram of
the scores,
- you should only get odd scores
- there should be big spikes at the tails (+/- 81)
- there should be a Gaussian-looking
I checked my notes. For Light playouts
---
average game length 111 (including final 2 passes)
not counting passes 107
---
When these numbers match, it's a pretty strong sign that the implementation is
correct (particularly the eye rule).
- Dave Hillis
-Original Message-
From: Jason House
>>> The http://shootout.alioth.debian.org/ site, ...?
>>>?
>>> If we, as a community, could come up with a sufficiently detailed?
>>> description of light playouts algorithm (see the current "Light?
>>> simulation : Characteristic values" thread), there is no reason that?
>>> this algorithm couldn'
Computers + random = can of worms.
What if I get a fast benchmark by implementing the fastest, most awful, random
number generator imaginable? What if every one of my "random" playouts looks
the disturbingly similar?
As to the relevance, the time-eaters in my heavy playouts are different from
There is a de facto standard light playout policy (algorithm). If you want to
adhere to this standard, then by definition, there are correct and incorrect
ways to do so. If you just want to design a better playout policy, naturally
anything is fair game. But how are you going to measure whether
11. When selecting moves to play in the actual game (not playouts)
superko is checked and forbidden.
positional superko (as opposed to situational superko).
- Dave Hillis
-Original Message-
From: Don Dailey <[EMAIL PROTECTED]>
To: computer-go
Sent: Sat, 11 Oct 2008 9:11 am
Subjec
David,
A while back, Don did a 9x9 scalability study (before this one
http://cgos.boardspace.net/study/index.html) comparing light versus heavy
playouts. The light playouts didn't?scale badly, they didn't plateau early,
they just?weren't as strong?as the heavy ones. There was nothing to suggest
Core Wars , robot soccer (there is a simulation league), pictionary,...
- Dave Hillis
?
- Original Message - From: "Darren Cook" <[EMAIL PROTECTED]>?
To: ?
Sent: Monday, October 27, 2008 8:54 PM?
Subject: Re: [computer-go] OT: Harder than go??
?
>>> Where "harder" means the gap between t
Go81 by Tapani Raiko used decaying move weight values as part of AMAF. He
published his source code, and a paper in 2004. Both are?well worth reading.
- Dave Hillis
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mai
Yes, the best combination for my program, Antigo, is to use (somewhat) more
stochastic
moves for the first 5-9 ply.
I decided to look into this after noticing how surprisingly badly my heavy
playouts
did as part of AMAF without UCT/tree search. A more stochastic version of my
heavy
pla
It's not auspicious. Last season, some poor computer chess developer got
assassinated, and this episode a computer go start-up got violently taken
apart. And this was at the hands of the good guys!
-Dave Hillis
-Original Message-
From: Michael Williams <[EMAIL PROTECTED]>
To: computer-
I would be very interested to see the RAVE code?from Valkyria. I'm sure others
would be too.
- Dave Hillis
-Original Message-
From: Magnus Persson <[EMAIL PROTECTED]>
To: computer-go@computer-go.org
Sent: Fri, 28 Nov 2008 8:58 am
Subject: Re: [computer-go] RAVE formula of David Silver (
There is another speedup trick that might interest you. IIRC Lukasz Lew came up
with it, but I forget what he called it. After calculating the selected move
for an internal node (going through UCT and RAVE and whatnot) store that move.
Then, for the next N visits to that node (where N is 5 or 10
Hmm.. it could be that N is picked randomly each time... now I can't seem to
find the description and my memory is not serving me well here. Perhaps someone
else remembers? I'll try to track it down.
- Dave Hillis
-Original Message-
From: Michael Williams <[EMAIL PROTECTED]>
To: comput
Finally got a window of time. It's called the "epsilon trick." Here is a cut
and paste of Lukasz' explanation from the archives, including how to calculate
N.
- Dave Hillis
--
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
> -Original Message-
> From: Heikki Levanto
> To: dailey@gmail.com; computer-go
> Sent: Tue, 30 Dec 2008 5:22 pm
> Subject: Re: [computer-go] 3-4-5 rule
>
> On Tue, Dec 30, 2008 at 02:01:29PM -0500, Don Dailey wrote:
> > It looks like 3 is no good:
> >
> > Rank Name Elo+
Sounds about right. Looking at my notes, I have 57% wins for white using
similar playout?rules.
- Dave Hillis
-Original Message-
From: Don Dailey
To: computer-go
Sent: Thu, 8 Jan 2009 1:38 pm
Subject: Re: [computer-go] Black/White winning rates with random playout?
On Thu, 2009-01-
You can't just look at the mean. If you take a histogram and look at the
distribution of scores, you'll see a Gaussian-like bump in the middle, but
also huge tails where only one color was left. You can calculate the histogram
once and then use it to derive the win rate for different Komis. (Tha
First, my code is in no shape for sharing.
Some time back, I experimented with training a neural net to predict ownership
maps from 9x9 board positions. I wasn't looking for a static evaluator; I
wanted something to speed up my MCTS bot. I used my own engine to generate
ownership maps for train
Ernest,
Fun stuff! I have a co-evolved neural net that used to play on KGS as
“Antbot9x9”. I use the same net in the progressive widening part of my MCTS
engine. I would guess that many people experiment along these lines but they
rarely report results.
Here are some suggestions that might
I believe you've traced it back as far as it goes. I certainly haven't
published it. Sometimes comp-go papers cite this list as a catchall source for
the not-previously-published lore that's been posted here. I don't know of any
better way to handle things like this.
- Dave Hillis
-Origina
Bruno Bouzy gives it credit for a 1% strength improvement in the tutorial:
"Old-fashioned Computer Go vs Monte-Carlo Go"
http://www.math-info.univ-paris5.fr/~bouzy/publications/CIG07-tutorial-1avril2007.pdf
(It's a pretty good read in general, btw.)
The Mercy rule interacts with ownership maps and
One factor is that there seems to be a narrow range between too few entrants
and too many. For any given contest, the potential pool includes an elite few
who have a chance at first place and maybe a couple who have a new or newly
improved bot. There is?a larger group, back in the pack,?whose la
I took a look at this once, testing?how well ownership maps predicted?the moves
chosen in a large set of pro games. Ownership maps have some tricky artifacts,
especially for forced moves.
Consider a position, with white to move,?where black's previous move put a
white group in atari, and whit
I think this is?one of those?design decisions that nobody takes on faith. We
all wind up testing it both ways and in various combinations.
An additional advantage of using the number of visits is that branches at the
root become mathematically eliminated and can be pruned away. It often also
al
> -Original Message-
> From: Don Dailey
> To: computer-go
> Sent: Sat, 6 Jun 2009 5:59 pm
> Subject: Re: [computer-go] Tweak to MCTS selection criterion
> 2009/6/6
> I think this is?one of those?design decisions that nobody takes on faith. We
> all wind up testing it both ways and in
> I had the early stop rule and didn't know if anyone else had thought of it.??
> But I never considered the pebbles rule,
> which somewhat conflicts with the early stop rule.?? But as I layed out above
> I think you could do both.
> This is probably one of those things that adds a little bit b
The policy is only risk free on a per-move basis. For the game as a whole,
using more time on one move means there will be less time available for later
moves. Back when I tested this rule in my own program, I didn't see any
significant difference in strength. YMMV.
- Dave Hillis
-Original
Looking again, I was confusing a followup post with the original description of
the pebbles rule. I have not tested this exact rule. Sorry for my confusion.
- Dave Hillis
-Original Message-
From: dhillism...@netscape.net
To: computer-go@computer-go.org
Sent: Sun, 7 Jun 2009 9:39 pm
Subj
Yes. I think it's a good idea, but the devil is in the details. I've become
pretty disenchanted with trying to use 3x3 or 5x5 patterns. Currently, I have
about 300 1x1 patterns (I call them context codes) that I'm playing around with.
You can also do the same for RAVE without needing any more me
In my case, yes.
That is a correct interpretation for the context codes in my program, which are
equivalent to some of the suggestions for the meaning of "1x1 pattern." (But I
don't call them "1x1 patterns."?I also find that term confusing. I don't
remember seeing it before.)
- Dave Hillis
-
Sure, that would be a place to start. I also did some testing with just the
number of pseudo-liberties at the position. That was pretty easy to code up.
And I did have some limited success using 3x3 patterns-just not enough to
justify the nuisance of carrying it along in my code.
There are quit
Since this topic has resurfaced, I'll mention again the alternative strategy of
using unbalanced playout rules to compensate for high handicaps. As Don pointed
out, the existence of a high handicap *should* indicate that black is more
likely to make mistakes. This is simple to model, assuming h
There are 3 commonly cited problems and 4 commonly proposed remedies.
Problems:
1) Human games remain interesting, even after the winner is clear, because the
players just naturally switch to playing for maximum territory. Wouldn't MCTS
bots be more fun to play against if they did that too?
2) S
There are some relevant discussions in the computer go forum at
http://www.godiscussions.com
-Original Message-
From: Alain Baeckeroot
To: computer-go
Sent: Thu, Jul 16, 2009 5:08 pm
Subject: Re: [computer-go] Slightly OT: Sound in CGoban
Le 16/07/2009 à 22:28, Peter Drake a écrit :
> -Original Message-
> From: terry mcintyre
> To: computer-go
> Sent: Fri, Aug 7, 2009 10:35 am
> Subject: Re: [computer-go] RAVE problems
>
> Perhaps the "context" attached to RAVE needs to be more subtle than a static
> 3x3 pattern - tactical and efficiency > considerations may app
I'll add some detail. I have 10 features which give me 1024 possible context
codes, not all of which are realizable. I keep a CAMAF table of approximate
size 1024*(number of spaces)*colors (1024*81*2 for a 9x9 board). This table
persists throughout the entire game, with suitable decays of the we
I think Terry's suggestion is the best way to test these ideas:
1) Take 2 severely mismatched engines (perhaps 2 versions of the same engine
but with different numbers of playouts.)
2) Find the fair handicap by playing a sequence of games and adjusting the
number of handicap stones whenever
Well, it's a trade-off of course, but a?mercy rule threshold of 20?might
be?pushing it a bit. For 9x9, I typically use 30. If you only invoke the rule
for external nodes at least N plys away from any internal nodes, then the tree
will catch some of these problems.
Some playout policies tend
Interesting stuff. Thanks for reporting your results.
- Dave Hillis
-Original Message-
From: Christian Nentwich
To: computer-go
Sent: Wed, Sep 9, 2009 11:54 am
Subject: [computer-go] CUDA and GPU Performance
I did quite a bit of testing earlier this year on running playout algori
They?are also known as ngrams. Their use in machine translation might provide
some inspiration for computer go.
As with many of the ideas mentioned in this discussion, I've played with it
enough to say it's not low hanging fruit but I?don't necessarily believe?it's a
dead end. (I am fairly d
I'm not sure whether they meant different things when they were first coined,
but maybe that doesn't matter, and there are two different approaches that
should be distinguished somehow.
When a node has been visited the required number of times:
1) Use patterns, heuristics, ownership maps f
For 9x9 games, when I added progressive widening to AntiGo (before I added
RAVE), it was low hanging fruit. I used my old program Antbot9x9 for the move
ranking and got a very nice strength increase for very little effort. Then,
with a bit of tweaking, I got more improvement. RAVE, on the other
I made some more tables with 50K playouts, in case that is easier to look at.
50 K playouts?
LIGHT PLAYOUTs XX
rave
?? 1|?? 36?? 39?? 38?? 40?? 39?? 40?? 40?? 40?? 37
?? 2|?? 38?? 40?? 42?? 42?? 42?? 42?? 42?? 40?? 40
?? 3|?? 40?? 42?? 42?? 43?? 43?? 4
[ Digression: Some ANN architectures are more biologically plausible than
others. "Neuromorphic Engineering" is a good search term to see what's going on
along those lines. (But for a beginner project, the standard multi-layer
perceptron with backpropogation would still be the natural choice.)
> -Original Message-
> From: Hideki Kato
> To: computer-go
> Sent: Wed, Oct 28, 2009 1:41 am
> Subject: Re: [computer-go] First ever win of a computer against a pro 9P as
> black (game of Go, 9x9).
> ...
> BTW, recently I've measured the strength (win rate) vs time for a move
> curves
Hideki,
Thank you. Your results look quite compelling. Do you allow memory (the number
of nodes in the tree) to grow along with thinking time or is there a fixed
limit?
IIRC Don et. al.'s excellent scaling studies included gnugo but its effect was
probably small. Self play dominated. Perhaps
Just a wild guess here. One way to get catastrophically slow performance is to
have superfluous nested loops. For instance, one could iterate over each board
space, calling a routine to check for legality. If the legality routine also
iterates over the whole board (perhaps by updating all liber
For my fast/dumb neural net engine, Antbot9x9, I coevolved the weights using a
similar tournament system. Each individual played a number of games against all
the others, round robin, and the score was the sum of points for all of its
games.
Some observations/claims:
Non-transitive effects see
On Tue, Nov 24, 2009 at 16:11, Nick Wedd wrote:
> Suppose my attempts to read the game tell me "If I seal off my territory at
> A, I will win by 5 points. If instead I invade at B, then 70% of the time I
> will win by 25 points, 30% of the time I will lose by 5 points".
>
> If I am playing Go,
I would enter a bot in a KGS Hahn tournament, of Nick's type (2) if it were
held. (If KGS permits round-robin scheduling, I think that would be preferable,
but not essential.) I think it would be a lot of fun. Which is not to suggest
that the regular KGS tournaments need changing.
The early MC
It's good that you posted this. I liked the paper. (And I understand
proof number search a little better after reading it too.) But it describes the
epsilon trick in terms of transposition tables which I don't use. I didn't see
how it would apply to a broader range of applications or, spec
>-Original Message-
>From: [EMAIL PROTECTED]
>To: computer-go@computer-go.org
>Sent: Sun, 14 Jan 2007 11:08 PM
>Subject: Re: [computer-go] Fast Board implementation
>
>What should the mercy threshold be for other board sizes than 9 by 9,
>particularly 19 by 19?
>- George Dahl
Here is another MC speedup trick. I think it may have been mentioned
before but it's worth repeating.
This applies to the case where my program is going to run N playout games
and then select the most visited node as its move for that turn (which will not
always be the node with the
The answer is "yes." Many computer programs (including my own) can beat me
easily on today's hardware and I am, indeed, a human.
Glad I could clear that up for you. ;-)
- Dave Hillis
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Tue,
Handicap stones.
- Dave Hillis
-Original Message-
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: computer-go@computer-go.org
Sent: Sat, 27 Jan 2007 8:07 AM
Subject: Re: [computer-go] early results
On Fri, 2007-01-26 at 20:18 -0800, David Doshay wrote:
> I would highly recommend
I'm having difficulty picturing this, so I'll start with the most basic
questions.
Do you mean Monte Carlo by itself or Monte Carlo combined with tree search
(e.g. UCT)?
Do you mean partition the larger board for the course of each playout
(randomizing zones from one to the next) or in som
To gain some intuition re. what level of intransitivites are present on
CGOS, it would be interesting to see the cross-scores of all (or some...) of
the bots in a big table. A less obvious refinement is to add color coding to
make it easier to read. Here's an example from the game of C
I think of it as a continuum going from "light" to "heavy." Pure random
playouts are the lightest. But then you add some rules about filling in eyes,
then maybe discourage self-atari,... and the playouts keep getting heavier. I
agree with you that the current crop of MC engines are not n
I agree with what you say here and I'll try to make my point better.
First, my limited experience working with Monte-Carlo simulations involved
photons traveling through scattering media. The sequences of moves described in
the Mogo paper are pleasantly reminiscent of this.
I did no
-Original Message-
From: [EMAIL PROTECTED]
...
>> The earliest MC engines were extremely simple and easily described. > It
>> seems inevitable that someone new to the field will seize >on > this
>> description, and then combine it with the success of current > Monte-Carlo
>> engines, le
I have a design question about playout logic in Monte-Carlo games. If a
ladder starts in a playout game, should it be played out to the end
always/sometimes/never? I'm talking about purely external nodes, not what
happens in the tree search. Clearly the last option (determining which color
>-Original Message-
>From: [EMAIL PROTECTED]
>To: computer-go@computer-go.org
>Sent: Wed, 7 Feb 2007 5:34 AM
>Subject: [computer-go] MC approach (was: Monte Carlo (MC) vs Quasi-Monte Carlo
>(QMC))
>
>On Wed, Feb 07, 2007 at 12:06:40PM +0200, Tapani Raiko wrote:
>> Let my try again us
I should have mentioned that I have only tested on 9x9. For larger boards,
I don't know.
- Dave Hillis
`
Intuitively, it seems like this should work. You only give the winning
margin a small weight, or only use it to break ties, or only apply it after the
game is
The tests that involved factoring in the margin of victory while the game
was still in play, used pure random playouts (or relatively close to it.)
Later, I did some tests with esthetics as a goal in itself, and for these, I
used what I call a "heavy" playout. I doubt that the playout type
It's a *weighted* average of all moves. UCT tree search doesn't explore
"bad" moves as often as good ones, so they don't contribute as much to the
estimation of the worth of a node.
- Dave Hillis
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: W
Sounds like a bug. The randomness of the moves should make infinite loops
fairly rare (though not impossible) and your average game length should be
close to 100 moves.
It's a good idea to step through playout games one move at a time. Also to
run a lot of games, stopping to look
This one's a long shot. If you get the simple ko rule a little bit wrong,
you can run into a situation where a move that was illegal for black doesn't
get reset correctly and white isn't allowed to move there either. This can lead
to endless triple kos.
_ Dave Hillis
-Original Mes
Last one, I promise :) If your eye rule doesn't allow the defender to fill
in behind the ko stone (the one in atari), that can set up infinite loop triple
kos.
- Dave Hillis
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Thu, 8 Feb 2007 12:19 PM
Looks like a fractal to me. Easy to test: just calculate the fractal
dimension (using e.g. the box counting method) over a range of board sizes. If
you find a fractal (or mult-fractal) relationship - and maybe compare pure MC
against one of the variants - you could probably get a decent pape
1 - 100 of 186 matches
Mail list logo
