Re: [Computer-go] Aya won December 2014 KGS bot tournament
Hi! Note that looking into these mailing list issues did not die out - Michael is in the process of migrating it to a new server right now, I'm helping out with various configuration issues and will help admin it for the time being. It's work in progress, which is why the computer-go.org archive link doesn't work right now - sorry! On Mon, Dec 08, 2014 at 11:09:25PM +, Aja Huang wrote: > >From Erik's post > http://dvandva.org/pipermail/computer-go/2014-November/006950.html > > Looks like it's Gmail's problem. I'll report the issue directly to the > Gmail team. > > Aja > > 2014-12-08 22:58 GMT+00:00 Aja Huang : > > > Thanks Peter, Hiroshi and Rémi. > > > > Oh, seeing the posts in the archive I just realized a lot of emails from > > the list are surprisingly missing in my Gmail. Does anyone know how to fix > > it? > > > > Aja > > > > 2014-12-08 22:02 GMT+00:00 Rémi Coulom : > > > >> http://dvandva.org/pipermail/computer-go/ > >> > >> On 12/08/2014 10:40 PM, Hiroshi Yamashita wrote: > >> > >>> By the way, I can not see archives now. > >>> http://computer-go.org/pipermail/computer-go/ -- Petr Baudis If you do not work on an important problem, it's unlikely you'll do important work. -- R. Hamming http://www.cs.virginia.edu/~robins/YouAndYourResearch.html ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Computer-Go list seems to be dying? Time to move?
On Wed, Dec 03, 2014 at 04:09:00PM -0800, Dave Dyer wrote:
> Changing the mail host is only going to change the symptoms, not
> fix the problem. No one knows what google, microsoft et. al are
> doing today, much less what they will do tomorrow. Whomever is
> maintaining the mailing list is running on a treadmill no matter what.
It's not that much work, really - for me it takes maybe one issue per
year to take a look at; but you do need to look at it, otherwise
I suspect it slowly spreads to other blacklists.
It probably matters quite a lot what your subnet neighborhood is, maybe
dvandva.org is just in a bad one; mine lives in an academic network.
Typically, mailing lists do work even in the present and get their mail
delivered to most places.
--
Petr Baudis
If you do not work on an important problem, it's unlikely
you'll do important work. -- R. Hamming
http://www.cs.virginia.edu/~robins/YouAndYourResearch.html
___
Computer-go mailing list
Computer-go@dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Computer-Go list seems to be dying? Time to move?
Hi!
On Thu, Dec 04, 2014 at 12:12:52AM +0100, Erik van der Werf wrote:
> I just noticed in the archives that none of the last 3 messages sent to
> this list reached my gmail account. One of them was by a well known
> conference spammer, but the other two (by Remi and Ingo) definitely should
> have made it through. Like Ingo, I recently also tried to register another
> address but that didn't work either.
>
> Perhaps we need to move the list elsewhere?
I run a mailman instance that handles various mailing lists - Pachi's,
but also e.g. a fairly lively mailing list for Czech beekeepers (really!)
and I do try to take care of keeping delivery from that host to other
mailservers working.
I can host this mailing list, ideally even back in the computer-go.org
domain (otherwise, as computer...@v.or.cz).
Michael, what do you think? Would you be ok with me hosting the
mailing list? Or do you plan to take a look at the delivery problems
yet?
Petr Baudis
___
Computer-go mailing list
Computer-go@dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Delivery Problem of the list
Hi! On Sun, Nov 16, 2014 at 08:38:43PM +0100, "Ingo Althöfer" wrote: > in my eyes the best solution for the "non-delivery problem" > would be to have the list on a server with an IP address > that is trustworthy for "all" mailing services. But such "trustworthy" status is highly transient, so this isn't really a long term solution. There are two aspects: (i) Some mail servers are over-paranoid about mail they receive and have overly strict rules. gmx.de is one of the most famous examples, I had a lot of trouble in the past with delivering to gmx.de myself. If the mail server you use is dropping the incoming mails, I'd regard that as primarily a setup problem on your side and the responsibility of your sysadmins to deal with. Try using support channels to complain to them, or consider switching to a different mail erver. (Unfortunately, I don't have any good recommendations myself, I run my own; maybe others do have.) (ii) Typically, if the mail servers bounce the message, they include some information about why and what to do about it - e.g. a URL with blacklist removal option etc. These should appear in the logs and/or reach the list admin as uncaught bounce notifications. Sometimes, this can be dealt with easily, sometimes it requires too much work / payments / etc. But it would be good to know whether our list admin is watching uncaught bounces and taking any action? Kind regards, Petr Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Zombie processes
Hi!
On Sun, Oct 26, 2014 at 10:30:10AM +, Nick Wedd wrote:
> I wonder how practicable it would be for a bot, on startup, to search
> for other copies of itself running, and issue a warning if it finds any.
I think it would be much easier in practice if the program made sure
it does not keep running when its parent process (kgsGtp) dies. This
can happen in multiple ways - either by doing this explicitly,
http://stackoverflow.com/questions/284325/how-to-make-child-process-die-after-parent-exits
has a couple of ideas, but even a much more elegant way is simply not
overriding SIGPIPE. Then your process will get that signal when trying
to reply to a deceased kgsGtp and die automatically.
I suspect these problems stem from disabling SIGPIPE which really
shouldn't be necessary for anything in this context anyway.
Petr Baudis
___
Computer-go mailing list
Computer-go@dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Definition of single-point eye
Hi! On Thu, Oct 23, 2014 at 03:17:41PM -0700, Peter Drake wrote: > I'm writing up some "how to play Go" flyers and and want to make sure I'm > being precise. How is this for a definition of a [single-point] eye? If this is supposed to teach beginners play Go, I think precise definitions are inadequate - I'd propose to just show how it *looks* like on a diagram or two. I typically start by explaining how capturing works in general, then pointing out that one of the liberties may be "inner" (a single point eye, possibly in a corner), then showing that when a group has two such inner liberties that we call "eyes", it cannot be captured anymore even if otherwise surrounded, and we call that "life" So the question is what actually is your aim when explaining eyes. If it is to explain life and death, maybe it's easier to explain it directly and let the "eye" term fall out of that naturally, rather than starting with it. (Of course, there is a lot of special cases - starting with seki and then continuing in the eventual direction of moonshine life; but I think it's obvious that it's best to start easy. :-) Petr Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] some general UCT notes.
Hi! Thanks for sharing your observations. On Sat, Aug 30, 2014 at 01:10:10PM -0700, Dave Dyer wrote: > I found simple threading had a pretty sharp knee in performance at 4 > threads. In other words, 2 3 and 4 threads improved the overall amount > of work done more or less linearly to 3.5x, speed improvements fell off > rapidly for more threads. Do you exclusively lock the tree when working with it, or does Java allow some tricks to use the traditional lockless tree updates? > I've also been comparing "blitz" play which creates a copy of the > board at top level, and starts each descent with a copy of the board; > compared with "unwinding" play where every move is explicitly unwound. > Of course, the complexity of the unwinding varies a lot from game to > game, but I found that "unwind" is always faster, an average 1/3 faster > across several games. So if the complexity of unwinding your data > structures is not too great, it's worthwhile. Couldn't it be the case that your "board" object is just too heavy weight? Don't any surprising things hide in the constructors etc.? What actually takes so much time during the copy operation? (Also, in general - what is the relation between number of moves you make during a playout, number of different board points you visit by the moves, and size of the board? If the last is much bigger than the former two, it may make sense.) -- Petr Baudis Life is short, the craft long, opportunity fleeting, experiment treacherous, judgment difficult. -- Hippocrates ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
[Computer-go] Visualizing test games for performance analysis
Hi!
I have came upon an interesting trick for analyzing behavior changes
in noisy systems like game AI runs, that draws heavily on using some
abstract characteristics and visualizing them:
http://yieldthought.com/post/95722882055/machine-learning-teaches-me-how-to-write-better-ai
Has anyone tried something like this in Computer Go? It's been pretty
inspiring for me because I have always found finding bugs and
shortcomings in heuristics a really painful process.
One question is what game-continuous performance characteristics
to choose in Go. An obvious one is winrate, for reading measure
I guess also numbers of dead / unstable stones.
I guess I'll try to implement this for Pachi + gogui-twogtp
-debugtocomment, the tool itself can be engine-independent.
(Of course, given that we also simulate games during MCTS, this could
be brought into an even more interesting level.)
--
Petr Baudis
Life is short, the craft long, opportunity fleeting, experiment
treacherous, judgment difficult. -- Hippocrates
___
Computer-go mailing list
Computer-go@dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Update on the ICGA Journal
On Thu, Aug 21, 2014 at 07:29:56PM +0200, Rémi Coulom wrote: > I don’t know how many copies of the ICGA Journal are distributed. > I expect around 100 or 200. And a very large part of the subscribers > are not interested in Go at all. You’d make a much bigger impact by > publishing your idea on this list. Isn't this a bit of a false dichotomy? Thankfully, the ICGA Journal doesn't restrict authors to put up preprints on their homepages - I'd never have published in any journal personally if I couldn't also circulate my paper among the community, in the case of Computer Go via this mailing list - I think they are doing this reasonably right (of course completely open access would be even better but...). (I'm not sure what their stance towards archiving on arxiv is, but I don't consider that so critical personally.) I personally think you will meet much more resistance during the publishing process in TCIAIG than in ICGAJ - more, and possibly more critical/demanding reviews. This is definitely a good thing, especially if your academic circumstances don't depend on getting the thing published. So my personal strategy would be probably aiming at TCIAIG but if it doesn't work out (obviously not because the result is wrong but perhaps just not great/novel/useful enough for their standards), resubmit to ICGAJ - though I guess Ingo will not be excited to read this. :-) -- Petr Baudis Life is short, the craft long, opportunity fleeting, experiment treacherous, judgment difficult. -- Hippocrates ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Update on the ICGA Journal
Hi! On Thu, Aug 21, 2014 at 02:46:11PM +0200, "Ingo Althöfer" wrote: > > > Then I'd suggest that the homepage is updated so that it doesn't list > > > 34-1 from March 2011 as the latest issue (both as direct link and in the > > > contents database). > > It seems you have been looking on an outdated website. > From this site > http://icga.uvt.nl/?page_id=26#blank > you get at least the TOCs until June 2013. Frankly, I can't figure it out. :-( Maybe it should be available when I click "TOC" in the Navigation section, but literally nothing happens at that point, the page doesn't change or anything. (Both in Firefox and Chrome.) (Still, I think my point stands - "ICGA journal" google query will bring the original page http://ticc.uvt.nl/icga/journal/ with old "Latest Issue" as the first result to me and nothing on it indicates to me that I should look further.) Kind regards, Petr Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] ICGA Journal
Hi! On Thu, Aug 21, 2014 at 12:44:19PM +0200, "Ingo Althöfer" wrote: > > - at least I hope it's still being published, > > ??? (So you are not a member of the ICGA - otherwise you > would know better) Unfortunately not right now, as my Computer Go research profile is very low in recent years. > Of course, the ICGA Journal keeps being published. I have all issues > until end of 2013. And the March 2014 issue will come soon > (delay of 3-5 months is an old ICCA/ICGA Journal tradition). Then I'd suggest that the homepage is updated so that it doesn't list 34-1 from March 2011 as the latest issue (both as direct link and in the contents database). I fear it might be turning some potential authors away. Kind regards, Petr Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Journals for computer go related papers
Hi!
On Wed, Aug 20, 2014 at 05:01:49PM +0200, Detlef Schmicker wrote:
> I am writing a little paper on a new backup operator for MCTS. Now I
> just realized, that most (nearly all) computer go related papers are
> published in conference proceedings.
>
> As a high school teacher I have no possibility to take part at
> conferences:(
>
> Do you think there are reasonable journals to consider or should I
> simply use arXiv.org?
I think the most popular journal choice for Computer Go papers is
IEEE Transactions on Computational Intelligence and AI in Games.
Another alternative (esp. if it has some domain specific details)
may be the ICGA Journal - at least I hope it's still being published,
I'm pretty sure at least some of the newer issues are missing from
their homepage so lack of activity there may not be a fatal sign.
Petr Baudis
___
Computer-go mailing list
Computer-go@dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] [ANN] Imago - Go board optical recognition
Hi!
On Tue, Aug 12, 2014 at 03:51:46PM +0200, Rémi Coulom wrote:
> Your dataset is way too easy, though. I tried only a few pics, and kifu-snap
> had no difficulty with them. I uploaded my own dataset there:
> http://remi.coulom.free.fr/kifu-snap/goban.tar.bz2
> I don’t own the rights for most of these photos. Found most of them with
> Google images. If anybody complains, I will remove the file. The .ks files
> are coordinates of the corners of the board (pixels, with 0,0 at the center
> of the image, IIRC). The .gob files are stone configurations.
>
> This is the result of stone-recognition (given the correct grid placement
> from the .ks file):
> http://remi.coulom.free.fr/kifu-snap/stone-recognition.txt
> (time is in milliseconds)
Thanks a lot for sharing that dataset! If Tomas is able to resume his
work on Imago, I hope he'll make sure to measure its performance on this
dataset as well - a good reference dataset was something we missed. If
not, we still hope Imago will encourage + provide a starting point for
others to work on this and spur some friendly competition and further
innovation in this area.
Petr Baudis
___
Computer-go mailing list
Computer-go@dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] [ANN] Imago - Go board optical recognition
On Wed, Aug 13, 2014 at 11:02:21AM +0200, Rémi Coulom wrote: > There was a bit of irony in Aja’s post, because kifu-snap & Crazy Stone > already did this in Sibiu. That’s the reason for the last sentence of his > message (the one you did not quote). Oh, I see. I didn't get that, sorry. :-) That's pretty impressive then! > I know the monthly subscription system that Unbalance used for this app > turned out extremely unpopular, but they are not willing to change it now. > Note that you can try the app for free for 10 days. If you don’t want to pay, > then just be careful to cancel your subscription before the end of the 10 > days. I didn't attend a real-world Go event for much longer than a year by now I think, so I wouldn't really get a chance to try kifu-snap for real too much. All I went by for a first impression of day-to-day performance was the feedback at https://play.google.com/store/apps/details?id=jp.co.unbalance.android.kifusnap but based on what you say, maybe most of the negative feedback was due to the required subscription rather than actual functionality... It's a pity that Unbalance insists on it. -- Petr Baudis Life is short, the craft long, opportunity fleeting, experiment treacherous, judgment difficult. -- Hippocrates ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] [ANN] Imago - Go board optical recognition
Hi! On Tue, Aug 12, 2014 at 01:15:11PM +0100, Aja Huang wrote: > Several cameras are relaying the games of the best players. A smart optical > recognition program automatically converts the streaming images to sgfs and > sends them to a Go program. The Go program then shows rich analyses over > the games, such as wining rate, best moves, principal variations, estimated > territories, etc, even predicts the next moves. A spectator is watching a > friend's game and wondering who is ahead. He doesn't understand Go very > well. He uses his android phone takes a snapshot. After 3 seconds, the Go > software oh his phone immediately tells him that his friend is ahead for 20 > points and winning with 90% chance. I'm sure we will get there, and maybe it won't take so long. :-) Working on a reliable recognition could be a good first step. I think analysis of the top boards is the most difficult part as it's similar difficulty as playing on that level. I think Remi is best positioned to build something like this as he has most of the pieces. Otherwise, we'd need a sort of (ideally open) ecosystem in the mobile, mainly an app that brings the engine, analysis visualization, recognition and some Go GUI all together. Doesn't require any scientific breakthroughs, just patience and technical skill. -- Petr Baudis Life is short, the craft long, opportunity fleeting, experiment treacherous, judgment difficult. -- Hippocrates ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] [ANN] Imago - Go board optical recognition
Hi!
On Tue, Aug 12, 2014 at 08:19:42PM +0800, Horace Ho wrote:
> I am curious what is the license for code use. It's not GPL (wonderful!)
> but what is it (like)?
It's the standard three-clause BSD licence:
https://github.com/tomasmcz/imago/blob/master/LICENSE
I.e. a simple, extremely permissive licence that *roughly* amounts to
"do anything you want with the code as long as you give credit".
Petr Baudis
___
Computer-go mailing list
Computer-go@dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
[Computer-go] [ANN] Imago - Go board optical recognition
Hi!
Tomas Musil (a student of mine), has created a state-of-the-art open
source Go board optical recognition software. We have focused on
completely automatic runs, so it automatically detects the board corners
and then the stones on the board, and the precision seems pretty good
at least in reasonable lighting conditions.
You can find it at http://tomasm.cz/imago together with a lot of
pictures, documentation and bachelor thesis describing the algorithms
in detail. In the thesis, Tomas also compares it against other similar
apps, and it appears Imago shows the best performance of all these
that were available to us.
Unfortunately, we specifically couldn't easily compare it to Remi
Coulom's Kifu-snap for multiple reasons - mainly because that is
a mobile app. Hopefully, someone will be able to compare these two
in the future. At any rate, I think Imago is a great starting point
for anyone who would like to play with Go board recognition.
My personal dream would be if we added video capability and further
improved speed + reliability in time for EGC2015 (in Czech Republic)
and were able to deploy it there to transfer large number of top boards.
But this will depend on how much time Tomas will have after the summer
(and we didn't actually check with EGC2015 organizers yet), so it's
still more of just a dream. :-)
Petr Baudis
___
Computer-go mailing list
Computer-go@dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Popular Youtuber Dwyrin (~6d amateur) starting a series playing against bots on KGS
Hi! On Tue, Aug 05, 2014 at 07:51:55PM +0200, Michael Markefka wrote: > care to shed some light on what you would work on? Right now I've been fixing some bugs uncovered by recent Pachi play and trying to finish some experiments from February. (It seems that when randomly choosing whether to apply a certain heuristic in a playout or not (perhaps with 80% probability or such) it may be *slightly* beneficial to actually do this decision once per playout for all the moves in the playout.) Nothing terribly interesting, but I'd like to wrap up in-progress stuff and tag pachi-11. Other than that, I'd like to mostly revisit some old stuff that really *ought* to have worked and brought great improvements, but never did. Maybe I'll unearth some obvious bugs with fresh mindset. :-) Generally, I want to focus on the never-ending quest for algorithmic breakthroughs, not small heuristic tweaks (...which is what again sucked me in last weekend; it's tricky to resist!) > Not related to playing strength itself, but regarding bots as teaching > aids, I'd be very interested in a user-friendly interface to have > Pachi analyze games within a given time per move or game, mark > blunders, provide the best current move and perhaps output some > statistics considering the shifting winning percentages. Very similar > to what Chess engines do. I did some proof-of-concept work on this, described at https://github.com/pasky/pachi/blob/master/README#L151 but it's just commandline scripts, definitely not user friendly. Pachi also has a JSON "streaming" interface that contains details on its thought processes. And it would also be pretty easy to build a CrazyStone-style web interface for Pachi, in principle. However, I'm unlikely to work on anything in this category personally, at least not as a free-time activity. I'll gladly support other programmers that would like to have a stab on such a thing and I think it'd be really awesome to build something like that, but for me there's tons more work deeper down in Pachi. > I remember someone looking into doing something like that with Pachi > on 9x9 over at L19, but I think there is some merit in expanding that > into a full-blown learning tool. I wish they'd have let me know... :) Petr Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] 9x9 and 13x13 game records
Hi!
On Sun, Aug 03, 2014 at 05:53:36PM +0300, Mikko Aarnos wrote:
> >for what purpose do you want to have the games?
>
> The games would be used for constructing fuseki books. Not the
> Fuego-style, but the type you see used in chess engines.
I'd advise against using computer games in that case, as the openings
used by computers are very uniform and potentially wrong.
For example, Pachi without opening book on 9x9 is very prone (played
in 80%+ games where the position arises) to a specific variation of the
opening that leads to a decidedly suboptimal middle-game position.
I suspect other programs will have similar biases *or* follow a fixed
sequence from their opening book that may or may not be good, but you
are learning *their* opening book instead of the *optimal* opening book.
On the other hand, humans probably will switch openings often and
adapt quickly when they figure that a specific opening is not good.
Petr Baudis
___
Computer-go mailing list
Computer-go@dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Popular Youtuber Dwyrin (~6d amateur) starting a series playing against bots on KGS
Hi!
On Mon, Jul 21, 2014 at 06:33:31PM +0200, Michael Markefka wrote:
> ... He has started a series where he plans to play
> against successibely stronger bots on KGS and comments the games while
> playing. The first video (https://www.youtube.com/watch?v=g6WyPTZNS4o)
> features very basic bots, so the future videos are going to be more
> interesting. One of his specific interests seems to be whether the
> bots would be good teaching aids and could be recommended as such.
Thanks for letting us know. Reading this actually prompted me to put
Pachi on KGS again, and perhaps I'll even do some work on a few ideas
throughout August. :-)
--
Petr Baudis
Life is short, the craft long, opportunity fleeting, experiment
treacherous, judgment difficult. -- Hippocrates
___
Computer-go mailing list
Computer-go@dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Computer-go Digest, Vol 54, Issue 4
On Thu, Jul 03, 2014 at 06:18:32AM -0700, Greg Schmidt wrote:
> Perhaps there is an argument that the UCB formula "won't generally let this
> happen" since it takes into consideration both win rate and tries to increase
> confidence by promoting the visit of nodes with low visit counts. Still, I
> can envision cases where time is running out, and UCT has just recently
> discovered a promising new branch.
In practice, choosing this promising new branch is very dangerous.
Promising new branches pop up all the time, but we can observe
them usually being swiftly squashed away by finding a refutation
to their current favorable move as soon as they start receiving
simulations, and their winrate fades back again.
The fact that some branch has already received many simulations means
that it consistently survived all sorts of proposed refutations.
--
Petr Baudis
Life is short, the craft long, opportunity fleeting, experiment
treacherous, judgment difficult. -- Hippocrates
___
Computer-go mailing list
Computer-go@dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] ieee aticle about computer go by Jonathan Schaeffer
On Thu, Jul 03, 2014 at 10:57:17AM +0200, Stefan Kaitschick wrote: > On Thu, Jul 3, 2014 at 9:00 AM, Darren Cook wrote: > > > > > If you had a choice between a 1% 65,000-wins move and a 70% 7-wins move, > > MCTS will keep exploring the 70% move, until it either reaches 65,001 > > wins, and can be chosen, or the winning percentage comes down to 1% also. > > > > BTW, that implies it would be very difficult to ever reach the situation > > you describe, as 1% win rate moves wouldn't be given 650,000 trials > > (unless all other moves on the board are equally bad, i.e. the game is > > clearly lost). > > > > What I dont understand, is why the variation that's trying to catch up has > to absolutely overtake the leader. > Shouldn't there be a substantial bonus for a late high success rate? The way this bonus is often implemented is that if a disparity between the move with the highest winrate and the move with the highest number of simulations is different, the program spends some extra time searching to give a chance to resolve this. (Conversely, if some move has been simulated so much more that no other move can overtake it in the number of simulations in the alloted time anymore, the search can be stopped early.) P.S.: No, I don't like Japanese byoyomi for Pachi. ;-) -- Petr Baudis Life is short, the craft long, opportunity fleeting, experiment treacherous, judgment difficult. -- Hippocrates ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] ieee aticle about computer go by Jonathan Schaeffer
Hi! On Tue, Jul 01, 2014 at 03:43:29PM +0200, Xavier Combelle wrote: > here it is: > > http://spectrum.ieee.org/robotics/artificial-intelligence/ais-have-mastered-chess-will-go-be-next > > I found it well writted and you ? A nice article, thanks for sharing it! But the first image is like putting http://www.cars-10.com/wp-content/uploads/2011/01/weird_car_design.jpg as the title image of a (serious) article on Google's self-driving cars. -- Petr "Pasky" Baudis Life is short, the craft long, opportunity fleeting, experiment treacherous, judgment difficult. -- Hippocrates ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Elo vs CLOP
Hi! On Tue, Feb 11, 2014 at 11:42:24AM -0800, Peter Drake wrote: > A naive question: > > In what situations is it better to use Coulom's Elo method vs his CLOP > method for setting parameters? It seems they are both techniques for > optimizing a high-dimensional, noisy function. Do you mean minorization-maximization? I'm not sure if it could be adapted for optimizing a black-box function sensibly. Moreover, it might not deal well with noisy observations. But most importantly, it can optimize a function on presampled data, while CLOP will perform the sampling itself in order to enhance the fit of the quadratic model. P.S.: I don't understand the details of minorization-maximization so maybe I'm wildly off in something. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Browsing the game tree?
Hi! On Sun, Dec 22, 2013 at 08:58:14PM +0100, Harald Johnsen wrote: > why not use the sgf format to dump your tree search ? Fuego does > something similar and then you can use gogui or any sgf viewer to > explore your tree search ; you can put comments to add for example > your rave stats or whatever. The sgf format also supports some tags > to add graphic hints like top moves. On Sun, Dec 22, 2013 at 10:01:08PM +0200, Francois van Niekerk wrote: > Have you considered outputting your tree to SGF? You can put as much > (or as little) information in the tree comments and, assuming you have > a good SGF viewer, it is easy to navigate the tree and figure out what > the engine was 'thinking.' Oakfoam has this functionality and I have > used it in the past to great effect. Hmm, I have always assumed that there is no SGF viewer that could handle ~500k-1000k node SGF files. Which one would you recommend? Most I have tried already take a while just to load Kogo's. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
[Computer-go] Browsing the game tree?
Hi! I'm wondering how are you investigating your MC game trees? For example, I'm interested in why Pachi did not consider move X, in what branches it _was_ considered and how did the simulations that considered it end up, what are its RAVE stats, etc. So far, I have been relying on debug prints and text dumps of the tree, but they are getting very inconvenient to use for long thinking times and deep trees. My worst case scenario is developing some data format and writing a few tools for visualization and investigation of game trees, but I'd be more than happy to find out that something I could use already exists. Thanks, Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Playouts vs playing strength (Detlef Schmicker)
Hi! On Sat, Dec 21, 2013 at 08:18:50AM +0100, Detlef Schmicker wrote: > Thanks a lot for sharing so much information. I am checking all your > suggestions :) > > I wonder, if the biggest difference between fuego, oakfoam compared to > pachi is not the use of progressive widening?! > > This might be narrowing the search very good for low number of playouts, > but becoming useless later?! I admit that I forgot what oakfoam uses here. I think both Fuego and Pachi are essentially Mogo clones in these regards, i.e. using Silver's RAVE formula and node priors (almost like progressive bias). Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Playouts vs playing strength (Detlef Schmicker)
Hi! On Thu, Dec 19, 2013 at 10:23:05AM -0700, Martin Mueller wrote: > I assume this is on 19x19? Yes, it is also my experience that pachi scales > better than Fuego on the big board. > I suspect that a big part of it is large patterns, which Fuego does not yet > have. But it is also possible that something else contributes to better > scaling, such as the UCT formula. In general, for scaling, the best tradeoff is to minimize bias at the expense of slower convergence. How to accomplish this is of course a difficult question, e.g. more randomness does not always mean less bias. Two things may help: (i) in Pachi, I always tried to make all decisions noisy; almost no rule in the playout is applied 100% of the time. (ii) there is rather involved code for reducing bias in some common tactical situations; I think many other programs don't have that much of this (though at least Zen probably does, I'd expect; maybe CS as well). As an interesting experiment, you might wish to test scaling with modified Pachi that has 'return false;' at the top of is_bad_selfatari_slow() body in tactics/selfatari.c. Out Pachi paper may also contain some ideas; it lists Elo effect of some of Pachi's heuristics with various time allowances; e.g. strength contribution of playout-heuristic tree prior is mostly constant, but CFG prior is more important with more time. But the biggest difference may be that Pachi had the enormous luxury of having its parameters historically tuned with similar game conditions as in real games, rather than the usual low-performance blitz, thanks to Jean-loup Gailly. You may find some of the parameter changes in history (e.g. 49249d but not only), but I'm not sure if there are clear or universal lessons in that and understanding the parameter semantics might involve reading a lot of Pachi's code. > My two conjectures are that 1. using knowledge from large patterns decreases > the effective branching factor in pachi, and/or 2. patterns allow it to focus > on better moves, improving the quality of the tree. > I think part 2. is relatively clear. Part 1. is not clear to me. I'm not sure there is a simple answer. One thing is that in low-end scenario, optimum pattern prior is *10 to *20 the usual prior, while in high-end scenario, optimum pattern prior is just *4 the usual prior. [1] So leaning heavily on patterns will make Pachi focus too much on just nice shapes. But I'd be surprised if the optimum moved much further down when going above the high-end scenario. [1] But it's also confounded by the fact that *20 pattern prior was when testing against GNUGo while *4 pattern prior was against Fuego. Performance data is not always perfect. :-) -- Petr "Pasky" Baudis Sick and yet happy, in peril and yet happy, dying and yet happy, in exile and happy, in disgrace and happy. -- Epictetus ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Playouts vs playing strength (Detlef Schmicker)
Hi! On Thu, Dec 19, 2013 at 07:52:04PM +0100, Detlef Schmicker wrote: > From the pachi README file coming with the version I use it should use > large patterns, at least it does mention using it and is not mentioning > that I have to turn it on :) All you should need to do is download the patterns.prob and patterns.spat files from http://pachi.or.cz/pat/ and place them in Pachi's current working directory. Pachi should print an information message on startup if it loaded the patterns. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Playouts vs playingstrength
On Sat, Nov 23, 2013 at 11:32:49AM +0100, Detlef Schmicker wrote: > Just to let you know: > > I did a comparison of the playings strength vs. playouts. > > This time I used 4 times the oakfoam playouts for pachi > (eg. 1000 for oakfoam 4000 for pachi) > > The graph shows how bad we become (in comparison) with more playouts:(. > >From the games the first impression is, that the joseki becomes worse > with more playouts e.g. > > http://www.physik.de/playouts2.pdf > The plot is 1050 games fitted with a 5th order polynome. The borders of > the plot are not statistical significant! It really is mainly a question of tuning of parameters, I'd believe - whether you are tuning with short or long games. C.f. tables 1 and 3 in http://pasky.or.cz/go/pachi-tr.pdf . In particular, tuning with small number of playouts will favor very strong bias - favoring quick and decisive solutions to local situations, that will however prevent long-term convergence in cases where your heuristics are wrong. Sometimes, this phenomenon becomes very arcane. For example, our smart implementation of dynamic komi works great with "low-end" or "mid-end" computing power, but increasing computing power further, its impact decreases almost to negative at extremely high end; we didn't figure out why that happens. One method that remains mostly unexplored in literature AFAIK is dynamically adjusting engine parameters based on elapsed/available time; certainly something good to explore and publish. I'm not sure if anything but such an explicit approach could get best performance both with low and high computing power. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Playouts vs playingstrength
On Sun, Nov 17, 2013 at 03:11:22PM +0100, Erik van der Werf wrote: > make sure Pachi isn't doing any kind of pondering in the > background. Indeed, Pachi will ponder by default. Turn pondering off by passing pondering=0 on the commandline. > pachi -d 0 -t =4000 -r chinese threads=1,max_tree_size=2048 Also, it may be worth passing pass_all_alive unless you are doing a sophisticated scoring procedure, to make sure Pachi captures all dead groups at the end of the game. P.S.: Do your results imply that on 4000 playouts/move, oakfoam is quite stronger than Pachi now? I'd love to hear more. :) How does the playout speed compare? -- Petr "Pasky" Baudis Sick and yet happy, in peril and yet happy, dying and yet happy, in exile and happy, in disgrace and happy. -- Epictetus ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] September KGS bot tournament: 19x19, slow
Hi! On Sun, Sep 01, 2013 at 08:00:48PM +0100, Nick Wedd wrote: > This may be the last "slow" tournament, with time limits of over an > hour each, that I run. Now that cloud computing is easily available, > I believe that there is little purpose in setting such slow time > limits. If you want to see how a bot does given a lot of thinking > time, it makes more sense to hire multiple processors than to let > it run for a long time. (If you think I am wrong, you can probably > convince me of it.) To rephrase what others mostly already said, I think slow tournaments are beneficial on two counts: (i) Implementing MCTS that is scaling well with additional time is much easier than with additional (parallel) processing power. (ii) Some people are already running their programs on the biggest hardware they can find / affort. I think this actually holds especially for the strongest programs where you can't really improve the move quality in any other way than increasing the thinking time. That's also the reason why I wouldn't be particularly excited... On Mon, Sep 02, 2013 at 12:15:59PM -0700, David Fotland wrote: > I think it would interesting to have a slow tournament with a fixed maximum > number of cores (4 or 8, since they are readily available). ...about this. Since I believe most programs scaling with threads will also scale with time (though of course not the converse), I'm not sure if a slow tournament would be more interesting than a regular one with number of cores fixed. -- Petr "Pasky" Baudis If I had more time, I would have written you a shorter letter. -- Blaise Pascal ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] SGF format: How to specify prisoner count?
On Sun, Sep 08, 2013 at 10:29:54AM +0200, Rémi Coulom wrote: > Yes, but I don't know the move history. What if I want to score a game from a > photo of the final position? If I don't assume balanced passing, I must > specify the number of prisoners (or number of extra passes). > > I think I can do it by adding pass moves to the sgf game, before the setup. > That should indicate which player passed more. In order to also show the prisoner count correctly in SGF viewers, I'd favor an approach that would first have a position setup with k-stone black group in atari and j-stone white group in atari, then two moves that'll capture the groups, then a position setup which will produce the current position. Maybe you could introduce a property as an SGF extension to declare that some SGF nodes are "virtual" and shall not be visible to the user. But not sure if the result still won't be too confusing. :) Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Measuring program strength
Hi! On Sun, Sep 01, 2013 at 11:18:57AM +0200, Detlef Schmicker wrote: > As I do not like using self play, I think of running 7 instances on KGS > with 1 playouts per move for CLOP. This should lead to even more > games per hour, as the humens are doing the opponent move and not using > my CPU time:) > > Comments? I think automated tuning against humans is still unexplored, perhaps except some experiments of Hideki-san, I'm not sure. I'd be interested to hear your experiences if you try this - I'd be worried about great amount of noise due to the strength variation of human opponents; besides different strenght/weakness mixes, you will not be playing just 1d humans all the time. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Measuring program strength
Hi! On Fri, Aug 30, 2013 at 11:41:12AM +0200, Detlef Schmicker wrote: > Up to now I always was able to measure oakfoam improvenment by playing > against gnugo. > (700 playouts against gnugo level 10 and 300 playouts against gnugo > level 0) By nature of the probability distribution, the play-testing measurements are most sensitive when your program is around the 50% winrate. Since you want to test with as many playouts as feasible wrt. time allocated (since that's closest to the real playing conditions), what I do is use komi to even the game out (fairly big komi at that, in the order of few tens of points). > But now we seem to be at a strenght, that makes this not very sensitive > anymore. I can change parameters,which have significant effects on > regression tests, but do not change playing strength against gnugo > anymore. I included fuego and pachi at a playing level playing 50% > against gnugo, but this only improved the sensibility a little. > > How do you handle this problem? > > What do you think is the reason? > > Thanks a lot for any secrets:) I'd say that possibly it's not the measurement being less sensitive to strength changes of your programs, but the absolute strength of your program less sensitive to bugfixes you make. Our returns are diminishing and like for human players, the stronger you get the more it takes to improve further, especially in the way of incremental bugfixing. -- Petr "Pasky" Baudis If I had more time, I would have written you a shorter letter. -- Blaise Pascal ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] 9x9 result in Olympiad
Hi! Congratulations to Zen! On Wed, Aug 14, 2013 at 12:03:08PM +0900, Hiroshi Yamashita wrote: > Aya Bit Col Gom Ami mar MCa Nom Win Zen Wins Rank > Aya 1 1 0 0 1 1 1 1 064 > Amigo 1 1 1 0 1 1 0 1 064 I'm curious about Amigo - has this program seen any new recent development? As far as I remember, this used to be a rather old and weak program, and its sourceforge page does not show any radical new development, does anyone have any details on this? Thanks, Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Computer Go at EGC
On Fri, Aug 02, 2013 at 08:15:49AM -0700, steve uurtamo wrote: > On Fri, Aug 2, 2013 at 6:20 AM, "Ingo Althöfer" <3-hirn-ver...@gmx.de>wrote: > > > Hello, > > will there be bot games at the EGC 2013? > > If so, can we watch them somewhere? > one's on kgs right now. Hmm, seems I've missed it. The web is not heavy on details, which programs competed in the end? Could someone summarize the results, please? And how was the scientific conference? :-) Thanks, Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
[Computer-go] Pachi for Android
Hi! A Pachi port for Android done by Emmanuel Mathis using his ElyGo frontend has recently been released on the Play store: https://play.google.com/store/apps/details?id=net.lrstudios.android.pachi Of course Pachi is not so strong especially on the 19x19 board, but I think it's still the strongest free Go app for Android? (Please correct me if I'm wrong.) And while the ElyGo UI library is not opensource, the rest of the app is, at: https://github.com/Daimas/android-pachi It's still in beta and may have some rough edges, I'm sure Emmanuel will be glad to hear any comments you may have. :-) Happy go-playing, Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Has Anyone Heard of Multi-Hashing?
Hi! On Wed, Jul 17, 2013 at 08:54:21AM -0700, Brandon Cieslak wrote: > We are using multiple hash tables to store win rates for large patterns. > Each table uses a different Zobrist hash function. The tables are “sloppy” > in that, when two patterns inevitably hash to the same location, we simply > combine the information. The idea seems interesting, but if you are really worried about collisions, I wonder if this approach really pays off compared to some more standard approach like linked lists in the buckets or using adjecent buckets. The issue is that each hash lookup results in pretty much guaranteed cache miss (and can easily trash your cache if you do too many of these) and serving a cache miss takes *long* time... Perhaps a good compromise would be to use one hash function to generate positions, then use another function (or multiple functions) to match the desired value locally. The bottom-line then really is just whether collisions are bad enough that handling this compensates for the (CPU time, cache space) overhead of calculating multiple zobrist hashes in parallel. I'd be very curious to hear about your findings. :-) Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Narrow wins
Hi! On Mon, Jun 10, 2013 at 11:48:01PM -0700, David Fotland wrote: > Sorry, secret. It took me quite a while to find something that worked well. > I think you are right that most of the benefit comes from keeping the win > rate close to 50%. I think Pachi found it was ideal to keep the win rate a > little below 50%. I try to keep it in the range of 45% to 55%. I think > Pachi's approach has been published. Mine is rather different. Note that you can read my findings in http://pasky.or.cz/go/dynkomi.pdf (I recommend e.g. Fig.2 to quickly grasp the picture). Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] KGS and GTS - disputing final status
Hi! On Tue, Jun 11, 2013 at 01:21:27PM -0400, Ed Poor wrote: > Specifically, is there any way to respond (in an unrated game) when > the opponent disagrees with the bot over which stones are alive? I think it's limited to rated games on KGS. > Is there a message that GTP will send to my bot, so the bot can > detect the disagreement over dead or alive stones? (Or is such a > message sent only in rated games?) Indeed. Please refer to the kgsGtp documentation which describes the exact KGS GTP extensions used in this case. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Question on 0.5-wins
Hi! On Fri, May 31, 2013 at 12:27:49PM +0200, "Ingo Althöfer" wrote: > For a long time it was my impression that this phenomenon > was typcial only for bots-vs-humans, but not for > MC-bots vs. MC-bots. But now experiments with other games > make me believe that wins by small margins happen often also > for MC-bots against each other. The MCTS in Go may win by an 0.5 margin because the human continues to play mostly calmly, catching up gradually. However, an MCTS opponent definitely does not like to *lose* by an 0.5 margin - it will force itself to resign and it's not a matter in which the winning program has any influence. It's probably a question of implementation and the character of the game. Perhaps in other games the playouts are short enough for resign not to make sense and/or score fluctuation within a branch isn't so big or is rather predictable. -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Go playing software accelerator development
Hi! On Thu, May 23, 2013 at 02:53:38PM +0400, Рождественский Дмитрий wrote: > Thanks, I have already started to do this as both are open source. But it is > not an easy nut too without a help from an author. I don't have the time to run a Pachi profile right now but if you'll send me one, I can help you identify which functions do what. Best, Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Go playing software accelerator development
Hi! On Tue, May 21, 2013 at 07:02:16PM +0400, Рождественский Дмитрий wrote: > I have got an idea to create a hardware accelerator for Go playing software. > It will probably be a USB (or maybe PCI-Express) device that will be able to > do some basic, but very time-consuming for general-purpose CPU calculations > very fast. For example load a goban layout, make a number of random moves (as > used in Monte-Carlo algorithm) and unload result back to a computer. There are two issues I would also like to mention: (i) The moves in current programs are not very random. They are chosen based on pattern matching and tactical evaluation by some fairly complex heuristics. Implementing just a random play would probably not be too difficult, but that also corresponds just to fairly small code; but to make a strong program, the additional heuristics are not an implementation detail but a crucial step forward, and there is a complexity jump both in the move generator _and_ the amount of goban data structures your goban library needs to keep around, in order to make these tactical checks effectively. (ii) If you use a device that's too far away from the CPU, you will have latency issues during communication; as Lars mentioned, pipelining will reduce importance of individual results. This reduces the viability of offloading only some very specific tasks to this accelerator, unfortunately. This is not meant to discourage, I just want to make you aware of the challenges ahead. If you have ideas on how to tackle them, that's great! -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] EXTENDED Full Paper Submission : TelSaTech 2013 - Advanced Science Letters Journal
On Fri, May 17, 2013 at 06:31:37PM -0400, Jeff Nowakowski wrote: > On 05/17/2013 03:22 PM, Mark Boon wrote: > >More plugs disguised as an apology. Very clever :) > > > >I vote in favor of kicking these guys off the list. > > The list isn't moderated, so it's a big deal to move to moderation > and figure out what that entails. We can either put up with it (and > put the guy in your kill file), or move to moderation. *Now* what do > you vote for? I don't see any requirement to move to moderation, mailman can unsubscribe and/or block individual sender addresses just fine. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] ladder
On Wed, May 15, 2013 at 12:37:26PM +0900, Hiroshi Yamashita wrote: > >Many Faces reads ladders in both the tree and the play outs. In play-outs > > Aya reads ladders only in tree. In play-outs Aya checks killing > two libs stones without search. So it can understand only easy > cases up to 3 plies, but it was effective. I tried ladder in > play-outs before, but I could not get good result. In Pachi it's similar to Aya. We special-case only "ladders near the edge of the board" which are trivial to read and are very helpful in the playouts: . O . O X O ? . x?. ? # # # In the tree, I tried to be very smart about analyzing ladders without playing moves on the board and with no backtracking etc., but too many bugs kept appearing and that caused a lot of embarassment in Pachi's KGS games. :) So I gave up and rewrote ladder check in a much more naive, but reliable way and now Pachi has pretty much no problems with ladders anymore. But yes, in order to have MCTS deal with ladders correctly, a specific heuristic is essential - correct ladder reading does not arise from anything magic in the algorithm, unfortunately. -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Can we kick out the conference spammers?
On Thu, May 09, 2013 at 07:47:12PM +0200, Rémi Coulom wrote: > I tried to send a polite request to Rudy Lolo but he did not answer. I agree, it's more and more noise and practically none of them seem even remotely relevant to us. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Computer Go at the European Go Congress
Hi! On Thu, May 02, 2013 at 11:53:57AM +0100, Nick Wedd wrote: > I would like to hear from the owners of strong programs > whether they are planning to enter. If no strong program > will be competing, I will not want to travel to Poland for > the event. If there will be at least two strong programs > competing, I will travel to Poland, and will offer to operate > competing programs for those who cannot be there themselves, > if this is to be permitted. I am considering to travel to Poland, but I am not decided yet whether I will go. I'm waiting for some sort of official announcement of the tournament with more detailed information; from http://egc2013.go.art.pl/page/go-tournaments I've understood that we could install Linux on the competition computer. -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Using RAVE statistics during playout
Hi! On Fri, Mar 29, 2013 at 09:40:49PM +0400, Alexander Kozlovsky wrote: > I know that RAVE data typically used during tree traversing. > But is it possible to use it during random playout, in order to > increase playout quality? ..snip.. > I think, this should add exploration element to next move > selection and prevent skewing of RAVE statistics. > I suspect using RAVE data can improve playout strength > significantly. > > Has anybody trying something like this, or it is just crazy idea? I think most Computer Go programmers devote part of their time to experiments with ideas similar to this. I have summed up some of the approaches (not all) recently in my presentation in Chofu: http://pasky.or.cz/go/infsharing.pdf Unfortunately, probably none of the ideas has been earth-shatteringly successful. Getting improvement from the first and maybe second method of information sharing you devise is easy, but to improve above certain bounds seems like a difficult problem. In case of your idea, I see a possible problem in that it will be difficult for playouts to discover "new" moves in case a move is not suggested by the playout heuristics, and that "followup bias" could make the playouts prefer moves that lead to favorable misevaluation of the situation rather than the "true" solution. But that's just my thoughts and I'd encourage you to try it out anyway. I think eventually, the next breakthrough in Computer Go will come up from one of us, in one of our many tries, succeeding in getting a variation of this to work, and it could be anybody. :) -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] CLOP: Confident Local Optimization for Noisy Black-Box Parameter Tuning
Hi! On Sat, Jul 07, 2012 at 11:52:21PM -0700, Michael Williams wrote: > Are the optimized values the "Mean" column on the "Max" tab? How does > one get them out? Copy to clipboard only works for a single cell at a > time. I'm on Windows. I'm wondering how to determine whether the parameters are already likely close to the optimal values. Can I use the winrate/Elo confidence bounds for that in some way? (Sorry if this has already been answered somewhere, I wasn't able to find it.) Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] *First* Densei-sen results
On Wed, Mar 20, 2013 at 10:56:07PM +0900, Hiroshi Yamashita wrote: > Some Japanese papers wrote up. > > "Looks like Amatuer 6dan, maybe genius" Pro Go player lost against Computer. > (with picture) > http://sankei.jp.msn.com/life/news/130320/igo1303202042-n1.htm > Densei-sen. one win, one loss in first match. > http://mainichi.jp/feature/news/20130321km040071000c.html Thank you for the links. I grinned at Google Translate's term "electric crusade". > And this is not Second, but First Densei-sen. I'm so sorry - I thought that the match with Takemiya Masaki was the first Densei-sen but it seems I have misunderstood the Densei-sen homepage. -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
[Computer-go] Second Densei-sen results
Hi! On Mon, Mar 18, 2013 at 11:30:05AM +0900, 村松正和 wrote: > The results of the second day of the 6th UEC Cup is now on the web at > http://www.jsb.cs.uec.ac.jp/~igo/result2.html Today, Zen and CrazyStone both played Ishida Yoshio 9p; there has been maybe about 80-140 spectators in the audience and a professional commentary. Both played with four stone handicap. Zen has lost after fighting hard and ending with a large white group in its moyo that had miai for life that Zen's simulations likely didn't understand; if they did, it seemed like black had some advantage and would have good chances. CrazyStone has played a steady game, resolving an early fight peacefully and entering the yose about 20 points ahead; there was a tricky endgame tesuji at one point that black mishandled, but it didn't matter after all and eventually CrazyStone cruised for a comfortable 3.5pt win. So today's result against Ishida Yoshio 9p on four stones is 1-1! It generally feeled to us that four stones is the correct handicap against professionals at this moment. I don't have CrazyStone's game but I'm attaching Zen's game SGF that I was given by David Fotland. It's a nice testcase. -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken ishida-zen.sgf Description: application/go-sgf ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] UEC Cup final result and MP-Fuego Nomitan game
On Sun, Mar 17, 2013 at 10:17:30PM +0100, Olivier Teytaud wrote: > I was surprised many MC programs are not UCT anymore. > > UCB = (wins / games) + C*sqrt( log(all_games) / games ) > > But in MFG, CS, Pachi and Fuego, C = 0. So they use something like this. > > UCB_RAVE = (1-beta)*(wins / games) + beta*(rave_wins / rave_games) + > > somebias. > > > > I think that in many UCTs, the C was so small that it was close to the case > C=0. > > In fact, wins/games is not asymptotically consistent (because a move with > 0/1 is discarded if another move has a score >0). > But "(wins+K)/(games+2K)" for any K>0 makes a MCTS consistent. We've worked > on this in http://hal.inria.fr/inria-00437146/ . Hi! I believe this is also equivalent with the "even game prior" described earlier (maybe even in your paper :)? I think many programs use something like that. -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Congratulations to CrazyStone!
Hi! On Sat, Mar 09, 2013 at 03:07:27AM +0900, Hideki Kato wrote: > Most important thing to reach high-dan level is to solve L&D correctly, > IMHO. For example, the bottom W at the position after 258 moves should > be recognized as dead on pachi vs. Zen19S in round 3 > (http://files.gokgs.com/games/2013/3/4/pachi-Zen19S.sgf). Indeed, that is a tricky one for pachi. Actually, this and the botched josekis against CrazyStone have been my main impulses to revisit the question of MC simulations strategy again, since I don't quite see a way to efficiently solve this in playouts in rule-based playouts. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Congratulations to CrazyStone!
Hi! On Fri, Mar 08, 2013 at 12:30:22AM +, Aja Huang wrote: > > Now it seems to me that this is related to the way playouts are done > > and it will be difficult to improve with Mogo style (rule-based) > > playouts above certain strength, without using larger patterns and next > > move choice based on probability distribution. Currently, playing out > > a simple joseki in a sensible way in simulations will just never happen. > > This is a bit frustrating since all my attempts at successfully > > implementing probdist-based playouts have failed so far, but I guess > > I will just have to try again... > > > To implement softmax, you can refer to my thesis where I have described the > framework of the move generator for the playout. Detecting forbidden moves > and replacing useless moves by better alternatives are very useful. There > you can gain a lot by applying much Go-knowledge. Two good candidate > algorithms for training the feature weights are MM and SB(Simulation > Balancing). I tried hard but failed to measure any improvement from SB > gammas (trained on 9x9) on 19x19. You can use CLOP to tune the MM gammas > which are far from optimal according to our experience. Thank you for the reference. It's true that in my experiments, I don't follow the "forbid - replace" logic but rather apply this logic when assigning the features; your idea is nice as it should be significantly more efficient, though I will have to rework my code quite a bit in order to accomodate it. A question that has always been important for me is how wide set of features to match and how often to recompute them. I assume that you are mainly matching local tactical features and 3x3 patterns. When there is no local move, do you choose a global move randomly or do you constuct a probability distribution for the whole board? Thanks, -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Congratulations to CrazyStone!
Hi! On Thu, Mar 07, 2013 at 12:26:50PM +, Nick Wedd wrote: > My report is at http://www.weddslist.com/kgs/past/S13.1/index.html > I expect it contains at least as many errors as usual, so I will be > pleased if you point these out to me. Pachi was not running with 12 threads, but as specified in its info on 2x Opteron 6134 (15 threads) with 64GiB RAM. On Thu, Mar 07, 2013 at 01:13:52PM +, Aja Huang wrote: > Thanks Nick for the report. Congratulations to CrazyStone! Congratulations from me too! There is a huge gap between CrazyStone and Pachi... In both of their matches, CrazyStone systematically wiped pachi out in the first joseki played on the board. :-) Now it seems to me that this is related to the way playouts are done and it will be difficult to improve with Mogo style (rule-based) playouts above certain strength, without using larger patterns and next move choice based on probability distribution. Currently, playing out a simple joseki in a sensible way in simulations will just never happen. This is a bit frustrating since all my attempts at successfully implementing probdist-based playouts have failed so far, but I guess I will just have to try again... > My observation is that Nomitan has improved a lot. Also welcome back, > pachi! Thank you. :-) I wish I was able to devote more time to Pachi, but I hope I will be able to persist with at least a daily 1-3 hours of Pachi care in the near future. -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
[Computer-go] Japanese rules in KGS tournaments
On Sat, Feb 23, 2013 at 07:37:35PM +0100, Erik van der Werf wrote: > On Fri, Feb 22, 2013 at 5:18 AM, Martin Mueller wrote: > ... > > Do people consider this a solved problem? > > I do. > > BTW I think it would be nice to have some kgs tournaments with > Japanese rules; good for testing, and it might even make 9x9 a bit > more interesting... I second that idea. Having tournaments with Chinese rules by default is friendly to Computer Go beginners, but having a Japanese rules tournament once in a while would be nice to help weed out any bugs (and assess how often some corner cases actually happen :-), especially considering that some important non-KGS tournaments have Japanese rules. -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] OT: monte-carlo in web sites
Hi! On Wed, Feb 06, 2013 at 08:59:30AM +0900, Darren Cook wrote: > I've been trying for years to find more real-world uses for UTC and what > we've learned from monte carlo go. Now O'Reilly have just released a > book entitled Bandit Algorithms for Website Optimization: > oreilly.com/shop/product/0636920027393.html That's nice to know! I know that some people use bandits for deciding which advertisments to run; I'm actually currently negotiating a contract to develop a system in a related area that would likely end up using UCB (either combined with simple Bayesian networks or actually UCT) for intelligently choosing which advertisment to show. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Recursive Neural Networks
On Wed, Jan 23, 2013 at 04:41:57PM -0500, George Dahl wrote: > This paper reports 36% move prediction accuracy: > http://www.cs.utoronto.ca/~ilya/pubs/2008/go_paper.pdf C.f. also http://research.microsoft.com/apps/pubs/default.aspx?id=67955 which reports 34% accuracy for top move, 66% accuracy for top five moves suggested. I'm not sure if anyone measured Remi Coulom's pattern model performance in move prediction. P.S.: As already mentioned, it should go without saying that there is very little correlation if any between move prediction rate and playing strength as a sole move generator or a feature provider. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Should playout patterns be gathered from high-dan games only?
Hi! On Wed, Jan 16, 2013 at 07:53:21PM +0400, Alexander Kozlovsky wrote: > Is it enough to use big number of hign-dan games > to build a strong pattern library for random playouts? > > I have suspiction the most useful patterns may be > gathered from low-dan games. ..snip.. I don't know if anyone did any rigorous study. I experimented with adding patterns from IIRC about a thousand games where (i) Pachi was black (ii) White was high dan (usually, this was a handi game) (iii) The move was white's to my pattern corpus, with the rationale that this way Pachi would learn to expect refutations to its common mistakes this way. The effect was negligible if any (I was not able to measure any statistically significnant improvement). Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] GPU Go engine (re-sent with fixed quotes!!!)
Hi! On Tue, Jan 08, 2013 at 04:34:15PM +0400, Alexander Kozlovsky wrote: > Is it possible to completely ignore superko during playouts > and detect it during UTC tree descent only, or maybe, > detect only relatively short superko cycles during playouts? > I think that probability of long superko cycle are very small > and statistically its effect during long series of random > playout will be insignificant. Short superko cycles might be enough, but this will need careful debugging. (Hidden) superkos may matter surprisingly often in endgame positions, at least on 9x9 in such a way that guarding against superko in some way is essential for good performance. > > > 2) What is a typical data size of structures used in modern > > > Monte-Carlo Go engines? > > > - size of UCT tree node; > > > > You will need at least UCT and RAVE values (#of playouts > > and value or #of wins), move coordinates and say another > > extra byte for some flags, per child, and pointer to its > > children list. > > I have a plan to completely avoid pointers to child nodes. > Maybe I don't fully understand something, but if each UCT > tree node have unique Zobrist hash and all nodes reside > in gigantic hash table, then address of hash table bucket > with specific child node can be calculated on the fly by > calculating Zobrist hash of child position from parent Zobrist > hash. So, it is enough for each node to keep relatively small > header of node-specific information and array of UTCValues > of chid positions, This is usually called transposition tables. It has its pros and cons; you will save on child pointers and allow merging transposed positions, but you will get all the hash table worries, mainly fixed capacity. There's no clear answer here which is better, I think. But you must have good entropy in your hashes as full collisions are catastrophic. > where index in the array corresponds to > coordinates on the board. This seems somewhat wasteful, though; by middlegame, you will have a significant overhead, and you will want to have a way to skip unused positions during iteration, which will mean some more overhead. > So, I think is is possible to keep size > of UTC node less then 1KB for 19x19 board assuming each > UTC value in array of child UTC values fit in 2 bytes > (I don't sure is 2 bytes is enough for UTC value, but why not). With longer thinking times, even single precision floats aren't enough. Careful here, typically many tree branches may have very similar values. > This assume some calculations during tree descent, but > I think it is not critical, because I think most processor time > will be spend not in tree descent, but in random playouts. I find that surprising amount of CPU time is spent in the tree descent (due to cache misses and mathematic operations) in Pachi, but with efficient representation and superscalar evaluation you should be able to push this down. > Also, I want to do not > not one, but several playouts after each tree descent > (I do not know whether this is a common practice), so > tree walking time seems even more minor compared to > playouts. This (or rather a variant of this) is sometimes called leaf parallelisation. It's not been found to work well so far, but I encourage you to do your own experiments. > I want to store Zobrist hash values not in 6 KB of shared memory > used for playout, but in 64 KB of GPU constant memory, > which have 8 KB cache per SM and to me looks very suitable > for Zobrist hash storage, because it seems optimized for both of Huh. Isn't the constant memory space shared with the shared memory? (Or worse, offloaded at will to main memory.) > By the way, I have read several time already about > keeping edges in array together with positions to avoid > analyze of position index to determine is it lie near board, > but I just don't understand this. Is it really so slow to check > if position lie near board? As it seems to me, many board > representation (such as bit masks) imply much more > performance hit comparing to edge check. At the least, > I can have a small shared lookup table, which will tell > for each index is it lie near the edge, and near which > edge exactly I'm not sure if anyone really uses bitmasks when there's no bad memory pressure. I don't. I just talk about bits of information, it's up to you if you round that up to nearest 2^n, n>2. :-) Having an edge frame allows us to avoid branching in many common for-each-neighbor loops, for example when decreasing/increasing liberty count, cached information like 3x3 pattern codes, and so on. Branching is expensive. But again, I encourage you to experiment. :) Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Hello Everybody!
Hi! On Tue, Jan 08, 2013 at 01:26:00AM +0400, Alexander Kozlovsky wrote: > 2) What is a typical data size of structures used in modern Monte-Carlo Go > engines? > - size of UCT tree node; You will need at least UCT and RAVE values (#of playouts and value or #of wins), move coordinates and say another extra byte for some flags, per child, and pointer to its children list. > - size of board representation; The bare minimum of course is two bits per point. Usually, an extra edge frame (or half-frame) is added so that you do not have to special-case border areas. Then again, for efficient implementation, you will also need at least some representation of stone chains and chain membership information for each point. For each chain, you will want to keep at least approximate number of liberties and fast way to get liberties of low-liberty chains (at least the last two libs). You will need to be able to quickly iterate over all points belonging to a chain (for captures), e.g. by having another "next-stone-in-chain" information per point. You may also want to maintain queue of free positions for random move selection, and some extra cached data (e.g. I cache number of neighbors of various colors). Then, you'll need to guard against superko by having a hash code per point+color and hash map of encountered positions. > - size of patterns library used for playout; A bare minimum for good computer player is 3x3 patterns around last move, two bits per point, i.e. 16 bits per pattern. (Of course, you can use more bits or slightly larger patterns, or use decision tree instead of pattern matching.) You can extend this to much larger patterns, more moves, more features and so on, but that's not so crucial. You'd have about 8-16 such patterns (up to isomorphism). > Below I describe the purpose of this second question. > > I have a strong suspicion it is possible to write strong GPU-based Go > engine. > Specifcally, I want to use GTX 580 graphics card, based on Nvidia Fermi > architecture. Great that someone else wants to try! I'm curious what comes out of it. I'm one of the two people who tried before and reported negative results here. I'm still sceptical, but I don't want to squash your enthusiasm. Quite possibly you will find a few ingenuities we missed, with sufficient effort. > Each of this playout will use single warp (32 GPU thread) and typically > will use > only first thread of warp, but for several task, such as Zobrist hash > calculation, pattern matching > and relatively good next random playout move selection, all warp threads > will be used. You should also be able to fully utilize all threads for tree node selection. On the other hand, I worry a little about memory latency when walking the tree. > To achieve the goal of fitting all necessary data inside GPU crystal, I > must suffice > the next restrictions: > > - Sinle playout must use no more then 6 kilobyte of memory (technically > speaking, > it will be shared memory of SM (streaming multiprocessor), 8 simultaneous > independed > playouts executed on single SM may use up to 48 kilobyte of shared memory > in total) A lot of this memory will be overhead for local variables of the threads; you also need to store the tree descent stack etc. Even if all 6kb data of memory was for board structure, that's 15 bytes per intersection on 19x19 (or rather 20x20). The trouble here is the superko detection I think, you would need some clever ways to cheat here. If you don't care about 9x9 strength but just about large boards, perhaps some clever bandaid trick would suffice instead of real superko detection... but you would still be cutting it very thin. > I suspect light playout for 13x13 can fit in 1 kilobyte of memory, Zobrist hashes alone would occupy 2352 bytes: (14*14)*3*4. Maybe 2028 if you forego the edge frame (but you'll have to do expensive index recomputation). You may want to think about reducing the 32-bit entropy, but it's dangerous balancing of collisions vs. memory. And this is 13x13. I think engines that can't work on 19x19 aren't really very exciting nowadays, maybe that's just me. The situation really seems very dire here. The tiny shared memory is the main reason I gave up on GPU Go. It will require some original thinking to get over these limitations. > so 6 kilobytes give > place for ladder evaluation. You don't need much memory for ladder evaluation, I think; you need to store move stack only in case of branches, which are rare when checking ladders. > - Hash table with pattern library must fit in 512 kilobyte of GPU L2 cache > (with total > L2 cache size 768 kilobyte) You will also want the cache to hold some popular parts of the tree, a "base" board with the current position, etc. Patterns are optional. Maybe it's good idea to design your program around patterns from day zero, but you should be able to attain at least KGS 1d strength even with just the 3x3 patterns if you forego this.
Re: [Computer-go] Practical significance?
Hi! On Wed, Nov 28, 2012 at 12:03:36PM -0800, Leandro Marcolino wrote: > > When you said a "23% difference" did you mean the win-ratio is 61.5:38.5? > > Well, basically I mean that in 1000 games, system A1 can win about 300 > games (30%) against B, while A2 can win about 530 games (53%) against B. So > I calculate a difference of 23% between A1 and A2. As Ingo noted, this > assumes transitivity, that may not always happen in real life, but as Don > said, it can be a "good" approximation In a more strict interpretation, > A2 would be 23% better "when playing against B"... But, say, 5% difference between 48% and 53% is surely different kind of improvement than 5% difference between 94% and 99% winrate, isn't it? It's a seductive thing to use directly the values your testing tool prints out and I've been also long measuring performance difference in percentages. But converting to Elo points has a distinct advantage here, since they unfold the percentage space to a linear scale. Percentages are misleading to people. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] TAAI details?
Hi! On Thu, Nov 22, 2012 at 11:32:24AM +0900, Hideki Kato wrote: > BTW, the official announce of "Denseisen" has been released. > http://entcog.c.ooco.jp/entcog/densei/ (in J) and > a pdf file for press. > http://entcog.c.ooco.jp/entcog/densei/Release20121120.pdf (in J) > > Denseisen is the name of a serie of (handicap) games between > professional players and computer players under the contract between > Nihon Ki-in (Ichigaya, Tokyo) and UEC (The University of > Electro-Communications, Chofu, Tokyo). The contract is valid for five > years. Note that Denseisen is an "offical" serie. > > #For Denseisen. The "den", "sei" and "sen" mean electric or electronic, > saint and match, respectively. Similar to well-known "Kiseisen", in > which "Kisei" means a saint of Go (or Shogi) where "saint" suggests > almost the God level. Historically, there is a word "Kensei" where > "ken" and "sei" mean sword and saint. The title "Kensei" is used > for the very excellent swordmen for long years in Japan and is still > well known. Hence, "Densei" is created as the title for very excellent > computer Go players. > > The first match will be held on March 20th, 2013 (a Spring holiday) at > UEC. Two games are planned. The professional player for both is Shuho > Ishida 24th Hon'inbo (Yoshio Ishida 9p). The computer players are > the 1st and 2nd places of the Sixth UEC Cup, which will be held on > March 16th and 17th, 2013. Handicaps will be studied after the UEC > Cup. > > Nihon Ki-in: http://www.nihonkiin.or.jp/index-e.htm > UEC: http://www.uec.ac.jp/eng/ That is mighty awesome, thank you so much for sharing this news! Participation in UEC Cup seems suddenly to be something to consider much more seriously! If I read Google Translate output right, there is also prize 100,000 and 200,000 yen for the matches; is this something the winner of the Densei match receives, or is placement in the UEC Cup enough (i.e. just qualifying for the Densei match)? This could at least cover any travel expenses, and seems to be after long time first open computer Go match with significant financial reward. P.S.: In UEC cup, do you bring the whole cluster in the playing room, or does Zen run only on a single computer? :-) Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] TAAI details?
Hi! On Wed, Nov 21, 2012 at 08:03:38PM +0900, Hiroshi Yamashita wrote: > Aya was running on 10 machines, each has 12 cores @3.3GHz(10x12 =120 cores). > I borrowed it from The University of Electro-Communications. > Cluster is Root Parallelization with summing up root results each 0.5 sec. > Aya uses GTP(Go Text Protocol) to communicate another machines. > I tested this cluster as AyaMC6 on KGS. But it got only 1d or 2d. > AyaMC5 (4 cores) has 2d. I think my method may be something wrong. Have you looked at Pachi's usage of virtual wins and virtual losses? Does using that make a difference for you? Best, Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Parallela and Computer Go
Hi! On Wed, Oct 24, 2012 at 02:00:52PM +0200, ds wrote: > I saw this too, but the cores are ARM A9. With oakfoam one such core > does 150 playouts / second on 19x19 (iPad1 with NiceGo, the free version > of oakfoam for iPad), one i7-2600 core is more than 8 times faster. > > Even with good scaling a 64 core machine is only twice as fast as a > i7-2600 I would think. Of course, the performance is not stellar per se. However, Parallela based solution would be much cheaper both to buy and to run; low power consumption also means that there's no big deal in stacking many of them together, though I'm not sure what memory sharing options there will be in that case. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
[Computer-go] Parallela and Computer Go
Hi! There is a new fairly exciting parallelization platform in the works, currently as a kickstarter project (that will unfortunately likely not make it since while it's technically awesome, its marketing/PR campaign was far from stellar, but if you like it, don't hesitate to pledge in the next three days yet :) : http://www.kickstarter.com/projects/adapteva/parallella-a-supercomputer-for-everyone/ It consists of a control processor (in fact an FPGA) and a grid of 16 parallel processors in slightly Cell-like arrangement, with a promise to dramatically grow the number of processors in future. Single board costs $99. Something worth knowing about, I think - while the processors currently have fairly small amount of local memory, unfortunately, they still seem to me as much more suitable for Computer Go than GPUs as the thread on each parallel processor can be completely independent from others. Perhaps if the project makes it (on kickstarter or in another way), this is the hardware side of the next Computer Go strength boost to come. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Social web was: JSON game format
On Sat, Aug 18, 2012 at 02:12:13AM +0100, Jonathan Chetwynd wrote: > afaict PC[] BL[], OB[] are not defined by a well used standard, > and hence extremely little used in my experience > whereas javascript date, and GPS are well defined and well used They are defined by the SGF standard itself and they are used quite commonly, at least in the SGF collections I can see (KGS files, GoGoD, ...). They are of freeform format, so you can of course just stick javascript date or GPS coordinates in there if you want too. Either establish a convention that says this is always preceded e.g. by "GPS", but you should be able to easily construe a regex that matches the given format with essentially 100% accuracy. But *requiring* something like that is dangerous since it forces to use certain precision even if the original information is much less precise. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] JSON game format
Hi! On Sat, Aug 18, 2012 at 03:18:36PM +0200, Jonas Jermann wrote: > I don't know if this is the right time/place. But I wanted to > mention that I developed my own gaming format to store store > time-accurate recordings of go lectures/games together with optional > media. > > In that area SGF is certainly lacking. What I did was: I tried to > keep as much of the SGF syntax as possible (i.e. "tried" to keep it > backwards compatible) and break as few things/assumptions as > possible. > > For more details please check it out here: > > https://github.com/jjermann/rgf > > resp. > > https://github.com/jjermann/rgf/blob/master/DOCS/RGF.txt > > I really tried to think it through and also made a complete > prototype that already works quite nicely (at least with firefox). > > My decision to use an extension of SGF is: > - SGF is already very nice to store tree data, compared to e.g. xml/XGF > or some other binary formats: > o It can be edited by hand > o It is small > o Everyone/most (non-asian) softwares already use it, so > import/export is easier and writing/adjusting a parser is easier > - SGF actually already has _almost_ everything I needed > - It is easy/easier to "enrich" an SGF with time sensitive data > - RGF is actually like a wrapper/container around SGF, so all old SGF > editors canstill be used and can easily be extended for > recording... I did not understand your example in RGF.txt well. I'm confused by several points: (i) Is there any advantage in having RGF files a tree of nodes instead of just a timestamped sequence of actions given that the latter is exactly what a RGF player will convert it to and it can refer to the SGF file for the actual variation? If so, why not just keep all the information in the SGF tree? To have e.g. stones appear gradually, you can just split AB[]s etc. to multiple nodes, which SGF readers should handle fine too? (ii) In each GS/GD node of the SGF file, you repeat full game information. Why all this duplication? What semantics should SGF editors adopt regarding changing game information and how should SGF viewers handle changes in game information? (iii) Zip container is usually preferred for such bundles since you can easily access random files without loading and scanning the whole bundle file. Is there a reason why you picked tar instead? Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] JSON game format
Hi! On Fri, Aug 17, 2012 at 09:07:19PM +0100, Jonathan Chetwynd wrote: > SGF has rather limited metadata, JGF could standardise at least part > of this... > examples might include: > Location: ie GPS or similar PC[] > Timing of moves see javascript date object BL[], OB[] etc. I think the most obvious representation as JSON is a straightforward syntactic translation from SGF, and a common chunk of javascript code can serve as that... The next step can be to have an option to generate SGF.json directly but I don't see a great case for that except for optimization of particular webapp setups. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Kas Cup - results and prizes
On Sat, Aug 11, 2012 at 12:52:12AM -0700, David Fotland wrote: > Yes, root parallelization with some sharing. > http://www.personeel.unimaas.nl/G-Chaslot/papers/parallelMCTS.pdf said it > was good and I tried it and it works well. The paper is not so relevant now, since the standard method of most programs is lockless tree parallelization, which is not covered. The locking overhead is quite significant, I'd expect, as locking instructions can AFAIK take hundreds of cycles. That said, root parallelization overperforming sequential simulations is something I never managed to reproduce and that seems rather surprising to me. It might have something to do with the way priors are done in the tree or some other engine-specific factors. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Kas Cup - results and prizes
On Sat, Aug 11, 2012 at 12:46:19AM -0700, David Fotland wrote: > I'm happy with MFGO's scaling. I'm running a scaling test now, 4 threads vs > 8 threads, fixed 32K total playouts per move, 19x19, no pondering. Ideally > the win rate should be 50%, since the total playouts are the same. Has > anyone tried this kind of scaling experiment, and is willing to share > results? With Pachi, the winrate in this scenario would be 50%; our thread scaling incurs basically no strength loss compared to sequential playouts. This is visible in the Lousy Graph http://pachi.or.cz/root-vs-shared.png as second triplet of bars (labelled Sequential) vs. the last one, and in Fig. 9 of http://pasky.or.cz/go/pachi-tr.pdf (see text for detailed description of the graph). Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Kas Cup - results and prizes
On Fri, Aug 10, 2012 at 09:26:31AM -0700, David Fotland wrote: > Because my current approach seems to work just as well (or maybe better), > and I haven't had time to code up a shared try and tune it up to validate > that assumption. Chaslot's paper indicates perhaps that not having a shared > tree is stronger. My guess is that they are about the same, so it's not > worth the effort to change. In Pachi, having a shared tree makes all the difference when scaling up to more threads. See the graph (really awful one, sorry, it's old!) at http://pachi.or.cz/root-vs-shared.png If you have some information sharing near the root, I imagine it might be similar to Pachi's distributed engine performance (or just slightly better). But that is still far behind in scaling compared to the shared tree in our experience. P.S.: There are two important things, virtual loss (not necessarily 1 simulation but possibly more) and mainly lockless updates. The latter also means that sane code should be really easy to modify to use single shared tree instead of multiple trees. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] 50k-100k patterns
On Thu, Aug 09, 2012 at 03:38:45PM -1000, Mark Boon wrote: > Occasionally the Nihon Ki-in or the Kansai Ki-in take in someone over > 30 to become professional. These are people who already spent > something like 10-20 years full time on Go. Yet I can't think of a > single one that made it through the competition to become > professional. At the very best they get a diploma as 'teaching > professional'. But they're not allowed to enter the professional > competitions. Of the people that enter the professional schools at age > 20 or later, I believe Catalin Taranu got the furthest to 5-dan pro. > And these are people who started playing Go in their early teens. Well, Catalin Taranu started learning Go when he was 16. But while I got it stuck in my head that there were some other exceptional professionals who started playing Go very late or became pro at 29 or 30, I couldn't find any right now... Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Kas Cup - results and prizes
On Thu, Aug 09, 2012 at 08:09:55PM +0900, Hideki Kato wrote: > Erik van der Werf: > : > >10-15%, really, that low? For my program (on an i7-3930K, going from 6 to > >12 threads) it is more in the order of 40% extra simulations per second. > > In general that number highly depends on the code, architecture of the > processor (Intel's are usually better than AMD's), memory speed, cache > size, use of ALUs, etc. For Zen, the number is also about 40% on both > an i7 3930K (6 to 12 threads) and an i7 920 (4 to 8 threads). For Zen, I'm not surprised, since I assume that in simulations, you are matching some larger patterns which involves a lot of time-consuming hash table lookups which is ideal for hyperthreading. Not sure about stv. I think it matters a lot on whether you are matching patterns by explicit test code snippets or by a hash table. I measured the hyperthreading effect about 2 years ago with a lot older Pachi version. I think today, the hyperthreading effect would also be higher, but I cannot test it right now. > Pasky, modern processors are much more complicated :). There are more > than two sets of general registers, which are used not only for > hyperthreading but also register renaming, for example. Sure, I just tried to sketch a rough explanation. I did not know that hyperthreading could reduce opportunity for register renaming, though. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Kaś Cup - results and prizes
On Wed, Aug 08, 2012 at 09:08:47PM +0200, ds wrote: > Hyperthreading does the trick, I have the experience it increases the > performance by about 10%. I think this is due to waiting for RAM I/O or > things like that Yes. With hyperthreading, performance per thread goes down significantly, but total performance goes up by about 15%. In the Pentium 4 era, hyperthreading did not usually pay off, but with i7, its performance is much better. The basic idea is that there are two instruction pipelines that share the same ALU and other processor units; if one of the pipelines stalls (usually due to memory fetch), the other can use the ALU in the meantime, or the two threads may use different parts of the CPU altogether based on what the instructions do. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Seki in playouts
On Wed, Aug 08, 2012 at 12:07:43AM +0200, Erik van der Werf wrote: > On Tue, Aug 7, 2012 at 10:34 PM, Michael Williams < > michaelwilliam...@gmail.com> wrote: > > > Could anyone describe the basic implementation for detecting some seki > > in a fast enough way to be used in playouts? I understand that it's > > not practical to detect them all. > > > > Just prevent self-atari unless it makes a basic nakade shape and the > surrounding group doesn't have eye potential elsewhere. That sounds simple, but "just" testing if a move is self-atari is not so straightforward, with possible connections to neighboring groups etc. Also, you must allow throw-ins. But yes, proper selfatari testing is the way to prevent breaking seki. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Kaś Cup - results and prizes
On Tue, Aug 07, 2012 at 12:35:29PM +0200, Petr Baudis wrote: > In my testing, this version of Pachi is about 60 Elo weaker than normal > Pachi against Fuego 1.1 with 500s/game (PachIV's rating drop against > humans on KGS is about 40 Elo). I just realized that PachIV used i7 920 instead of i7-2600 beforehand, so the rating drop is probably roughly consistent with testing against Fuego. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Kaś Cup - results and prizes
On Tue, Aug 07, 2012 at 02:08:49AM +0200, Łukasz Lew wrote: > Notably at least one game (Round 2 Aya : Pachi) ended with premature > resignation at final position. Yes. This was a bug in Pachi - its dynamic komi state got reset when the opponent played an unexpected move (that could therefore not be promoted to the MCTS tree root); the move was unexpected because Pachi played very fast at the game end, since its time controls are optimized for shorter games (or won games with Pachi playing quickly at the end due to very high winrate). I have fixed the bug shortly after the game, alas the third place has already escaped between Pachi's fingers. :-) > Program authors / operators, please state in this thread the hardware used. Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz. It seems it is auto-overlocked to 3.7GHz. Four cores, eight threads. > If you wish, tell us whether and how you modified your programs. Couple of things (summarized in new 'maximize_score' parameter in Pachi's git): * Pachi passes when status of all intersections is settled, not when it wins subsequent counting. * Dynamic komi - adaptive strategy as described in my paper, with the exceptions that the komi ratchet is used even for losing extra komi and dynamic komi is used to the very end of the game (normally its use is discontinued near the end of the game to make sure it is wrapped up properly). * Value scaling - Pachi used to incorporate win margin in values stored in the tree ([0,0.04],[0.96,1] instead of 0,1). We turned that off recently since it started having a tiny negative Elo contribution to Pachi's strength. For this tournament, I have turned it on and added two enhancements; the win margin is measured against average outcome of the game in this search episode, not against jigo; and the margin contribution diminishes for balanced tree branches (a=0.01 for values near 0.5, a=0.05 for values near 0 or 1). However, this has a fairly complex interaction with dynamic komi which tries to keep the value around 0.5. In my testing, this version of Pachi is about 60 Elo weaker than normal Pachi against Fuego 1.1 with 500s/game (PachIV's rating drop against humans on KGS is about 40 Elo). I did some rudimentary tuning but not too much; perhaps I should have eventually gone with Pachi w/o dynamic komi for the tournament like others... :) However, it seems to me that even though it is weaker, playing Pachi with maximize_score settings is more pleasurable for humans, so I also added a suggestion about this to Pachi's README. Congratulations to the winners as well! This was a fun exercise; it's a pity that in the end, most programs competed unmodified. If there will be a second installment, it would be great if it would be announced more in advance (this was a very short call for any modifications requiring serious testing and tuning) and perhaps figure out a way to increase people's motivation not to use stock versions of their programs. (One random idea - discourage going for *too* big win margins, e.g. reward starts decreasing with win margin 20 or more. This is sort of Hikaru handicap game style challenge, going for close games.) Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
[Computer-go] Human-computer Rengo at EGC2012 Bonn
Hi! We organized a human-computer rengo with Ingo tonight. Black was Jonas Welticke 4d and Pachi operated by me (on i3 notebook, 4000 playouts/s, ~25 seconds per move, our experimental maximize_score mode). White was Fabien Bambusch 1d and CrazyStone operated by Ingo (on I think T6510 processor, similar time settings as Pachi used). I'm attaching the SGF if anyone wants to take a look. Black managed to take an early lead and hold to it throughout the game, though there were few dangerous moments. Petr "Pasky" Baudis rengo-bonn.sgf Description: application/go-sgf ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] EGC2012 13x13 and Pachi
On Tue, Jul 31, 2012 at 01:17:38AM +0200, Petr Baudis wrote: > Pachi has advanced to playoff, to be played out today. The first round > turns out to be against Robert Jasiek, the tournament organizer who > kindly allowed Pachi to participate. :-) (After I implemented support > for EGF simplified ING rules and pass stones.) Wish Pachi luck! Pachi has won the game, but so did Robert - I was the one who lost. The game was 2 handicap stones and 4.5 komi for white, and it turns out one must be extremely careful when using gogui in that scenario, since when handicap is set, komi is _zeroed_, even when set explicitly before. So, Pachi was playing as if the komi was zero all the time. Normally, I would notice during the game based on Pachi's output, but Robert requested the screen to be visible to him so I turned off the GTP shell... On board, we counted 1.5 win for white. I have verified that with 4.5 komi, Pachi would play F3 instead of D13 and win. Tough luck. :) Petr "Pasky" Baudis pachi-13-robert-jasiek.sgf Description: application/go-sgf ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
[Computer-go] EGC2012 13x13 and Pachi
Hi! Pachi participated yesterday in EGC2012 13x13 tournament. Thinking time was 20 minutes + 3x10 byoyomi, Pachi was set to use just 1000s to allow for delay coming from copying moves to real board. It took handicap as if it was EGF 3k and even though it ran just on an i3 notebook (~9000 playouts/s) (and with experimental maximize_score setting), this turned out to be likely an underestimated rank! It has won four out of five games. Four game records are attached if anyone is interested, one win (against Lukas Podpera 5d) is unfortunately missing as I forgot to save the game but that game was not as exciting actually, I think (white played very fast). Pachi has advanced to playoff, to be played out today. The first round turns out to be against Robert Jasiek, the tournament organizer who kindly allowed Pachi to participate. :-) (After I implemented support for EGF simplified ING rules and pass stones.) Wish Pachi luck! Petr "Pasky" Baudis pachi-13-1-soren-ohlenbusch.sgf Description: application/go-sgf pachi-13-3-alex-ketelaars.sgf Description: application/go-sgf pachi-13-4-wang-25k.sgf Description: application/go-sgf pachi-13-5-thomas-racz.sgf Description: application/go-sgf ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Dynamic Komi Question
Hi! On Fri, Jun 29, 2012 at 05:00:19PM -0700, Nick Sylvester wrote: > Hi, I am a student working with Peter Drake on the Orego project this > summer. We have recently been trying to implement dynamic komi into > our program. We have been trying to follow the paper by Petr Baudis > (sorry if this is misspelled) located here > http://pasky.or.cz/go/dynkomi.pdf. In the paper he says "We have found > that 30 is the top useful value for favorable komi; moreover, we stop > allowing negative komi altogether when we reach 95% of the game in > order to resign in cases when we cannot catch up anymore" (page 6). > The footnote says "Estimation based on board fill ratio". Does this > mean that they stop allowing negative komi once 95% of the board is > filled up? It seems like this is very unlikely to happen, and even if > it did you are not saving much time resigning at this point in the > game. Can anyone give some insight as to what this "95%" means/refers > to. I hope this has not been posted already! We use a heuristic that usually, about 20% of intersections are empty at the end of the game, and estimate the length of the game we are in based on that. When we reach 95% of this estimated length, we stop using negative komi. Obviously, this is very far from perfect. Overally, I think this is a fairly fine point and any similar feature will work. This is also just to be human friendly, in automated matches it probably doesn't matter at all. -- Petr "Pasky" Baudis Smart data structures and dumb code works a lot better than the other way around. -- Eric S. Raymond ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Patterns in playouts
On Wed, Jun 27, 2012 at 08:28:43PM -0700, Michael Williams wrote: > Is anyone succesfully using patterns larger than 3x3 in the playouts > (past the leafs of the tree)? I believe that at least Erica, CrazyStone and Zen are using such patterns, at least around the last playout move. I have spent many sleepless nights trying to get them work in Pachi, without success yet, though I plan to revisit the subject again. :-) Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Effect of lgrf on the playing strength agains gnugo
Hi! On Thu, Jun 14, 2012 at 07:47:41AM +0200, ds wrote: > as answers here are always very helpful, my problem: > > We (oakfoam) have a small number of playout rules: last atari, last 2 > liberty atari, patterns, fill board (mogo like I think) and a capture > heuristic (more or less in this order). > > Playing (1000 playouts/move) against gnugo (3.8l10) we play around even > but I can not measure any (positive) effect of last good reply rules > (which I checked a number of times and which do have positive effect on > special board situations like seki). Similar problems I have trying pool > rave rules. > > Does anybody have similar problems? In Pachi, we couldn't make it to work either. I think that as always, it's a heuristic whose effect highly matters on your current mix and might be made redundant by something else you do. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] [SPAM] Re: super ko
On Wed, Jun 06, 2012 at 10:35:08AM -0400, Don Dailey wrote: > Is the issue simply the CGOS behavior, the wrong bot losing on forfeit or > something like that?If so it does need to be fixed. I think Folkert simply asked a honest question whether his program is required to implement superko to play on CGOS, and did not mean to ask for any changes in CGOS itself, just check the current situation. To reiterate, the answer to Folkert's question is: yes, you need to support superko; make sure to educate yourself about positional vs. situational superko. Detection of superko using a hash table and Zobrist hashing (which is simple and useful to implement for other purposes too) is fairly straightforward. In case of MCTS, a simple and cheap way is to detect superko as "output filter" and use next best move in the tree if superko violation is detected; however, some situations may be significantly misread because of that. The other extreme is detecting and avoiding superko even in simulations; that is fairly expensive (due to a guaranteed cache miss during hash table lookup, at the very least) and usually *not* done. The most common compromise is to detect and prune superko moves only in the game tree and check only the simple ko rule in simulations. Another point is to follow the usual maxim "be conservative in what you send and liberal in what you receive". It is good idea to accept even opponent moves which you believe violate superko and leave the rule enforcement on the server, since different environments might mandate different superko rules. Kind regards, -- Petr "Pasky" Baudis Smart data structures and dumb code works a lot better than the other way around. -- Eric S. Raymond ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Congratulations to Zen!
Hi! On Wed, Jun 06, 2012 at 11:00:02AM +0100, Nick Wedd wrote: > I reported the problem to wms, and have received a reply: > > "It is possible that the bug is still there. I can't recall exactly > what I fixed in kgsGtp and when. Please let me know if the problem > recurs wher both players are using the latest kgsGtp." > > This is less than I was hoping for, but seems reasonable. He does > not want to spend his time looking for a bug in an obsolete version > of kgsGtp. It should be fairly straightforward even for a single individual to test this with two kgsGtp instances that e.g. read GTP replies from standard input (the programmer); you do not even need to play a full game, just few moves should be enough. I would test this; unfortunately, I most likely won't find time for that soon... Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Nice and Hyperthreading
Hi! On Tue, May 29, 2012 at 09:39:11AM +0200, ds wrote: > Now with Hyperthreading even niced processes harm the performance a lot. > I understand, that this is a conceptional problem, as the operating > system does not know that using virtual core 0 harms virtual core 4, but > this knowledge does not help me:( On Linux, you should be able to use the numactl tool to execute a given command while binding it to given CPUs. E.g. numactl --physcpubind 0,4,1,5,2,6 -- java -jar kgsGtp.jar should start a KGS interface bound to three of four cores; for CLOP, use --physcpubind 3,7 and CLOP should not interfere with KGS then. To find out whether two "physical CPUs" (in NUMA parlance) are of the same core, you can use the 'core id' field of /proc/cpuinfo or use http://mj.ucw.cz/vyuka/1112/aim/machinfo.tar.gz to get a nicely formatted listing. Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Great Triumph for Zen !
On Tue, Mar 20, 2012 at 04:40:14PM +0100, "Ingo Althöfer" wrote: > "less variance" - I have to think about that. > > Is there some thumb measure describing how much randomness/variance > the simulations of a bot contain? > > Did someone run experiments (with his bot) to see if there is some > optimal medium level of variance/randomness in the sims? "Variance" in itself is not what matters per se, but it implies that the program will not get strayed off too much by bias of its simulation heuristics when the bias is wrong. High variance allows for the program to at least still resolve the simulation ambiguously (wrt. e.g. status of some group) instead of unconditionally declaring the wrong result. On the other hand, "strength" of simulation means that if the heuristics do give the _correct_ result, you want them to declare it with as much strength and unconditionality as possible. Unfortunately, these two goals are often in opposition and finding the correct equilibrium is, after all, what most of "tuning" is all about. I believe this is one of the most annoying open problems in MCTS and also the reason why tuning simulations is considered "black magic". Wouldn't it be so much easier to improve the simulations if we could precisely measure how much it effects these two aspects? Alas... -- Petr "Pasky" Baudis Smart data structures and dumb code works a lot better than the other way around. -- Eric S. Raymond ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
[Computer-go] KGS Rating Drift
Hi! Just a word of warning - in the last two or three weeks, all ranks on KGS (at least ranks of all programs) started experiencing a strong upwards rating drift (by up to half a rank so far), so be careful about misinterpreting impact of any recent changes if you use KGS rating for evaluation. P.S.: I have warned the admins about this but got no reply so far. Perhaps to limit abuse, it would be wise to rate-limit impact of games against programs on rating to two games per week for each user (in some smart stochastic way). Happy coding, -- Petr "Pasky" Baudis Smart data structures and dumb code works a lot better than the other way around. -- Eric S. Raymond ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] About Minirock
Hi! On Tue, Feb 14, 2012 at 04:11:01PM +, Xaryl C wrote: > I am the one responsible for the bot. I started coding a go bot when school > was boring, that was when classical bots prevailed. > Then life got busy, I tried MC, made some nice progress in terms of strength, > but never even got the chance to properly debug the multi threading codes. > > Then sometime ago, Minirock (the player) wanted to have a bot, so I hackishly > glued (with macros and mass code replacing with scripts) and replaced the > playout codes and search distribution along with tactical reading codes and > pattern matchers onto Pachi's codes. Great, I'm happy Pachi is useful like this too! If I understand it right, you use Pachi as foundation with custom playout and tactics code? Or is it vice versa? If you have any patches / changes in mind for Pachi (not necessarily with any of your reading code, but even just whatever is needed for better integration of foreign code in Pachi), I will be glad to merge it. Or just if you have any feedback. :-) Best, -- Petr "Pasky" Baudis Smart data structures and dumb code works a lot better than the other way around. -- Eric S. Raymond ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Beating old ManyFaces at 29 handicap stones
On Sun, Jan 29, 2012 at 08:59:56AM -0800, David Fotland wrote: > please do not set handicaps just by passing, start with at least 6 handicap, > then pass. But how to do that with kgsGtp? It seems to me that the only way is to set up the game as human, then rejoin as a program, like we did it in Tilburg, which is a bit tedious for many-games testing. P.S.: I hope that mfgo1998 will be available on KGS for a longer time period; I will start having some time on my hands again only from the second half of February. Thanks for running it! -- Petr "Pasky" Baudis The goal of Computer Science is to build something that will last at least until we've finished building it. ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Pachi on cygwin
Hi! On Sun, Jan 29, 2012 at 08:07:13AM -0500, Michael Williams wrote: > I just grabbed the latest release again and the result is the same. Ah. This is just in Git for now. The latest release is usually not so exciting. ;-) I plan to tag new release sometime in the second half of February. > The most troubling warnings are: > > > > cc: unrecognized option '-pthread' > cc: unrecognized option '-rdynamic' Do not worry about -rdynamic. I don't understand how did it compile at all if cc complained about -pthread not recognized, though. You may try to replace that with -lpthread. That could fix things. > I also just noticed the Windows mingw Makefile on your web site, so I will > try that. It will probably work only on the current Git version. Also take a look at the recent Windows porting threads on the pachi@ mailinglist; the build system is not yet adapted for mingw compilation, however it should work with Cygwin I think. -- Petr "Pasky" Baudis The goal of Computer Science is to build something that will last at least until we've finished building it. ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Pachi on cygwin
Hi! On Sun, Jan 29, 2012 at 12:11:13AM -0500, Michael Williams wrote: > I just build the latest Pachi on the patest Cygwin. I got some warnings > but no errors. It does not crash when I run it. It does show it's > thinking process when I give it a genmove command. But when it is done > thinking, it does not print the result and prompt for the next command as > expected. Instead it just hangs. Any ideas? That seems curious. The only problematic thing that happens at this point I can think of is joining the thinking thread. Try with -d 4, it should report thread management information. I'm afraid you'd have to use a debugger to make further progress, though. Even more curious is the fact that people building Pachi using mingw report no such troubles, there is even a binary available for download that works fine even when using multiple search threads. > $ ./pachi.exe > Random seed: 1327809195 > play b e5 > IN: play b e5 > got move 1,5,5 > Fresh board with random seed 1327809195 > Warning: Cannot promote move node! Several play commands in row? > Move: 1 Komi: 0.0 Handicap: 0 Captures B: 0 W: 0 ... Are you sure this is latest Pachi? It does not print messages like this anymore with default debug level. -- Petr "Pasky" Baudis The goal of Computer Science is to build something that will last at least until we've finished building it. ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] Beating old ManyFaces at 29 handicap stones
Hi! On Thu, Jan 26, 2012 at 10:04:52PM +0100, "Ingo Althöfer" wrote: > Recently, dynamic komi helped Monte Carlo bots to play better > in handicap situations. Now I set up a prize for the programmer > of a bot that beats the old ManyFaces at 29 handicap stones: > 1,000 Euro for the first bot that achieves this at least three > times in a five games match. The offer ends on December 31, 2020. > Details will be clarified in a forthcoming website. > > David Fotland is willing to provide the old bot - also for sparring > sessions on KGS. Will David also try to compete? :-) Of course, for experiments it would be neat to have a binary of this version, but maybe that would make the challenge too easy (or prone to overtuning). Anyway, sounds wonderful, and Martin Mueller's play in that game is quite something. I'm looking forward to giving this challenge to Pachi. -- Petr "Pasky" Baudis The goal of Computer Science is to build something that will last at least until we've finished building it. ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] How well does pure monte carlo play?
On Sat, Jan 21, 2012 at 03:11:30PM -0800, Christoph Birk wrote: > > On Jan 21, 2012, at 2:16 PM, Petr Baudis wrote: > > > On Sat, Jan 21, 2012 at 03:42:57PM -0500, Don Dailey wrote: > >> On Sat, Jan 21, 2012 at 2:31 PM, Eric Baum wrote: > >> > >>> If you don't do rave, or use patterns to predict likely moves, or any of > >>> that, but just do pure monte carlo, > >>> parallelized on a cluster,how well would that play Go? Anyone know? > > > > I assume you are talking about 9x9? A rather optimistic estimate would > > be 1600 Elo on CGOS for 50k playouts per move; with GNUGo at 1800 Elo, > > we could estimate this as 8k KGS. > > myCtest-50k does exactly that and it rating is 1689 +- 15 (4000 games). With what parameters? Is it really plain UCT? It used to be weaker... http://senseis.xmp.net/?CGOSBasicUCTBots -- Petr "Pasky" Baudis The goal of Computer Science is to build something that will last at least until we've finished building it. ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] How well does pure monte carlo play?
On Sat, Jan 21, 2012 at 03:42:57PM -0500, Don Dailey wrote: > On Sat, Jan 21, 2012 at 2:31 PM, Eric Baum wrote: > > > If you don't do rave, or use patterns to predict likely moves, or any of > > that, but just do pure monte carlo, > > parallelized on a cluster,how well would that play Go? Anyone know? Given enough memory and thinking time, like a pro. ;-) Too general question. > If you are talking about a pure light playout without patterns but still > using a very basic MC tree implementation, it will play very poorly > compared to the best stuff we have. But it would still be better than > what we had before MCTS.It might reach the 1D level assuming a good > parallel cluster implementation. I assume you are talking about 9x9? A rather optimistic estimate would be 1600 Elo on CGOS for 50k playouts per move; with GNUGo at 1800 Elo, we could estimate this as 8k KGS. So about 12.8 million playouts per move assuming ideal scaling (100 Elo per doubling, again optimistic) in order to gain 800 Elo from there. I wonder what it would take in practice. I could never get non-RAVE MCTS to play above ~20k strength on 19x19 (not that I tried hard). Petr "Pasky" Baudis ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] kgs bot interface question
On Mon, Jan 16, 2012 at 08:53:47AM +0100, Rémi Coulom wrote: > I have this problem too. I think the problem is not resignation. The problem > is when several player challenge at the same time. You can tell kgsgtp to > write a log. Below is such a log for CrazyStone. > > So it must be a bug in kgsgtp. Maybe wms reads this. Otherwise, we could send > a message to him. I'm cc'ing ad...@gokgs.com. If the race condition is tricky to fix, a trivial workaround would be if the kgsGtp interface would at least have a lot shorter reconnect interval, e.g. 30 seconds instead of five minutes. > 30 déc. 2011 01:32:12 com.gokgs.client.gtp.GtpClient c > FIN: Game ended. Starting another. > 30 déc. 2011 01:32:12 com.gokgs.client.gtp.GtpClient a > PLUS FIN: No games to join. Creating an open game. > 30 déc. 2011 01:32:12 com.gokgs.client.gtp.f a > PLUS FIN: Joined challenge > 30 déc. 2011 01:32:20 com.gokgs.client.gtp.f a > PLUS FIN: Got challenge from "xiaosugi", testing engine response. > 30 déc. 2011 01:32:20 com.gokgs.client.gtp.GtpClient d > LE PLUS FIN: Command sent to engine: boardsize 19 > 30 déc. 2011 01:32:20 com.gokgs.client.gtp.GtpClient d > LE PLUS FIN: Got successful response to command "boardsize 19": = > 30 déc. 2011 01:32:20 com.gokgs.client.gtp.f a > LE PLUS FIN: Board size 19 is acceptable > 30 déc. 2011 01:32:20 com.gokgs.client.gtp.GtpClient d > LE PLUS FIN: Command sent to engine: time_settings 135 0 0 > 30 déc. 2011 01:32:20 com.gokgs.client.gtp.GtpClient d > LE PLUS FIN: Got successful response to command "time_settings 135 0 0": = > 30 déc. 2011 01:32:20 com.gokgs.client.gtp.f a > LE PLUS FIN: Time system is acceptable > 30 déc. 2011 01:32:20 com.gokgs.client.gtp.f a > LE PLUS FIN: Sending challenge back to server > 30 déc. 2011 01:32:20 com.gokgs.client.gtp.f a > PLUS FIN: Got challenge from "agotaoxin", testing engine response. > 30 déc. 2011 01:32:20 com.gokgs.client.gtp.GtpClient d > LE PLUS FIN: Command sent to engine: boardsize 19 > 30 déc. 2011 01:32:20 com.gokgs.client.gtp.GtpClient d > LE PLUS FIN: Got successful response to command "boardsize 19": = > 30 déc. 2011 01:32:20 com.gokgs.client.gtp.f a > LE PLUS FIN: Board size 19 is acceptable > 30 déc. 2011 01:32:20 com.gokgs.client.gtp.GtpClient d > LE PLUS FIN: Command sent to engine: time_settings 135 0 0 > 30 déc. 2011 01:32:20 com.gokgs.client.gtp.GtpClient d > LE PLUS FIN: Got successful response to command "time_settings 135 0 0": = > 30 déc. 2011 01:32:20 com.gokgs.client.gtp.f a > LE PLUS FIN: Time system is acceptable > 30 déc. 2011 01:32:20 com.gokgs.client.gtp.f a > LE PLUS FIN: Sending challenge back to server > 30 déc. 2011 01:32:21 com.gokgs.client.gtp.GtpClient e > GRAVE: Unexpected disconnect: The connection to the server has been closed > unexpectedly. You must log in again. > 30 déc. 2011 01:32:21 com.gokgs.client.gtp.GtpClient go > FIN: Will wait 5 minutes, then try to connect again. -- Petr "Pasky" Baudis The goal of Computer Science is to build something that will last at least until we've finished building it. ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
[Computer-go] Computer Go and EGC 2012
Hi! On Wed, Jan 18, 2012 at 08:04:24PM +0100, "Ingo Althöfer" wrote: > Due to the fact that there will be no special bot tournaments during > the EGC, there is some more flexibility for the exhibition games. Oh, that is quite a disappointment. :-( I wonder which program authors will be in Bonn? Maybe we could get together and organize at least a less official tournament, or just to chat some evening? Please let us know in this thread if you are coming! > For the 19x19 exhibition game the pro will be payed according to handicap. > He (or she) gets 50 Euro simply for playing. And he has the choice at which > handicap. When winning the game the pro gets additional money: > +50 Euro, when handicap was 2, > +100 Euro, when handicap was 3, > +200 Euro, when handicap was 4, > +300 Euro, when handicap was 5. That seems kind of strange, what motivation does the pro have to ever choose a different handicap than 5? -- Petr "Pasky" Baudis The goal of Computer Science is to build something that will last at least until we've finished building it. ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Re: [Computer-go] CrazyStone in the 5-dan footsteps of Zen
On Tue, Jan 03, 2012 at 12:25:57PM +0100, Petr Baudis wrote: > > Have the courage to > > compete under human conditions! Enter human tournaments! > > That's easy to say. Do you know a tournament where a program can enter? > I have tried few times with Pachi, never successfully yet. I think some > other authors tried as well in the past. P.S.: There will be a semi-official Czech Internet Go Championship played in 2012, with some fairly strong players participating as well: http://www.goweb.cz/cs/node/3306 - and Pachi (single computer version) will play in it. The time constrols will be varying main time and Japanese byoyomi 2x60s, which seems quite generous for the humans to avoid blunders. -- Petr "Pasky" Baudis The goal of Computer Science is to build something that will last at least until we've finished building it. ___ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
