t infinite time. That doesn't
> seem like an ideal situation for solving it.
I believe go, on any size board, is already solved (using the minimax
algorithm) in both finite time and memory. (At least for a ruleset
using super-ko; I'm not so sure about Japanese rules.)
Darren
--
Da
> Yes, MoGo gained much more from the longer time setting than Mr. Kim
> did. Note that Mr. Kim used very little of his time in the one-hour
> game. He said after the match that using more time would not have helped
> him.
I imagine that is typical as white in a handicap game; you play solid,
good
ose there is indirectly some go
opening knowledge (aka "good shape") in the heavy playout algorithms.)
Darren
--
Darren Cook, Software Researcher/Developer
http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic
open source dictionary/semantic network)
raries, etc.?
I'd also be interested to hear how inefficient the cluster was (e.g.
1000 CPUs won't be doing 1000 times the number of playouts, there must
be some overhead).
Darren
*: Sorry, I've forgotten the new term we are supposed to use.
--
Darren Cook, Software Rese
1.1
So, it seems 8.5 komi may favour white.
Darren
--
Darren Cook, Software Researcher/Developer
http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic
open source dictionary/semantic network)
http://dcook.org/work/ (About me and my work)
http://darrendev.blogs
other major go servers.)
Darren
--
Darren Cook, Software Researcher/Developer
http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic
open source dictionary/semantic network)
http://dcook.org/work/ (About me and my work)
http://darrendev.blogspot.com/ (blog on php
res of the game on the larger
board size, but 19x19 is too big too experiment with some brute-force
ideas on today's hardware. I believe 13x13 is the perfect test-bed for
the next algorithmic breakthrough.
Darren
--
Darren Cook, Software Researcher/Developer
http://dcook.org/mlsn/ (English
tion is
perhaps I can help them all by working on a really good opening library
(or connection patterns, or optimized UCT implementation, or whatever is
needed most).
Darren
--
Darren Cook, Software Researcher/Developer
http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic
t know, it could just be coincidence.)
Darren
--
Darren Cook, Software Researcher/Developer
http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic
open source dictionary/semantic network)
http://dcook.org/work/ (About me and my work)
http://darrendev.blogspot.com/ (
d the top programs).
Darren
--
Darren Cook, Software Researcher/Developer
http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic
open source dictionary/semantic network)
http://dcook.org/work/ (About me and my work)
http://darrendev.blogspot.com/ (blog on php, flash,
like this mailing list, CGOS, open source
projects, etc.
By data I mean things like: game records, or board positions, marked up
with correct/incorrect moves; game records generally; pattern libraries;
test suites; opening libraries.
Darren
--
Darren Cook, Software Researcher/Developer
http
>> 9.5pt komi is unreasonable. I agree with Don that perfect game value
>> will probably turn out to be 7pts, though I'm keeping an open mind that
>> it may be 6pts. I'd be surprised if it was 8pts, though that could just
>> mean I've been analyzing the wrong openings :-).
>
> On 9x9 with Chin
komi is unreasonable. I agree with Don that perfect game value
will probably turn out to be 7pts, though I'm keeping an open mind that
it may be 6pts. I'd be surprised if it was 8pts, though that could just
mean I've been analyzing the wrong openings :-).
Darren
--
Darren Cook
http:
>>> Unfortunately, I used level 10 in the gnugo only games but in the big
>>> study we use level 8. ...
> ... it's a major pain running those games and it ties up my
> machine.
Hi Don,
I just know your reply is going to make me slap my head and go, "of
course", but I've been puzzling over this f
> ...
> That mogo would not know to move to nakade point c1 with either color?
Mogo tends to get confused on nakade positions when there are still
external liberties. Here is my report on this with a couple of examples:
http://computer-go.org/pipermail/computer-go/2007-October/011327.html
If I'v
> See the handtalk's winning rates on cgos 9x9
> (http://cgos.boardspace.net/9x9/cross/handtalk.html).
> He won agains MoGo at 60% but his rating is about 200 ELO behind
> it. This happened probably because he know MoGo's weakpoint,
> misunderstanding of L&D at corners (including Nakde) very we
>>> ... it would explain the scaling curve flattening out.
>>>
>> Though the curve can also be flattened/made-curvier by changing the base
>> of the x-axis. Currently it is log-2. Proportional to actual playouts
>> would make it appear flatter.
>>
> No, that would make it appear more curved
> ... it would explain the scaling curve flattening out.
Though the curve can also be flattened/made-curvier by changing the base
of the x-axis. Currently it is log-2. Proportional to actual playouts
would make it appear flatter.
Darren
___
computer-
go4go.net/v2/modules/collection/sgfview.php?id=17016
Extremely rare plan: Black played the ladder (79-105), which was not
working, but he got nice compensation
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work)
h
t too complex to code up).
(I bet I'm not the only one on this list whose first go program was
based on influence calculations; it'd be somehow warm and comforting to
have a reason to try it again ;-)
Darren
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free d
> In one of my posts I'm pretty sure I published the raw data.
>
> Nevertheless, I will see if I can find the data. ...
Hi Don,
Around Jun 26th last year you sent me (or I downloaded) some files. I
have 04.tar.bz2, 05.tar.bz2, 06.tar.bz2 (which I think is cgos
archives), cgos.tar.gz, evalgo.
> 1K ~ 100 K / sec is much faster than "a dozen" / sec of a conventional
> program.
>
> Do they calculate dragon safety (eyes, connections, patterns ...)? if not,
> the estimate will be VERY unreliable.
No, because they play the game out to the end where everything is as
safe as it can be. Then,
ia does not":
http://computer-go.org/pipermail/computer-go/2007-April/009714.html
Ah, I just managed to find this:
http://computer-go.org/pipermail/computer-go/2007-July/010432.html
http://computer-go.org/pipermail/computer-go/2007-July/010446.html
Darren
--
Darren Cook
http://dcook.org/mlsn/
>> One more puzzle: this processor is rated at 2.4GHz,
>> but cpuinfo tells a different story:
>
> It's because SpeedStep is working. You can stop it in BIOS setting.
> http://en.wikipedia.org/wiki/SpeedStep
Thanks! I've the same CPU and just discovered mine is running at 1.6Ghz
too! For linux u
> the OS is constant, they seem to offer benchmarks on 4 different
> hardware platforms
Sorry for the noise. I mis-read the top page: they use two platforms,
Gentoo on Pentium 4, and Debian on AMD Sempron. (They are very roughly
the same, but java6-server stands out as being considerably quicker o
>>> http://shootout.alioth.debian.org/
>
>> To clarify: I don't really like these non-scientific benchmarks (in
>> many cases I assume no one or only really few people (not including
>> me) really understand what each micro-benchmark is really measuring).
I posted the link to the Shoot-out site
are not the top of every benchmark. E.g.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=all
Darren
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work)
http://dcook
>> I was thinking that it could be quicker to do prototyping in something
>> like python, while having fast low-level functions in C. ...
>
> I have done a Python binding for the current libego. You can get it from
> http://mjw.woodcraft.me.uk/2007/pyego/ .
>
> I did this as an exercise in using
> Or you use Erlang as Vlad suggested. I've started something like this
> and I'm using libEGO for the move generation. ...
Here is the erlang vs. C++ language benchmark comparison:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=hipe&lang2=gpp
And here is LISP SBCL:
http://shoo
> Am I confused in my understanding that a weakness of MC evaluation is
> that due to its random play it will miss sequences where there is only
> one winning move at each play? ...
This was exactly the topic I tackled in this article:
http://dcook.org/compgo/article_the_problem_with_random_playou
ly-alive-group as low priority. So, in that
sense, they do have a concept of nakade.
(I hope Remi, or one of the Mogo developers, will correct me if I've
misunderstood what is going on.)
Darren
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
ht
Joshua Shriver wrote:
> I've been looking into GPGPU for several years now, there was even some buzz
> in the comp-chess stream but the downsides seemed to be to much. Think the
> big problem is the latency on the PCI/AGP bus. Though that might not be as
> much an issue now with PCI-x, etc.
Thanks
compile such code to real hardware assembly. In the mean
time our GPU simulator Sm implements various features expected to be in
GPUs in the near future, such as a unified vertex and fragment
instruction set.
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictiona
>> I've played the top 9x9 programs at 9x9, and so have several
>> other amateur Dan players, and I think we all agree that the top 9x9
>> programs have reached amateur Dan level.
I'll add another vote for that opinion. (3-dan-ish, at 30-60s/move, on a
2.8Ghz Celeron).
Robert, you can get Mogo he
> 9x9 games is a bit silly. it doesn't actually capture any extra
> information about the program, since there's no such thing as
> a 9x9 rank to compare with/against, much less a dan rank.
I disagree. In my studies of 9x9, over a number of years, the human
19x19 rank generally carries over to 9x
better optimization was a key feature: it seems
everybody sees design by contract as all about safety. But it is about
describing the problem more accurately to the computer so that it can
not just find more bugs at compile-time but also so it can generate
better code at compile-time.
Darren
> (I just joined this list last week, this is my first post)
Hi Colin, welcome to the group.
> I still find it easier and faster to code in Java (using Eclipse) than
> with C++. The OP mentioned that Java is slow, but I have actually
> read that in the recent years it has become comparably faste
> [XML] is like going backwards to the 60ies (OK, there are some thing
> XML is good for -- is't developed as HTML successor and in this area
> XML has quite some advantages; in some cases it's also good as
> intermediate data exchange format, but not always; as an primary
> format to save data in
> But as one who has to program some php for living, I wonder why would you
> like to use a language like that? I am *so* tired of the way it happily
> declares a new variable when you mistype one, or finds mistyped function
> names only at run time, if you happen to call that function...
Or reph
On Oct 2nd 2007 Heikki wrote:
>> I was thinking that it could be quicker to do prototyping in something like
>> python, while having fast low-level functions in C. Since we already have
>> Lukasz Lew's ego library, I wonder if anyone has written a wrapper around it
>> to call it from python (or rub
> How does one configure MoGo to do a fixed number of playouts per move?
> I saw only time-based command line options.
On Oct 7th Sylvain wrote:
--nbTotalSimulations 3000
Once you set this option it ignores all other time settings.
Darren
___
compu
> yes. Allowing everyone to add non-standard properties means that
> you cannot validate the files in a meaningful way anymore.
> Also, I haven't really seen convincing use cases for non-standard
> properties. SGF defines (more than) enough, even if some of them
> are a bit underspecified ...
I've
et tracked down exact information,
who is speaking, etc. even in Japanese.
Darren
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work)
http://dcook.org/work/charts/ (My
difference was.
>From the above position I played very passive moves for black, and
white's confidence rose to 0.6, but no higher. I.e. Mogo is seeing white
is dead in some paths, but it is seeing white is alive in more paths.
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Ch
>> I wouldn't put it as strongly, but I also noticed that MC and UCT and suclike
>> techniques were not mentioned at all.
>
> to be fair to the article, in fact they were. you just have to click on all
> of the
> links in the article to see it.
For others, like me, who missed the link, it is he
e able to
test it with PHP.
Darren
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work)
http://dcook.org/work/charts/ (My flash charting demos)
___
computer-go mailing lis
> It preserves the tree if and only if you add:
> --pondering 1
>
> If you don't want to use pondering, but you still want to keep the tree
> between moves, add
> --keepTreeIfPossible 1
>
> (not documented, and from my memory, it may be not the right option :p)
Good guess, that worked. It someti
>> Looking at the performance of hb-amaf-1k I suspect you have some
>> serious bug(s)
> ... I'm starting to run out of ideas. ...
As Magnus suggested, look at some of the games you are losing but should
be winning. When I was testing libego vs. gnugo, and libego was losing
everything, it wasn't un
in the
debug output that says how many nodes it is carrying over?)
Darren
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work)
http://dcook.org/work/charts/ (My
> Thank you for the releases of the Windows version and the Linux
> version for older processors.
>
> The Windows version, however, seems much weaker than MoGo that running
> on KGS these days on 19x19, even giving much longer time setting such
> as "--time 300" for example. I guess some other
> What are the options for someone who ... doesn't have a Linux system
> currently?
LiveCDs ( http://en.wikipedia.org/wiki/LiveCD ) allow you to do a
temporary linux installation.
Of course, then you have to decide which one, and which distro. I would
think any of those marked for "general" in t
er print? (or setting up stdout to not
buffer?). A quick google confirmed python is buffering stdout, but I
couldn't find the flush command.
Darren
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work)
http:/
I can
make the histogram and derive the median that way. E.g. 100 distinct
numbers means I just need 100 counters. I also get the mode as a bonus.
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work)
http://dcook.org
>>> The statement "will never give a strong computer go program." is rather
>>> devoid of meaning. You either should define "strong" ...
>> OK, I'll add something. By strong I mean dan level.
>
> In that case, the statement seems downright wrong. We know from both
> theory and Dan's experiments
> The statement "will never give a strong computer go program." is rather
> devoid of meaning. You either should define "strong" ...
OK, I'll add something. By strong I mean dan level.
> I definitely agree that once you've played a few thousand uniformly
> random games, there is little to be ga
> "What I am calling random playouts for the purposes of this article
> give all legal moves equal weight and randomly chooses one of them,
> and this process is used for both players all the way to the end of
> the game."
>
> I get the impression that this also includes filling single point
> eye
'd be surprised if the UCT experts on this list will find much new
there, but I hope some people will find it of value.
Thanks to Magnus Persson for reviewing an earlier version.
Darren
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/wo
.org/onlinedocs/libstdc++/17_intro/license.html
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work)
http://dcook.org/work/charts/ (My flash charting demos)
___
co
> I don't use functions to convert 0-n to x, y. I use arrays of constants
> instead. It's faster.
APD.get_x(d), for instance, is doing a lookup in an array that is made
by the constructor once when the program starts up. Everything is inline
so it is the same.
Darren
__
> I always used a 1-dimensional 25x25 = 625 integer array with 0 for
> black 1 for white 2 for empty and 3 for border (everything else).
>
> This way I can have a 21x21 board with 2 rows of border cells
> surrounding it.
David Fotland, on the other hand, seems to use a 19x19 grid, and detect
off
I got this from the AGA rules which I (falsly?) assumed to use
chinese counting (http://www.cs.cmu.edu/~wjh/go/rules/AGA.html)
>
> "At one time, the Chinese rules compensated White with an extra point
> when Black got the last move. If Black's last move was to fill a ko he
> or she had
>>> I actually think that under Chinese rules White wins too because
>>> Black owes 1 point for playing the last (and first) move.
> ...
> I got this from the AGA rules which I (falsly?) assumed to use
> chinese counting (http://www.cs.cmu.edu/~wjh/go/rules/AGA.html)
I only saw this in section 4,
>> Or did you mean it is too much bother to connect with gogui while
>> also running your code in a debugger?
>
> That would be great! How do you do that (without going through a
> million zillion steps each time)? I use Visual Studio.
Can Visual Studio connect to a running process?
On linux you
> I thought the rules for Go were rather simplistic when it came to scoring:
> Count all eyes, and spaces owned by each player and each captured
> stone counted as a point. Whoever had the most points wins.
>
> How does that differ from Japanese, Chinese, Korean?
Hi Josh,
Many of your recent ques
>> New lesson learned. It depends on the rule set if something is correct
>> or a blunder.
>> So far the Go-masters told me, it does not matter, its practically the
>> same. Obviously its not. This is not some weired, constructed
>> position, it really happened and it does not look strange at all.
release, no-one will see it, and I'll go back and make it
beautiful next week. And people will think it must be very active
because we got to version 0.2 so quickly!"
Darren
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (Abou
> At $39.95 that's just shy of $16 million. Wow Even at $1 a copy that's
> almost 1/2 a million dollars.
I'm reminded of a post this list about 10 years ago (maybe by Mark
Boon?), probably in the context of winning the Ing prize: if you are a
very good programmer, there are easier ways to get rich
>> I think this is what I want. Thanks! So I might have to repeat this
>> a few hundred times to actually get a legal position?
>
> Are you aware that nearly all of these positions will be final positions?
> ...if you actually need middle game positions you will have to
> use a different procedu
Don wrote:
> Presumably, if you run 1000 random play-outs from a given position you
> will get a fair indication of "how good" the position is.
>
> But what if you are able to prune out many of the bad moves in that
> simulation? Would this improve the accuracy of the simulation?
>
> Prob
>>> Can MPI be as quick as threads on a 2- or 4-core single
>>> machine?
>
> no, but I think you are worried about something that is such a a small
> percentage of compute time that I doubt that it is significant for a Go
> program.
A random playout might complete in 10 microseconds. Is thread or
cluster of 4 single-core machines and a single
4-cpu machine. That is a kettle of fish for a different thread. ;-)
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work)
http://dcook.org/work/charts/ (My flash charting
> After throwing out the low and high ratings the top 5 players average
> about 132 ELO per doubling and the bottom 5 average an increase of
> about 210 per doubling.
> ...
> I suspect Lazarus at
> the highest level I tested is within a few hundred ELO points of
> perfect play. It's still a lon
>> I thought the point being made was that the games were played without
>> byo-yomi.
>
> Isn't that a time control not usually played in serious games?
No, the other way round: all serious ama or pro games (at least, that I
know of) are played with byo-yomi. In the two-day tournaments the
byo-y
> I think Remi was making the point that the CrazyStone games were played
> at a time control not usually played in serious games. Therefore he
> concludes the rating was inflated. ... If you spend too much time
> building up a won position, how can you claim a "moral victory" if you
> lose on t
r me to understand :-).
Darren
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work)
http://dcook.org/work/charts/ (My flash charting demos)
___
computer-go mailing list
c
> libego is a very optimised library. indeed, very hard
> to change. If it fits your needs, go for it. Its
> simply the best you can do.
>
> BUT, If you want to try different MCGO approachs with
> libego, I'm sure it will be far more hard to change
> than using slowish java.
I've been refactorin
> Plenty of data can be mustered for either side of this question, but the
> assumption that Java is necessarily, inherently slower than C/C++ is
> outdated.
So why is libego many times faster (at doing random playouts) than orego
on the same hardware? :-). I got the impression from you that you d
> The game:
> http://www.grappa.univ-lille3.fr/icga/round.php?tournament=169&round=9&id=2
>
> Sylvain posted some anaylsis from MoGo side. Following are my comments
> (KGS 4k) as I understand the situation:
>
>> After white (mogo) H2, MoGo was estimating 74%, and expecting:
>> H2 G1 H3 B1 A1 B3 H
> In the second game against CrazyStone it played like a weak
> MC-program in the opening - playing all moves in the center and
> allowing Crazystone as white to make two rock solid groups which in
> my experience should be an easy win for white. But Crazystone then
> played some slow moves and mad
> Let's take a basic example of a leaf node in an MC search tree that
> hasn't been expanded, but has 4 children. Let's say that random
> simulation through the children have winning percentages of {46%, 51%,
> 47%, 48%}. Assuming a uniform simulation policy, the winning percentage
> would be the
Hi Jason,
In UCT the monte carlo searches (I find it clearer to call them "the
playouts") are always run to the end of the game. So they always
accurately (well, as accurate as a random playout can be!) take sente in
account. Therefore my understanding is that it does not matter whether
they start
> I've been messing around with where to apply heuristics. Candidates
> include:
>
> 1) In the UCT tree, since this is earliest in each playout.
> 2) In the moves beyond the tree ("heavy playouts"), since this is where
> most of the moves happen. Because this part is so speed-critical, ...
Remi (
Does anyone know of UCT being used in games other than go, or outside
games altogether, such as travelling salesman problem, or some
business-related scheduling/optimizing/searching problem domain?
Thanks,
Darren
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free
I've been training from game records played in Japanese rule sets, but I
am using Chinese scoring. I was braced for obscure seki and triple kos
but the issues that are coming up are more mundane:
1. In Japanese rules when you have no ko threats you pass, then the
opponent connects. In Chinese rule
>> "Could not compile libego" is not a very helpful error message. What
>> exactly did the compiler complain about? My guess is that you don't
>> have the required boost libraries installed.
>
> Yes. It must be that. I didn't know about boost libraries. Where can I
> find that?
http://boost.org/
> Jason, can You tell me why You don't want to use libego instead?
> Actually this is open question to all comp-go readers.
>
> Is libego too complicated? Do You have problems with compilation?
> Or You are not comfortable with the GNU license? Any other reason?
I've been studying and experimenti
> I just received the June issue of Scientific American and
> found a 1.5 page article on Computer Go and UCT.
Just so I'm ready next time a computer go question comes up at a pub
quiz, it says the Monte Carlo method was "First incorporated into Go
Programs in the 1970s". I'd have guessed 30 yea
> What is the most extreme example of being behind (either by X stones, or
> by some percentage, such as Heikki's 50% above) where the losing player
> can make a comeback and win the game (assume perfect play by both
> players from that point)?
I realized this is quite trivial: a board position wh
Heikki Levanto wrote:
>>> I don't make any tests for the first 20 moves. Thereafter, I
>>> resign if
>>> - I have no stones left on board
>>> - I have less than half the number of stones my opponent has
>>> I also pass if my opponent has no stones left on board.
Eduardo Sabbatella wrote:
>> My
rams with
self-play: the results have to be taken with a grain of salt. And Google
won the competition because they tuned their algorithms using Bleu.
Darren
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work)
ht
>> [...] memory-saving technique of not expanding a leaf until you have
>> been through it many times (100, for example).
>
> I have been wondering about this: If it pays off not to expand a node
> until it has been visited 100 times, why not bite the bullet and make
> those 100 simulations in one
> smaller for larger boards. The only part of our program that is not
> strictly ANSI C++ compliant is is_there_input(), ...
> ...
> return select(1,&read,&write,&except,&timeout);
> ...
> If you are interested on a Windows equivalent, I might be able to
> provide one.
Hi Alvaro,
I'm interested i
> Valkyria uses to methods to bias playouts towards better moves.
Thanks for the reply Magnus. You said it will always try to react to the
last move, and only if no reaction needed will it choose a random move.
It sounds like that is something you only want late in the game, so is
that what you ar
> I've attached a 9x9 game; a complex game that ended in a 2.5pt win for
> white (at 5.5pt komi).
To save you opening the sgf, here is the terminal position:
A B C D E F G H J
9 . . . . . . O O O 9
8 . O # O O O O # # 8
7 O O # O # # O O # 7
6 # O O # . . # # # 6
5 # # O # # # . # # 5
4
correctly (e.g. less than 10% black wins). The above results were using
libego "out of the box", so it is easy to prove your theory experimentally.
Darren
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary)
http://dcook.org/work/ (About me and my work
Thanks for the replies. After studying some of the losses I realized the
problem: I was letting gnugo do the scoring and it was using Japanese
rules! So libego filled in all its territory while gnugo kept passing.
So now I'm starting gnugo like in [1] and getting results much more in
line with my
>> I have one interesting test that I do, which I take
>> with a grain of salt, but I use as a first guess estimate. I search
>> from the opening position a few hundred times and average the time
>> required to find the move "e5." ...
Yes, I noticed libego usually switches to e5 at some point bet
>> I've been trying the libego program "out of the box", and am up to
>> 200,000 UCT playouts, but still gnugo 3.6 on level 6 is winning 10 out
>> of 10. ...
>
> If 200,000 play-outs is being beat, something is broken. Even
> a bad implementation should do better than that.
>
> Does libego p
> http://greencheeks.homelinux.org:8015/~drd/public/study.jpg
> ...
> I'm actually testing 2 programs - both of them UCT style go
> programs, but one of those programs does uniformly random
> play-outs and the other much stronger one is similar to
> Mogo, as documented in one of their papers.
Hi
> Can anyone share their estimates of RAM used per 100k playouts, or
> other appropriate measure?
As part of my study of libego I've had the same question.
100K playouts (from an empty board) creates an UCT tree of around 21,000
nodes, which is using 795K. The node class uses 20 bytes, which is
g
201 - 300 of 330 matches
Mail list logo
