Ingo,
I'm not a proper statistician, but I believe there's a crucial second step
that's missing in your analysis of significance. Even if this were the only
computer-go test that you personally had ever conducted, we would nevertheless
need to take into account all of the other tests being
Yes. And while worrying about what happens after a win rate of 97% sounds like
splitting hairs, I think we're talking about an awkward way of measuring
something that's of practical interest.
Suppose Hideki's experiment were repeated, giving GNU GO a four stone handicap.
If Zen plateau'd out
Well, I thought there seems to be a picture emerging was sufficiently hedged
that it would be construed as a conjecture, not a conclusion. :)
I am thinking, in particular, of the scalability studies with Zen that Hideki
reported to this list in Oct. 2009.
BTW, recently I've measured the
Thank you for posting these interesting results There seems to be apicture emerging that MCTS engines scale very well in self play, and apparently against other MCTS engines, but not so well against the non-MCTS version of Gnugo.
- Dave Hillis
-Original Message-
From: Jean-loup
Interesting is in the eye of the beholder, but I think a Hahn tournment would
be interesting.
Everyone with an MC bot could easily modify it to play by setting it
(carefully) not to resign, and changing it to try to maximize average score
rather than probability of win. That's really just a
On Tue, Nov 24, 2009 at 16:11, Nick Wedd n...@maproom.co.uk 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
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
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
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.
-Original Message-
From: Hideki Kato hideki_ka...@ybb.ne.jp
To: computer-go computer-go@computer-go.org
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
[ 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.)
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
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??
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
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
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
-Original Message-
From: terry mcintyre terrymcint...@yahoo.com
To: computer-go computer-go@computer-go.org
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 -
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
There are some relevant discussions in the computer go forum at
http://www.godiscussions.com
-Original Message-
From: Alain Baeckeroot alain.baecker...@laposte.net
To: computer-go computer-go@computer-go.org
Sent: Thu, Jul 16, 2009 5:08 pm
Subject: Re: [computer-go] Slightly OT: Sound in
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)
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
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
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
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
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
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
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
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
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
Sounds about right. Looking at my notes, I have 57% wins for white using
similar playout?rules.
- Dave Hillis
-Original Message-
From: Don Dailey dailey@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Thu, 8 Jan 2009 1:38 pm
Subject: Re: [computer-go] Black/White
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.
-Original Message-
From: Heikki Levanto hei...@lsd.dk
To: dailey@gmail.com; computer-go computer-go@computer-go.org
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:
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
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
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:
Core Wars , robot soccer (there is a simulation league), pictionary,...
- Dave Hillis
?
- Original Message - From: Darren Cook [EMAIL PROTECTED]?
To: computer-go@computer-go.org?
Sent: Monday, October 27, 2008 8:54 PM?
Subject: Re: [computer-go] OT: Harder than go??
?
Where harder
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
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 computer-go@computer-go.org
Sent: Sat,
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
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't join them.?
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
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
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
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
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
There is a discussion at godiscussions
http://www.godiscussions.com/forum/showthread.php?t=7154
?The sgf's for the two games played are on page 2
Dave Hillis
-Original Message-
From: mingwu [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; computer-go computer-go@computer-go.org
Sent: Sun, 21 Sep
Raises hand. Chinese rules version for 9x9 and 13x13 would be quite helpful if
that's what you are offering. Different komi would be fine.
- Dave Hillis
-Original Message-
From: Darren Cook [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Sat, 6 Sep 2008 10:33 pm
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
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Mon, 11 Aug 2008 11:09 pm
Subject: Re: [computer-go] Re: What's happening at the European Go Congress?
On Tue, 2008-08-12 at 11:50 +0900, Darren Cook wrote:
Also, if you are
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
I? use proximity in the heavy playouts themselves. I think most (all?)?people
do this.?I have a precalculated table with the 3x3 and 5x5 neighbors for every
position on the board.?
- Dave Hillis
-Original Message-
From: Jason House [EMAIL PROTECTED]
To: computer-go
I've tried both MoGo and CrazyStone style playouts. I find MoGo style playouts
easier to work with. YMMV.
My MoGo style heavy playouts are about 4 times slower than my light playouts.
- Dave Hillis
-Original Message-
From: Jason House [EMAIL PROTECTED]
To: computer-go
The people with stronger programs and more full-board experience will be better
positioned to comment on this. I'll say that the two styles both need a lot of
tweaking, making it hard to establish a fair test between them.
It's good to be able to match a 3x3 pattern very quickly. Since there
-Original Message-
From: Jacques Basaldúa [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Wed, 14 May 2008 6:38 am
Subject: Re: [computer-go] 10k UCT bots
Don Dailey wrote:
[EMAIL PROTECTED] wrote:
For those currently coding this up, I think the most important
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
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
-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
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
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
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
? -Original Message-
? From: Don Dailey [EMAIL PROTECTED]
? To: computer-go computer-go@computer-go.org
? Sent: Mon, 18 Feb 2008 1:45 pm
? Subject: Re: [computer-go] Re: computer-go Digest, Vol 43, Issue 8
...I have seen widely held beliefs be proven wrong before
(the earth is
Hi Florian,
?
That sounds like an interesting project. I've looked at this a little. If
it were me, I would start by implementing the simplest possible MC playouts in
gpgpu,?as efficiently as possible, before looking at adding things like
patterns.?
I also heartily encourage you
Lots of good information here. In particular, I notice that my program has the
explore needless captures in progressive widening weakness described below. My
thanks to Magnus (and Remi, of course) for pointing it out. I'll fix that and
then, I guess, I'll have to revisit the issue of reading
That's very interesting. RAVE, as described in the Mogo paper, incorporated
some priors and gave a progressive widening effect. Have you looked at
progressive widening with and without RAVE? Could you provide some details
about how you made it work?
-Dave Hillis
-Original Message-
A few trick moves in a row can cause problems. But the cases where I am most
likely to be watching my bot's play through my fingers are when there is an
obvious (to a 20 Kyu like me) situation but it's some plys in the future. (Or
it can be pushed into the future!)
A case of seki is easy for
I'm going to call this the procrastination effect. MY claim is that, when
MC-UCT encounters a critical life and death board situation that its playout
policy consistently gets wrong, the search will naturally tend to skew the tree
so that relevant moves continue to be made during the playouts.
Right you are. Silly me.
-Original Message-
From: Álvaro Begué [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thu, 31 Jan 2008 3:06 pm
Subject: Re: [computer-go] not Go knowledge and UCT
On Jan 31, 2008 2:59 PM, [EMAIL PROTECTED] wrote:
I'm going to call this
That's an interesting story. I just wish I hadn't precipitated it by sharing my
blinding flash of the obvious with the whole list. You are correct, of course.
I got so focused on something that I didn't see the forest for the trees.
- Dave Hillis
-Original Message-
From: Don Dailey
From: Don Dailey [EMAIL PROTECTED]
...
Rémi Coulom wrote:
...
Instead of playing UCT bot vs UCT bot, I am thinking about running a
scaling experiment against humans on KGS. I'll probably start with 2k,
8k, 16k, and 32k playouts.
That would be a great experiment. There is only 1
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
...
For instance since is legal to resign,? we could randomly include this
possibility in the play-outs, but it would not increase the resolving
power of the play-outs.
Hmm... It would speed things up, though. And if you made
Single stone suicide is much easier to test for. :)
- Dave Hillis
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Tue, 15 Jan 2008 12:11 pm
Subject: Re: [computer-go] On average how many board updates/sec can top Go
programs do
Um, by easier I mean faster. Also, I think single point suicide is more likely
to lead to infinite loops, depending on your eye-filling rule.
- Dave Hillis
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Tue, 15 Jan 2008 12:16 pm
Subject: Re:
Another possible reason could be for SIMD (vector) parallel processing. Years
ago, I was a real-time image processing guy. Some time back, I did a
back-of-the-envelope design for doing?light playouts on multiple go boards at
once, on a dedicated parallel processing card. It meant?tiling all
Thanks Alain. I see I had given up on the paper too soon.
- Dave Hillis
-Original Message-
From: Alain Baeckeroot [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Sun, 13 Jan 2008 11:51 am
Subject: Re: [computer-go] Sylvain Gelly thesis in english
Le dimanche 13
That sounds like it would be weaker than Wally. You could just use Wally,
though, with today's hardware,?I doubt many would find it a challenging
opponent.
- Dave Hillis
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Tue, 8 Jan
Down the road, when I'm ready for it, I'd like for there still to be a 19x19
CGOS much like the one now. But, in the mean time, the current 19x19 CGOS is of
no use at all in helping me get there. Ten minutes per side or faster would be
ideal. Don's plan for 2 speeds on the same server sounds
I've mentioned this before, but hopefully not recently enough to make this
annoying. Computer go people and corewars people overlap somewhat.
Intransitivity is extremely important for corewars, making?corewars a good
domain to study it.
Here is an example of a nice graphical way to visualize
Maybe some day computer go will reach the same level of maturity as computer
chess and we will need safeguards against all sorts of churlishness. But so
far, CGOS is very civilized.
I favor encouraging people to make their bots resign, but not penalizing those
who don't. The MC programs are
Depending on your rule set, you might not want to use stones captured.
I use more-or-less Tromp-Taylor rules; same as CGOS.
- Some form of mercy rule: if whiteStonesOnBoard == 0, I know who won. Early in
the game, blowouts are *very* comon.
- I maintain an array of empty spaces. At scoring
-Original Message-
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thu, 13 Dec 2007 6:30 pm
Subject: Re: [computer-go] MC-UCT and tactical information
...
Change for the better seems to imply only a one-sided analysis.? I would
imagine
-Original Message-
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Fri, 14 Dec 2007 2:23 pm
Subject: Re: [computer-go] MC-UCT and tactical information
So, what tactical information should be calculated, how should it be used, and
yes how
I'd like to start a more specific discussion about ways to combine tactical
information with MC-UCT. Here's the scenario.
It's the bot's turn and, prior to starting any playouts, it runs a tactical
analyzer (for want of a better name) that labels each string as unconditionally
alive,
That's a strong program, and interesting?information.?For clarity, I assume
that you mean something like Benson's algorithm, while my intended meaning was
alive assuming perfect play. Both are relevant, we just need to keep them
sorted out.
- Dave Hillis
-Original Message-
From: John
-Original Message-
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thu, 13 Dec 2007 3:20 pm
Subject: Re: [computer-go] MC-UCT and tactical information
On Dec 13, 2007 2:17 PM, [EMAIL PROTECTED] wrote:
I'd like to start a more specific
Impasse: noun,
1. There is no argument so elegant and compelling that it will prove the
negative that making UCT greedier could not possibly lead to more won games.
2. Everyone who has tried it one way, will have tried some variations. It's not
as if it takes a?lot of code. No one has reported
I got a smile out of that.
_ Dave Hillis
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thu, 13 Dec 2007 8:52 pm
Subject: Re: [computer-go] low-hanging fruit - yose
[EMAIL PROTECTED] wrote:
Impasse: noun,
1. There is no
-Original Message-
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thu, 6 Dec 2007 4:44 pm
Subject: Re: [computer-go] Re: evaluating monte carlo results
On Dec 6, 2007 4:22 PM, [EMAIL PROTECTED] wrote:
My program is riddled with code to
G'day guys,
I'm involved in the development of a very powerful and flexible grid
software, which we plan to release in January. It is all java based.
http://www-nereus.physics.ox.ac.uk/ (bear in mind you can't download
it yet and the website is out of date)
One of the things I'd like to do
Couldn't there just be two servers? There were multiple volunteers. A server
with long games might draw more viewers but fewer participants. Shorter games
would be more helpful for those of us working on weak 19x19 programs that other
people are less interested in anyway.
- Dave Hillis
Hi Don,
Sounds like a good idea.
- Dave Hillis
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Sun, 28 Oct 2007 5:05 pm
Subject: Re: [computer-go] 19x19 CGOS
Hi Dave,
Two servers is easy, but 1 server is better.The plan is
LOLCODE
http://lolcode.com/
The future of programing.
-?Dave Hillis
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Mon, 1 Oct 2007 3:45 pm
Subject: Re: [computer-go] Python bindings for libego?
-BEGIN PGP SIGNED MESSAGE-
-Original Message-
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Mon, 24 Sep 2007 10:22 am
Subject: Re: [computer-go] ego110_allfirst on CGOS
I just looked at 133684.? ego110_allfirst took all the way until move 18 to
play a move above the
When I try AMAF (including RAVE) my program always wants to make early
moves on the first and second lines. I've come to look at it as a
hallmark of the algorithm.
To combat this, I use a table with a move number for each position on
the board. The program is not allowed to put
Good information. Thanks.
- Dave Hillis
-Original Message-
From: Jacques Basaldúa [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Fri, 21 Sep 2007 7:44 am
Subject: [computer-go] Random move selection (was) Crazystone patterns
Dave Hillis, wrote:
Suppose I can generate
If the 19x19 CGOS is going to be retired due to lack of interest, I wonder if
there would be interest in trying out an ultra-blitz version for a while: games
as fast as the com. links would permit.?(Game storage would be an issue. Maybe
they just wouldn't get stored.) It could be a limited time
Hello Giles,
I downloaded the latest version of Drago (which includes the LibKombilo.dll
file that someone mentioned), copied in your patch, and played Mogo for a few
moves. It seems to work OK. YAY!
I'll mention this here, since others might encounter it. There is a small race
condition
-Original Message-
From: Cenny Wenner [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wed, 19 Sep 2007 11:31 am
Subject: Re: [computer-go] Re: Most common 3x3 patterns
On 9/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I neglected the rather important
-Original Message-
From: Rémi Coulom [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thu, 20 Sep 2007 10:22 am
Subject: Re: [computer-go] Crazystone patterns
Chris Fant a écrit :
Does this mean that you need to calculate the Bradley-Terry
probability for
That should do nicely. Thanks!
-Original Message-
From: Álvaro Begué [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thu, 20 Sep 2007 10:31 pm
Subject: Re: [computer-go] Crazystone patterns
Remi keeps a number that is the sum of all the probabilities (I'll
all them
1 - 100 of 142 matches
Mail list logo
