The current result is 52.5 percent for white. Of course if the
programs were playing perfectly it should be zero percent for white
if 9 is the correct komi.
Why are you not using komi=9 ?
Christoph
___
computer-go mailing list
computer-go@computer-
On Mon, 16 Oct 2006, Don Dailey wrote:
What I have decided on, based on several different simulations, is the
following:
1. Fix N at 3
2. Pick one unpaired player P at random.
3. Loop 3 times doing the following:
4. Select a potential unpaired opponent R as a candidate opponent
On Tue, 17 Oct 2006, Don Dailey wrote:
It's interesting that (relatively) strong players are still losing games
with both colors, despite the 8.5 komi.
I am not suprised to see a strong bias (2:1) toward WHITE with
komi=8.5 since only a (near) perfect player can take full advantage
of moving fi
On Tue, 24 Oct 2006, alain Baeckeroot wrote:
Any ko fight where the only legal move is suicide a group or pass.
It could be die instead of seki for example (which is pass-alive)
Seki is NOT pass-alive.
Christoph
___
computer-go mailing list
computer
On Thu, 2 Nov 2006, Peter Drake wrote:
To those of you with Monte Carlo programs:
.
..ww.
.wBBw
..wBBw...
...w.
.
..B..
.
.
I believe black's best move is to play in the center and escape via the
broken ladder.
1) Is this true? (This is a Go-pl
On Tue, 7 Nov 2006, Peter Drake wrote:
Consider this position:
...wBw...
.w.wB
...wB
B
B
B
w..wBw...
w..wBw.w.
w.wwBw...
Orego (now using UCT) quickly finds the correct answer, but the estimates of
the probability of winning are strange. Here's a graph:
The p
On Wed, 3 Jan 2007, David Doshay wrote:
Chinese, note that SlugGo started passing, indicating that it saw no
purpose in any more moves, at move 239. Here, the boundaries are
clear, the dead stones are clear to a human, and the winner is plenty
clear enough.
Yes, W (mogo) wins by 2.5 pts
But t
On Thu, 4 Jan 2007, Don Dailey wrote:
I have a question. With perfect play, obviously a 9 stone handicap
game is dead lost. If 2 perfect players played a game where one
was given the 9 stones, and they played for maximum territory (obviously
it doesn't make sense to play for a win) would the h
I think the whole discussion about Japanese vs. Chinese scoring
is moot in the context of "silly" invasions.
If my opponent passes and
1) I am ahead ... I pass and win.
2) I am behind ... I may start an invasion if I think I have a
chance; loosing a couple more points (Japanese) does not matter
On Fri, 5 Jan 2007, steve uurtamo wrote:
i think that the attached initial (13-stone) setup requires life to be
made in the center
rather than the sides or corners, but it looks difficult. a stronger
player can comment, perhaps?
It should be possible to live with an attachment at the 3-3 poin
On Feb 23, 2008, at 7:51 PM, Jason House wrote:
I mean, why do you have to download a client to run locally? Why
can't
you just use GTP directly against a socket?
That's similar to what I did.
I implemented the CGOS protocol directly into my Go-programm.
It's very straight forward and I don'
On Feb 24, 2008, at 1:22 PM, Raymond Wold wrote:
Do you have any notes on what you found out about the protocol? Any
open source code?
I looked at the CGOS-client code (TCL script) and re-implemented it
in C, then I
linked that file to my Go-program. That makes it specific to my
program,
On Feb 24, 2008, at 1:54 PM, Álvaro Begué wrote:
like the current scheme where a little program talks GTP to the
engine and then something else (I don't care what) to the server.
It would be better if the little client were written in Perl (there
used to be a Perl version but I don't know
On Tue, 26 Feb 2008, Don Dailey wrote:
The graph currently shows Leela as weaker than mogo at a given number of
simulations, but Leela appears to be catching up at higher levels.
Of course this may all prove to be nonsense after a few hundred more
games are complete.
We should be careful about
On Tue, 26 Feb 2008, Christoph Birk wrote:
We should be careful about any conclusions ... your pairing algorithm
currently creates leela-vs-leela games only.
May I recommend removing most of the Leela instances ASAP and add
them one-by-one later. This way the alorithm would be forced to
mix up
On Sun, 2 Mar 2008, Don Dailey wrote:
My feeling is that in lost positions, the only thing we are trying to
accomplish is to make the moves more cosmetically appealing (normal) and
at best improve the programs chances of winning against weak players.
After all, if the program is in bad shape,
On Sun, 2 Mar 2008, Don Dailey wrote:
This is true in GO too. I'm talking about the kinds of position where
go program start to play "aimlessly" and they only do that when the
result is like being down a queen in chess.Even being down a piece
in chess is playable if there is some compensati
On Mon, 3 Mar 2008, Don Dailey wrote:
What you are trying to do is more in the category of opponent
modeling.You want to optimize for the case that you might
occasionally salvage a game against an opponent that is much weaker than
you but is beating you anyway.
No, absolutely not. The idea
On Tue, 4 Mar 2008, Magnus Persson wrote:
But here you are missing the point that close to 0% winning probability means
that it cannot win against random play. The opponent could lose only by
killing his own groups.
I don't know why you (and Don) keep bringing up the 0% against random
play ..
On Tue, 4 Mar 2008, Don Dailey wrote:
I really believe the source of peoples confusion on this is believing
that the program starts playing "ugly random" moves as soon as it is
down a little. But in fact, when it gets into "ugly" mode it is
because the score is very close to 0.0 or in some p
On Tue, 4 Mar 2008, Don Dailey wrote:
When you get into opponent modeling, you have to understand your
opponent, because usually opponent modeling involves playing weaker
moves in exchange for better practical winning chances.
No, I don't want to do any opponent modelling.
And no, opponent mod
On Tue, 4 Mar 2008, Magnus Persson wrote:
I do not see why an MC programs in general is biased towards winning with 10p
instead of a single 1p mistake.
It is not biased, that's my point.
It should be biased toward the '1pt' loss, if loss is unavoidable,
not for beauty but for the likelihood of
On Tue, 4 Mar 2008, Weston Markham wrote:
greater loss by the program. (You also characterize the opponent's
blunder in (b) as "stupid", but I understand this to simply be a
subjective characterization based on the fact that it leads to a large
loss.)
In my own experience it is much easier to
On Mar 5, 2008, at 11:58 AM, Don Dailey wrote:
Don Dailey wrote:
not assuming that MC plays the best move. The problem isn't the
assumptions I am making, but the assumptions others are making, that
it's NOT playing the best move.You want to apply a fix to all
positions without really kn
On Thu, 6 Mar 2008, Don Dailey wrote:
One last time: Nobody suggested a one fix for all positions/problems.
The "floating komi" was suggested to guide the UCT search along
certain lines of play during specific (close!) endgame positions.
When I said all positions I meant all games.You expect
On Thu, 6 Mar 2008, Don Dailey wrote:
And can I assume the tree portion is also inhibited from seeing this due
to a combination of factors such as heuristics to delay exploring "ugly"
moves as well as the weakness of the play-outs in this regard (which
would cause the tree to not be inclined to
On Thu, 6 Mar 2008, Don Dailey wrote:
advantageous to give away stones that not. Despite what many people
believe, MC programs don't normally believe it's better to win small
and they are not hell-bent on giving away stones in order to try to make
the score come out to be exactly 0.5 win.
You
On Thu, 6 Mar 2008, Weston Markham wrote:
You are right, but I think that you may also be misconstruing the
nakade problem as a lack of concern about margin, when it is really a
fundamental failure to understand (i.e., failure to explore
Sorry, you miss-understood.
The nakade problem is totally
On Mon, 10 Mar 2008, Petr Baudis wrote:
MoGo displays the depth of the principle variation in the stderr stream.
I have been wondering, does that include _any_ nodes, or only these
above certain number of playouts? What is the playout threshold?
The 'principal variation' is usually the one t
On Mon, 10 Mar 2008, Petr Baudis wrote:
With 110k playouts per move and no domain knowledge in the playouts,
the ratings are now:
c=0.2 (pachi1-p0.2-light) ELO 1627 (285 games)
c=1.0 (pachi1-p1.0-light) ELO 1590 (120 games)
c=0.05 (pachi1-p0.05-light) ELO
On Tue, 11 Mar 2008, Petr Baudis wrote:
On Mon, Mar 10, 2008 at 06:57:07PM -0400, Don Dailey wrote:
I think you may still have a bug. You should get well over 1700 with
110,000 playouts, even if they are light playouts.
I will run myCtest with 110k-playout, c=0.25 and node creation
after the
On Mon, 10 Mar 2008, Christoph Birk wrote:
On Tue, 11 Mar 2008, Petr Baudis wrote:
On Mon, Mar 10, 2008 at 06:57:07PM -0400, Don Dailey wrote:
I think you may still have a bug. You should get well over 1700 with
110,000 playouts, even if they are light playouts.
I will run myCtest with 110k
On Tue, 11 Mar 2008, Petr Baudis wrote:
BTW: I count the new-node threshold like Don from the parent
node, so 50 not far from your '2'.
Hmm, I really wonder where this comes from, the idea seems quite
unnatural to me.
Well, child-nodes are created by the parent. The parent keeps
a count
On Tue, 11 Mar 2008, Don Dailey wrote:
If it is agreed, I will start a 25k test.My prediction is that this
will finish around 1600 ELO on CGOS.
I have long term rating for simple random playouts:
myCtest-10k and myCtest-50k.
I keep them active since Sept/2006. Please don't use 25k.
Chri
On Tue, 11 Mar 2008, Don Dailey wrote:
This isn't simple random play-outs.It's monte carlo with UCT tree
search.
Ok, I will use 50k to match your test.It means I probably cannot
run 2 tests on that machine and is why I hoped it would be minimal
resource usage, but since you have alrea
On Tue, 11 Mar 2008, Don Dailey wrote:
I am going to keep the 25k playouts running and add a 10k play-out
version of UCT. I want to establish a standard testing size so that
Great! That way Jason can also participate.
myCtest-10k-UCT has a long-term rating of about 1250.
For the 50k versio
On Wed, 12 Mar 2008, Don Dailey wrote:
1. My UCT constant is 1.0 - my formula is averageScore + c * sqrt(
(2.0 * log(n)) / (10.0 * m) );
so your contstant is 2/10 = 0.2 inside the sqrt(), which is
equivalent to c=0.44 ?
Christoph
___
computer-go m
On Thu, 13 Mar 2008, Petr Baudis wrote:
So I have created this page:
http://senseis.xmp.net/?CGOSBasicUCTBots
and summed up what I could find in the thread about the various bots.
Please clarify if anything there is wrong / unknown, and add your bots
if they aren't there. I wanted to ad
On Thu, 13 Mar 2008, Heikki Levanto wrote:
Would it make sense to have a similar page for pure MC programs (without
uct), so that we beginning developers could check that portion of our code
against known results?
I have two long-term CGOS programs:
myCtest-10k: 1011 ELO
myCtest-50k: 1343 EL
http://cgos.boardspace.net/9x9/standings.html
is not updating.
Christoph
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
On Mar 26, 2008, at 12:32 AM, Olivier Teytaud wrote:
... is room for improvement. But 19x19 is something else, perhaps we
can have the Dan, but I'm not sure of that in spite of the gentle
words of
Catalin, and I'm sure the current
mogo can't win against a professionnal player in 19x19 whene
On Mar 26, 2008, at 9:47 AM, David Fotland wrote:
The lower level prizes were given for games against Insei, but the
top prize
was for play against t top professional.
http://www.smart-games.com/worldcompgo.html
I can't find any official data on-line, but the information in the
page
above
On Mar 31, 2008, at 10:48 AM, Mark Boon wrote:
I don't know about this. I'm pretty sure MoGo checks if the stone
can make at least two liberties (ladder problem) in which case it
can still be horrible but very seldomly worse than random.
I would expect playing a "not-working" ladder to be w
On Mar 31, 2008, at 1:05 PM, Don Dailey wrote:
Christoph Birk wrote:
On Mar 31, 2008, at 10:48 AM, Mark Boon wrote:
I don't know about this. I'm pretty sure MoGo checks if the stone
can
make at least two liberties (ladder problem) in which case it can
still be horrible but ver
On Tue, 8 Apr 2008, steve uurtamo wrote:
There isn't, and this is actually a fortunate thing, yet any way to
use unix without at some point needing to use a command-line
tool. This is what will keep it out of the hands of consumers for
a long time to come, but I think that it's an inherent fact
On Wed, 9 Apr 2008, Andy wrote:
For example: Suppose a player's true strength is 1500 for some time, and
then he suddenly improves to 2000. Both before and after he plays a fixed
number of games per day (say 10). Show a graph of what each rating
algorithm would think his rating is over time.
On Wed, 9 Apr 2008, terry mcintyre wrote:
How does 500 elo points compare to kyu ranks?
Beginning players do improve by 4-5 ranks in a short
period of time. We don't all start as dan-level
players, alas!
Yes, but short time will still be many games.
Christoph
On Wed, 9 Apr 2008, Matthew Woodcraft wrote:
Beginning players do improve by 4-5 ranks in a short
period of time. We don't all start as dan-level
players, alas!
Yes, but short time will still be many games.
It might be that most of those games aren't visible to the rating
system.
That migh
On May 13, 2008, at 7:25 AM, Jason House wrote:
I'm testing my bot on CGOS using pure UCT, no pondering, and 10,000
playouts per move. Can someone put up a comparable bot?
I will re-start 'myCtest-10k-UCT' later today.
Christoph
___
computer-g
On May 13, 2008, at 9:00 AM, David Fotland wrote:
When you say pure uct, what is the playout policy? Pure random
moves except
don't fill one point eyes?
Yes.
What's your eye rule?
all four neighbors occupied by "my" stones and not more 1 diagonal
occupied by opponent (center) or no diag
On May 13, 2008, at 10:00 AM, Jason House wrote:
On May 13, 2008, at 12:00 PM, "David Fotland" <[EMAIL PROTECTED]
games.com> wrote:
When you say pure uct, what is the playout policy? Pure random
moves except
don't fill one point eyes?
That's exactly what I meant. I'd also assume other st
On May 13, 2008, at 10:04 AM, Jason House wrote:
On May 13, 2008, at 12:57 PM, Carter Cheng <[EMAIL PROTECTED]>
wrote:
I have a list of empty points. I pick one at random and then scan
until I find a legal one.
That's not random.
Christoph
___
On Tue, 13 May 2008, Mark Boon wrote:
If this asymmetry really bothers you, you could very easily fix this by
wrapping the search around. There's no asymmetry in a circle.
That doesn't fix anything.
Why not? The whole argument is about a bias against points towards the end.
In a circular lis
On Thu, 17 Jul 2008, David Fotland wrote:
Not trolling for flames, just expressing an opinion. If someone is not
willing to put in one day effort to port from Linux to Windows, why should
they expect anyone else to put in one day effort to make Linux available as
a platform? It seems Linux peop
On Thu, 17 Jul 2008, Álvaro Begué wrote:
Although it is possible that there are portability issues between
Linux flavors, your example has nothing to do with it: Macs don't
usually run Linux...
It is very simple to re-compile a Linux program on a Mac.
Christoph
On Thu, 17 Jul 2008, Dave Dyer wrote:
If your program has ANY gui at all though, you're pretty much screwed.
Mac Windows and Linux GUIs are about as far apart as any three platforms
can be. There are lots of "compatibility" solutions, including your
choice of platform independent languages; but
On Fri, 1 Aug 2008, Don Dailey wrote:
know which one that will be. If they all get reasonable usage I will
leave them all up, but if one tends to get very little usage, I will
bring it down later. I'll let them all stay up for a reasonable length
of time.
Thanks!
So there will be 9x9, 13
On Fri, 1 Aug 2008, [EMAIL PROTECTED] wrote:
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 w
On Aug 2, 2008, at 10:34 AM, Don Dailey wrote:
Does it make sense to use a komi of 7.5 for 13x13 and 19x19 under CGOS
rules?
I don't know about 13x13, but for 19x19 you should use 6.5.
Christoph
___
computer-go mailing list
computer-go@computer-go
On Aug 2, 2008, at 1:48 PM, Don Dailey wrote:
Ok, the 13x13 server is up and running. Here are some temporary
instructions that will probably be understandable for those with bots
already running:
would be nice to get a few bots on 13x13 to get it started off.
myCtest-10k-UCT is running
On Aug 2, 2008, at 2:23 PM, Christoph Birk wrote:
would be nice to get a few bots on 13x13 to get it started off.
myCtest-10k-UCT is running ...
Weired. I got disconnected during my first game (12) but CGOS
does not mention this game as a loss for myCtest ... it ignored it
entirely and the
Achor 'Gnugo-3.7.10-a3' loses a lot on time.
Christoph
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
On Aug 9, 2008, at 6:01 PM, Don Dailey wrote:
On Sun, 2008-08-10 at 01:59 +0200, Vincent Diepeveen wrote:
On Aug 9, 2008, at 9:45 PM, Don Dailey wrote:
I'm curious what you guys think about the scalability of monte
carlo
with UCT.
The MCTS technique appears to be extremely scalable. The
On Aug 10, 2008, at 1:46 PM, Robert Waite wrote:
Exhaustive search is scalable in that I could give it all the
memory and time it wanted. And it would approach a finite amount of
memory and a finite amount of time.
Yes, but "exhausitve search" does not improve your player by 63% (eg.)
for a
On Mon, 11 Aug 2008, Don Dailey wrote:
But let's not exaggerate. This was not just a simple matter of filling
empty points.
It was.
It was obviously unclear enough to some of us that it required some
analysis. Even the strong Leela did not see this as merely filling in
the empty points.
On Aug 25, 2008, at 10:47 PM, Olivier Teytaud wrote:
Just for information, mogo will play in a few minutes (on Kgs /
computer-go) some games
against high level humans.
MogoTitan is playing 9x9 against nutngo ?
Christoph
___
computer-go mailing li
On Sep 1, 2008, at 9:06 AM, David Fotland wrote:
It seems there is almost no interest in 13x13 cgos. There is
usually no
program there.
Does it make sense to keep it?
What's the cost (not necessarily monetary) to keep it?
Christoph
___
compute
On Fri, 5 Sep 2008, Magnus Persson wrote:
I will also run Valkyria on CGOS 13x13 over the weekend, (or long as things
are stable).
One anchor would be nice.
Christoph
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.or
On Tue, 9 Sep 2008, Olivier Teytaud wrote:
In 19x19, it's much better, but the MPI parallelization of 9x9 Go is
challenging.
The bright side here is that 9x9 is not really important but just
a test bed. If it works for 19x19, that's good.
Christoph
___
On Tue, 9 Sep 2008, Olivier Teytaud wrote:
testbed for
parallelization because it's more difficult) and as "real" targets (as there
are players
for both).
Sorry, but there are (almost) no players for 9x9. To repeat
D.Fotland's earlier comment: 9x9 is just for beginner's practice.
It's not go.
On Thu, 18 Sep 2008, Don Dailey wrote:
It didn't take very long at all before I figured out all the basic cases
for myself.Even the 2 eye rule I had "heard of" and even understood
it from a book, but it was still rather abstract to me until I actually
experienced it for myself. Only when it
On Tue, 30 Sep 2008, Magnus Persson wrote:
...wF1 bE6 wF6 bF2 wE3 bD1 wF1 bF5 wF4 bF2 wPass bF1 B+3.5
I guess you mean B+4.
Couln't black win by just refusing to play the ko?
I could B+4 in that case too.
Christoph
___
computer-go mailing list
compu
On Tue, 30 Sep 2008, Christoph Birk wrote:
On Tue, 30 Sep 2008, Magnus Persson wrote:
...wF1 bE6 wF6 bF2 wE3 bD1 wF1 bF5 wF4 bF2 wPass bF1 B+3.5
I guess you mean B+4.
Couln't black win by just refusing to play the ko?
I could B+4 in that case too.
Oops, you are right. B+2 if he refuse
On Tue, 7 Oct 2008, Denis fidaali wrote:
The engine is written in java, and run on a quad core Q9300 @ 2.50 Ghz.
The code has been lightly optimized, and use pseudo-liberties to detect
captures.
Run it on CGOS, it should get a similar rating to 'myCtest':
name#light_simulations
On Wed, 8 Oct 2008, Don Dailey wrote:
Christoph,
Do you use all-moves-as-first? If not, this data seems to match mine
very well. The upper bound seems to be around 1300 ELO give or take a
few ELO.Ike seems to be around 1300 ELO with 10k play-outs but they
are all-as-first.I'll let it
On Wed, 8 Oct 2008, Don Dailey wrote:
much more common.There were just a few games that used 6.5 komi
because when I first started CGOS I had set 6.5 by mistake but I think
that was just for a few hours at most. The vast majority of these are
7.5 komi games:
After all this discussion abou
On Wed, 8 Oct 2008, Denis fidaali wrote:
Now, i wanted to make sure that my implementation had any chances to be
correct. So i though I'd post the characteristic statistical values that
i get out of it. Indeed i though it could benefits others later on, in
particular if someone could corroborat
On Wed, 8 Oct 2008, Denis fidaali wrote:
To Don and Christoph : I reallize that i was probably not as clear as i though
i was.
I have built up a light simulator. There are no tree involved. It is
only choosing a move with equiprobabilty from the set of empty points on
the board.
That's exact
On Wed, 8 Oct 2008, Don Dailey wrote:
On Wed, 2008-10-08 at 11:47 -0700, Christoph Birk wrote:
On Wed, 8 Oct 2008, Don Dailey wrote:
much more common.There were just a few games that used 6.5 komi
because when I first started CGOS I had set 6.5 by mistake but I think
that was just for a
On Thu, 9 Oct 2008, "Ingo Althöfer" wrote:
I would like to see "all" Go programs to be able to live with
possible draws (or even with any score spectrum).
My program (myCtest) works with draws, but it's fairly weak
at about 1550 ELO (3.2 GHz P4).
Christoph
___
On Thu, 9 Oct 2008, Denis fidaali wrote:
tCan we degrade performances more with more simulations ? :) How
does 5000AMAF fares
agains 1AMAF, i wonder. Although i'm more interested about the
upscales that the downscales :)
I tried 50k vs 10k and saw no further improvement (no degradation
eit
On Mon, 20 Oct 2008, Don Dailey wrote:
And now after about 11,000 games we are within 1 standard deviation and
the score is very close to 50% so I have confidence that we have 2
functionally equivalent bots.
Why are they not running on CGOS?
Christoph
_
On Mon, 20 Oct 2008, Don Dailey wrote:
On Mon, 2008-10-20 at 13:47 -0700, Christoph Birk wrote:
On Mon, 20 Oct 2008, Don Dailey wrote:
And now after about 11,000 games we are within 1 standard deviation and
the score is very close to 50% so I have confidence that we have 2
functionally
On Wed, 29 Oct 2008, Mark Boon wrote:
the implementation with one that clears the array instead of increasing the
marker. And I'll only have to make changes in one place instead of dozens, or
more. Not that I had this in mind when I designed it, it's just the
beneficial side-effect of OO design
On Nov 18, 2008, at 11:28 AM, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
It depends very much on what exactly you mean by "amateur master
level". Is it a level that compares to amateur master level in chess?
And what is amateur master level in chess? USCF master, FIDE master
or internat
On Wed, 19 Nov 2008, [EMAIL PROTECTED] wrote:
I think that would not be enough, because that would only fix one point.
You can use the width too. That should give a pretty good comparision
for moderatly strong/weak players (see below).
EGF ratings are not pure Elo ratings. EGF ratings are weig
On Tue, 30 Dec 2008, Don Dailey wrote:
On Tue, 2008-12-30 at 14:23 -0500, Jason House wrote:
I hope you're joking...
It lost twice as many as it won, you're not convinced? :-)
Ok, I'll let it run a few hundred more games just in case it somehow
manages to turn things around.
I agree with
On Tue, 30 Dec 2008, Don Dailey wrote:
Rank Name Elo+- games score oppo. draws
1 base 2000 296 199 3 67% 18880%
2 d3p 1888 199 296 3 33% 20000%
I think I have proven decisively that 3 doesn't work, it lost 2 out of
the 3 games I played :-)
ok, you go
On Tue, 30 Dec 2008, Don Dailey wrote:
Distance 3 could easily play worse - we shall see. Just because a
distance 3 move is sometimes good doesn't mean it will make the program
play better not throwing those out. If it's RARELY best, then the
reduced effort and increased focus on (usually) mo
On Mon, 26 Jan 2009, matt harman wrote:
With an empty board, assuming I am using proximity heuristic of 1 Manhattan
distance,
from the root I will have 4 possible positions which will make up 4 children of
the root.
Each child will be simulated (eg) 1000 times and a winrate is calcuated.
If ch
On Mon, 26 Jan 2009, matt harman wrote:
Thanks for the quick answer, so 1 simulation is run because too many
will give lots of noise to the result? if only 1 is run then the 4 children can
either win or lose
the single simulation 0 or 1. This would be non-deterministic so how would you
decide wh
On Tue, 3 Feb 2009, Jason House wrote:
That kind of setup should make it easier to compare. There have been a few
times in the past where multiple authors posted similar bots with the same
configurations and let them all duke it out on the server for a while. Once
upon a time, I was the owner o
On Feb 6, 2009, at 9:55 AM, Isaac Deutsch wrote:
By the way, I've seen 2 games when checking my bot's status where
one of the
"myCtest" bots lost because of an illegal ko move. Maybe there's a
bug in
handling superko?
Not a bug, I never implemented it :-(
Christoph
__
On Fri, 17 Apr 2009, Brian Sheppard wrote:
I saw on Sensei's Library page http://senseis.xmp.net/?CGOSBasicUCTBots that
there are a range of basic UCT implementations that would be excellent
opponents (rating 1171 through 1603), but I haven't seen these players in
weeks. Is it possible to get the
On Mon, 20 Apr 2009, ?ukasz Lew wrote:
Is there a rating drift? I remember that pure UCT no RAVE with 100k
playouts got over 1700 elo.
That seems a little high. My 50k-pure-UCT searcher is around
1580 for a long time.
Christoph
___
computer-go maili
On Mon, 20 Apr 2009, ?ukasz Lew wrote:
Is there a rating drift? I remember that pure UCT no RAVE with 100k
playouts got over 1700 elo.
There is no 'anchor' (FatMan-1 ?) runnig on CGOS-9x9 for at
least 36 hours. That could create a drift.
Christoph
__
On Tue, 21 Apr 2009, sheppar...@aol.com wrote:
Pebbles learns from every game it plays. So I can't agree; drift is
inherent.
But since you had bugs in the earlier version, how do you know,
without restarting it after bug-fixes how much of the drift
is from the learning part and how much from th
On Tue, 21 Apr 2009, Jason House wrote:
AMAF and RAVE are the same thing. The MoGo team pioneered use of AMAF but
called it RAVE because of their paper's target audience.
I always thought them to be the application of the same heuristic at
a different time.
AMAF is usually applied at the end of
On Fri, 5 Jun 2009, Don Dailey wrote:
Handicap games opens a can of worms. The last time we discussed it,
it was difficult to get any kind of reasonable agreement on how to do it.
Handicap games are for humans ... they get frustrated losing
over and over. Computers have no problems with that.
On Mon, 15 Jun 2009, Brian Sheppard wrote:
Please don't do anything that decreases the frequency of games in order
to accommodate programs that want to play on multiple venues. Keep venues
strictly separate. Programs that want to play on multiple venues can just
log in multiple times.
I second
1 - 100 of 289 matches
Mail list logo
