Re: [Computer-go] Hosting mid-level bots on CGOS
Hi,
On Thu, Mar 15, 2018 at 04:27:44AM +, Brian Lee wrote:
> We're thinking about putting Pachi, Fuego, and the like on CGOS. I have a
> few questions:
> - Are the authors okay with us using our own compute resources to put their
> bots up on CGOS?
> - Do people have recommended hardware / configuration settings to run these
> bots?
feel absolutely free to run Pachi on CGOS! It definitely benefits
from faster CPUs and more threads (pays off handsomely up to *at least*
8 I'd say) but can play single threaded as well. It'd be great if you
share your Pachi CGOS setup with others if you find a good one I think.
Petr Baudis, Rossum
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] 9x9 is last frontier?
I think Hideki-san makes a great point. To rephrase it my way, AlphaGo-related advancements never really solved the MCTS limitation to properly read out precise "one way street" sequences and deal with the horizon effect. The value network amazingly compensates enough for this limitation on 19x19, but it inevitably does get into play on 9x9. On Fri, Feb 23, 2018 at 05:01:50PM -0800, uurtamo . wrote: > Slow down there, hombre. > > There's no secret sauce to 9x9 other than that it isn't the current focus > of people. > > Just like 7x7 isn't immune. > > A computer program for 9x9, funded, backed by halfway serious people, and > focused on the task, will *destroy* human opponents at any time it needs to. > > If you believe that there is a special reason that 9x9 is harder than > 19x19, then I'm super interested to hear that. But it's not harder for > computers. It's just not what people have been focusing on. > > s. > > On Feb 23, 2018 4:49 PM, "Hideki Kato" <hideki_ka...@ybb.ne.jp> wrote: > > > That's not the point, Petri. 9x9 has almost no "silent" > > or "static" positons which value networks superb humans. > > On 9x9 boards, Kos, especially double Kos and two step Kos > > are important but MCTS still works worse for them, for > > examples. Human professionals are much better at life > > and complex local fights which dominate small board games > > because they can read deterministically and deeper than > > current MCTS bots in standard time settings (not blitz). > > Also it's well known that MCTS is not good at finding narrow > > and deep paths to win due to "averaging". Ohashi 6p said > > that he couldn't lose against statiscal algorithms after the > > event in 2012. > > > > Best, > > Hideki > > > > Petri Pitkanen: <CAMp4Doefkp+n16CxDWY9at9OFwdh3V7+ > > 3zrby3k9kjvmzah...@mail.gmail.com>: > > >elo-range in 9x9 smaller than 19x19. One just cannot be hugelyl better > > than > > >the other is such limitted game > > > > > >2018-02-23 21:15 GMT+02:00 Hiroshi Yamashita <y...@bd.mbn.or.jp>: > > > > > >> Hi, > > >> > > >> Top 19x19 program reaches 4200 BayesElo on CGOS. But 3100 in 9x9. > > >> Maybe it is because people don't have much interest in 9x9. > > >> But it seems value network does not work well in 9x9. > > >> Weights_33_400 is maybe made by selfplay network. But it is 2946 in 9x9. > > >> Weights_31_3200 is 4069 in 19x19 though. > > >> > > >> In year 2012, Zen played 6 games against 3 Japanese Pros, and lost by > > 0-6. > > >> And it seems Zen's 9x9 strength does not change big even now. > > >> http://computer-go.org/pipermail/computer-go/2012-November/005556.html > > >> > > >> I feel there is still enough chance that human can beat best program in > > >> 9x9. > > >> > > >> Thanks, > > >> Hiroshi Yamashita > > >> > > >> ___ > > >> Computer-go mailing list > > >> Computer-go@computer-go.org > > >> http://computer-go.org/mailman/listinfo/computer-go > > > inline file > > >_______ > > >Computer-go mailing list > > >Computer-go@computer-go.org > > >http://computer-go.org/mailman/listinfo/computer-go > > -- > > Hideki Kato <mailto:hideki_ka...@ybb.ne.jp> > > ___ > > Computer-go mailing list > > Computer-go@computer-go.org > > http://computer-go.org/mailman/listinfo/computer-go > ___ > Computer-go mailing list > Computer-go@computer-go.org > http://computer-go.org/mailman/listinfo/computer-go -- Petr Baudis, Rossum Run before you walk! Fly before you crawl! Keep moving forward! If we fail, I'd rather fail really hugely. -- Moist von Lipwig ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Mastering Chess and Shogi by Self-Play with a General Reinforcement Learning Algorithm
On Wed, Dec 06, 2017 at 09:57:42AM -0800, Darren Cook wrote: > > Mastering Chess and Shogi by Self-Play with a General Reinforcement > > Learning Algorithm > > https://arxiv.org/pdf/1712.01815.pdf > > One of the changes they made (bottom of p.3) was to continuously update > the neural net, rather than require a new network to beat it 55% of the > time to be used. (That struck me as strange at the time, when reading > the AlphaGoZero paper - why not just >50%?) Yes, that also struck me. I think it's good news for the community to see it reported that this works, as it makes the training process much more straightforward. They also use just 800 simulations, another good news. (Both were one of the first tradeoffs I made in Nochi.) Another interesting tidbit: they use the TPUs to also generate the selfplay games. > The AlphaZero paper shows it out-performs AlphaGoZero, but they are > comparing to the 20-block, 3-day version. Not the 40-block, 40-day > version that was even stronger. > > As papers rarely show failures, can we take it to mean they couldn't > out-perform their best go bot, do you think? If so, I wonder how hard > they tried? IMHO the most likely explanation is that this research has been going on for a while and when they started in this direction, that early version was their state-of-art baseline. This kind of chronology, with the 40-block version being almost "a last-minute addition", is imho apparent even in the text of the Nature paper. Also, the 3-day version simply had roughly similar training time available as AlphaZero did. -- Petr Baudis, Rossum Run before you walk! Fly before you crawl! Keep moving forward! If we fail, I'd rather fail really hugely. -- Moist von Lipwig ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] Is MCTS needed?
Hi, when explaining AlphaGo Zero to a machine learning audience yesterday (https://docs.google.com/presentation/d/1VIueYgFciGr9pxiGmoQyUQ088Ca4ouvEFDPoWpRO4oQ/view) it occurred to me that using MCTS in this setup is actually such a kludge! Originally, we used MCTS because with the repeated simulations, we would be improving the accuracy of the arm reward estimates. MCTS policies assume stationary distributions, which is violated every time we expand the tree, but it's an okay tradeoff if all you feed into the tree are rewards in the form of just Bernoulli trials. Moreover, you could argue evaluations are somewhat monotonic with increasing node depths as you are basically just fixing a growing prefix of the MC simulation. But now, we expand the nodes literally all the time, breaking the stationarity possibly in drastic ways. There are no reevaluations that would improve your estimate. The input isn't binary but an estimate in a continuous space. Suddenly the Multi-armed Bandit analogy loses a lot of ground. Therefore, can't we take the next step, and do away with MCTS? Is there a theoretical viewpoint from which it still makes sense as the best policy improvement operator? What would you say is the current state-of-art game tree search for chess? That's a very unfamiliar world for me, to be honest all I really know is MCTS... -- Petr Baudis, Rossum Run before you walk! Fly before you crawl! Keep moving forward! If we fail, I'd rather fail really hugely. -- Moist von Lipwig ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Nochi: Slightly successful AlphaGo Zero replication
On Fri, Nov 10, 2017 at 03:40:27PM +0100, Gian-Carlo Pascutto wrote: > On 10/11/2017 1:47, Petr Baudis wrote: > > > * AlphaGo used 19 resnet layers for 19x19, so I used 7 layers for 7x7. > > How many filters per layer? 256 like AlphaGo. > FWIW 7 layer resnet (14 + 2 layers) is still pretty huge - larger than > the initial AlphaGo. Given the amount of games you have, and the size of > the board, I would not be surprised if your neural net program is > "outbooking" the opponent by remembering the sequences rather than > learning more generic things. > > (But hey, outbooking is learning too!) I couldn't exclude this, yes. It would be interesting to try to use the same convolutions on a bigger board to see if they play shapes and can do basic tactics. > > * The neural network is updated after _every_ game, _twice_, on _all_ > > positions plus 64 randomly sampled positions from the entire history, > > this all done four times - on original position and the three > > symmetry flips (but I was too lazy to implement 90\deg rotation). > > The reasoning being to give a stronger and faster reinforcement with the > latest data? Yes. > > * Value function is trained with cross-entropy rather than MSE, > > no L2 regularization, and plain Adam rather than hand-tuned SGD (but > > the annealing is reset time by time due to manual restarts of the > > script from a checkpoint). > > I never really had good results with Adam and friends compared to SGD > (even momentum does not always help - but of course it's much faster > early on). It has worked great on all my neural models in other tasks - but this is actually my first neural model for Go. :) > > * No resign auto-threshold but it is important to play 25% games > > without resigning to escale local "optima". > > This makes sense because both sides will miscount in exactly the same way. Without this, producing value 1.0 for one color and 0.0 for the other is a super-strong attractor. > > * 1/Temperature is 2 for first three moves. > > * Initially I used 1000 "simulations" per move, but by mistake, last > > 1500 games when the network improved significantly (see below) were > > run with 2000 simulations per move. So that might matter. > > > > This has been running for two weeks, self-playing 8500 games. A week > > ago its moves already looked a bit natural but it was stuck in various > > local optima. Three days ago it has beaten GNUGo once across 20 games. > > Now five times across 20 games - so I'll let it self-play a little longer > > as it might surpass GNUGo quickly at this point? Also this late > > improvement coincides with the increased simulation number. > > The simulation number if one of the big black boxes in this setup, I > think. If the policy network does not have a strong opinion yet, it > seems that one has to make it sufficiently bigger than the amount of > legal moves. If not, first-play-urgency will cause every successor > position to be evaluated and there's no look ahead, which means MCTS > can't discover anything. I don't see how first-play-urgency comes into play. Initially it'll be typically noise but that still means growing the tree pretty asymmetrically. I saw uniform sampling only in some cases when number of simulations was << number of children. > So a few times 361 makes sense for 19x19, but don't ask me why 1600 and > not 1200 etc. My feeling now is that especially slightly later on raising the count really helps. I think the moment is when you stop seeing regular, large discrepancies between network predictions and scoring output in very late endgame. But it could be an illusion. > With only 50-ish moves to consider on 7x7, it's interesting that you see > a big improvement by making it (relatively) much larger than DeepMind did. > > But uh, you're not simply matching it against GNUGo with more > simulations are you? I mean it would be quite normal to win more when > searching deeper. All playtests should have been with 2000 simulations. -- Petr Baudis, Rossum Run before you walk! Fly before you crawl! Keep moving forward! If we fail, I'd rather fail really hugely. -- Moist von Lipwig ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Nochi: Slightly successful AlphaGo Zero replication
On Fri, Nov 10, 2017 at 01:47:17AM +0100, Petr Baudis wrote:
> This is a truly "zero-knowledge" system like AlphaGo Zero - it needs
> no supervision, and it contains no Monte Carlo simulations or other
> heuristics. But it's not entirely 1:1, I did some tweaks which I thought
> might help early convergence:
* The usual MC rule of not filling one's true eye is used - eye-filling
moves are never considered by Nochi. Rather than encoding knowledge,
I prefer to think about this as a tweaked Go ruleset, but YMMV. :)
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] Nochi: Slightly successful AlphaGo Zero replication
Hi, I got first *somewhat* positive results in my attempt to reproduce AlphaGo Zero - 25% winrate against GNUGo on the easiest reasonable task - 7x7 board. :) a.k.a. "Sometimes beating GNUGo on a tiny board" without human knowledge (much wow!) Normally this would be a pretty weak result much but (A) I wanted to help calibrate other efforts on larger boards that are possibly still at the "random" stage, and (B) I'll probably move on to other projects again soon, so this might be as good as it gets for me. I started the project by replacing MC simulations with a Keras model in my 550-line educational Go program Michi - it lived in its `nnet` branch until now when I separated it to a project on its own: https://github.com/rossumai/nochi Starting from a small base means that the codebase is tiny and should be easy to follow, though it's not at all as tidy as Michi is. You can grab the current training state (== pickled archive of selfplay positions used for replay, chronological) and neural network weights from the github's "Releases" page: https://github.com/rossumai/nochi/releases/tag/G171107T013304_00150 This is a truly "zero-knowledge" system like AlphaGo Zero - it needs no supervision, and it contains no Monte Carlo simulations or other heuristics. But it's not entirely 1:1, I did some tweaks which I thought might help early convergence: * AlphaGo used 19 resnet layers for 19x19, so I used 7 layers for 7x7. * The neural network is updated after _every_ game, _twice_, on _all_ positions plus 64 randomly sampled positions from the entire history, this all done four times - on original position and the three symmetry flips (but I was too lazy to implement 90\deg rotation). * Instead of supplying last 8 positions as the network input I feed just the last position plus two indicator matrices showing the location of the last and second-to-last move. * No symmetry pruning during tree search. * Value function is trained with cross-entropy rather than MSE, no L2 regularization, and plain Adam rather than hand-tuned SGD (but the annealing is reset time by time due to manual restarts of the script from a checkpoint). * No resign auto-threshold but it is important to play 25% games without resigning to escale local "optima". * 1/Temperature is 2 for first three moves. * Initially I used 1000 "simulations" per move, but by mistake, last 1500 games when the network improved significantly (see below) were run with 2000 simulations per move. So that might matter. This has been running for two weeks, self-playing 8500 games. A week ago its moves already looked a bit natural but it was stuck in various local optima. Three days ago it has beaten GNUGo once across 20 games. Now five times across 20 games - so I'll let it self-play a little longer as it might surpass GNUGo quickly at this point? Also this late improvement coincides with the increased simulation number. At the same time, Nochi supports supervised training (with the rest kept the same) which I'm now experimenting with on 19x19. Happy training, -- Petr Baudis, Rossum Run before you walk! Fly before you crawl! Keep moving forward! If we fail, I'd rather fail really hugely. -- Moist von Lipwig ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] November KGS bot tournament
Thank you so much for organizing the tournaments! I think AlphaGo work is becoming easier to reproduce with their recent paper and there might be some new entrants. Perhaps a tournament every 6 months would be interesting. I considered entering Pachi, but it would be so much weaker than the other programs, I guess it would be a bit sad ending. But I might have a goal now: See if I can make my Michi nnet fork do anything meaningful on 19x19 before Sunday. :) On Thu, Oct 26, 2017 at 08:43:17AM +0100, Nick Wedd wrote: > The November KGS bot tournament will be on Sunday, November 5th, starting > at 16:00 UTC and ending by 22:00 UTC. It will use 19x19 boards, with > time limits > of 14 minutes each and very fast Canadian overtime, and komi of 7½. It > will be a Swiss tournament. See http://www.gokgs.com/tournInfo.jsp?id=112 > <http://www.gokgs.com/tournInfo.jsp?id=1116>7 > > Please register by emailing me at mapr...@gmail.com, with the words "KGS > Tournament Registration" in the email title. > With the falling interest in these events since the advent of AlphaGo, it > is likely that this will be the last of the series of KGS bot tournaments. > > Nick > -- > Nick Wedd mapr...@gmail.com -- Petr Baudis, Rossum Run before you walk! Fly before you crawl! Keep moving forward! If we fail, I'd rather fail really hugely. -- Moist von Lipwig ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] AlphaGo Zero
On Fri, Oct 20, 2017 at 08:02:02PM +, Gian-Carlo Pascutto wrote:
> On Fri, Oct 20, 2017, 21:48 Petr Baudis <pa...@ucw.cz> wrote:
>
> > Few open questions I currently have, comments welcome:
> >
> > - there is no input representing the number of captures; is this
> > information somehow implicit or can the learned winrate predictor
> > never truly approximate the true values because of this?
> >
>
> They are using Chinese rules, so prisoners don't matter. There are simply
> less stones of one color on the board.
Right! No idea what was I thinking.
> > - what ballpark values for c_{puct} are reasonable?
> >
>
> The original paper has the value they used. But this likely needs tuning. I
> would tune with a supervised network to get started, but you need games for
> that. Does it even matter much early on? The network is random :)
The network actually adapts quite rapidly initially, in my experience.
(Doesn't mean it improves - it adapts within local optima of the few
games it played so far.)
> > - why is the dirichlet noise applied only at the root node, if it's
> > useful?
> >
>
> It's only used to get some randomness in the move selection, no ? It's not
> actually useful for anything besides that.
Yes, but why wouldn't you want that randomness in the second or third
move?
> > - the training process is quite lazy - it's not like the network sees
> > each game immediately and adjusts, it looks at last 500k games and
> > samples 1000*2048 positions, meaning about 4 positions per game (if
> > I understood this right) - I wonder what would happen if we trained
> > it more aggressively, and what AlphaGo does during the initial 500k
> > games; currently, I'm training on all positions immediately, I guess
> > I should at least shuffle them ;)
> >
>
> I think the lazyness may be related to the concern that reinforcement
> methods can easily "forget" things they had learned before. The value
> network training also likes positions from distinct games.
That makes sense. I still hope that with a much more aggressive
training schedule we could train a reasonable Go player, perhaps at the
expense of worse scaling at very high elos... (At least I feel
optimistic after discovering a stupid bug in my code.)
--
Petr Baudis, Rossum
Run before you walk! Fly before you crawl! Keep moving forward!
If we fail, I'd rather fail really hugely. -- Moist von Lipwig
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] AlphaGo Zero
I tried to reimplement the system - in a simplified way, trying to
find the minimum that learns to play 5x5 in a few thousands of
self-plays. Turns out there are several components which are important
to avoid some obvious attractors (like the network predicting black
loses on every move from its second game on):
- disabling resignation in a portion of games is essential not just
for tuning resignation threshold (if you want to even do that), but
just to correct prediction signal by actual scoring rather than
starting to always resign early in the game
- dirichlet (or other) noise is essential for the network getting
looped into the same game - which is also self-reinforcing
- i have my doubts about the idea of high temperature move choices
at the beginning, especially with T=1 ... maybe that's just bad
very early in the training
On Thu, Oct 19, 2017 at 02:23:41PM +0200, Petr Baudis wrote:
> The order of magnitude matches my parameter numbers. (My attempt to
> reproduce a simplified version of this is currently evolving at
> https://github.com/pasky/michi/tree/nnet but the code is a mess right
> now.)
--
Petr Baudis, Rossum
Run before you walk! Fly before you crawl! Keep moving forward!
If we fail, I'd rather fail really hugely. -- Moist von Lipwig
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] AlphaGo Zero
The order of magnitude matches my parameter numbers. (My attempt to reproduce a simplified version of this is currently evolving at https://github.com/pasky/michi/tree/nnet but the code is a mess right now.) On Thu, Oct 19, 2017 at 07:23:31AM -0400, Álvaro Begué wrote: > This is a quick check of my understanding of the network architecture. > Let's count the number of parameters in the model: > * convolutional block: (17*9+1)*256 + 2*256 > [ 17 = number of input channels >9 = size of the 3x3 convolution window >1 = bias (I am not sure this is needed if you are going to do batch > normalization immediately after) > 256 = number of output channels >2 = mean and standard deviation of the output of the batch normalization > 256 = number of channels in the batch normalization ] > * residual block: (256*9+1)*256 + 2*256 + (256*9+1)*256 + 2*256 > * policy head: (256*1+1)*2 + 2*2 + (2*361+1)*362 > * value head: (256*1+1)*1 + 2*1 + (1*361+1)*256 + (256+1)*1 > > Summing it all up, I get 22,837,864 parameters for the 20-block network and > 46,461,544 parameters for the 40-block network. > > Does this seem correct? > > Álvaro. > > > > On Thu, Oct 19, 2017 at 6:17 AM, Petr Baudis <pa...@ucw.cz> wrote: > > > On Wed, Oct 18, 2017 at 04:29:47PM -0700, David Doshay wrote: > > > I saw my first AlphaGo Zero joke today: > > > > > > After a few more months of self-play the games might look like this: > > > > > > AlphaGo Zero Black - move 1 > > > AlphaGo Zero White - resigns > > > > ...which is exactly what my quick attempt to reproduce AlphaGo Zero > > yesterday converged to overnight. ;-) But I'm afraid it's because of > > a bug, not wisdom... > > > > Petr Baudis > > ___ > > Computer-go mailing list > > Computer-go@computer-go.org > > http://computer-go.org/mailman/listinfo/computer-go > > > ___ > Computer-go mailing list > Computer-go@computer-go.org > http://computer-go.org/mailman/listinfo/computer-go -- Petr Baudis, Rossum Run before you walk! Fly before you crawl! Keep moving forward! If we fail, I'd rather fail really hugely. -- Moist von Lipwig ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] AlphaGo Zero
On Wed, Oct 18, 2017 at 04:29:47PM -0700, David Doshay wrote:
> I saw my first AlphaGo Zero joke today:
>
> After a few more months of self-play the games might look like this:
>
> AlphaGo Zero Black - move 1
> AlphaGo Zero White - resigns
...which is exactly what my quick attempt to reproduce AlphaGo Zero
yesterday converged to overnight. ;-) But I'm afraid it's because of
a bug, not wisdom...
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Deep Blue the end, AlphaGo the beginning?
On Fri, Aug 18, 2017 at 06:31:54PM +0200, Gian-Carlo Pascutto wrote: > On 18-08-17 16:56, Petr Baudis wrote: > >> Uh, what was the argument again? > > > > Well, unrelated to what you wrote :-) - that Deep Blue implemented > > existing methods in a cool application, while AlphaGo introduced > > some very new methods (perhaps not entirely fundamentally, but still > > definitely a ground-breaking work). > > I just fundamentally disagree with this characterization, which I think > is grossly unfair to the Chiptest/Deep Thought/Deep Blue lineage. > Remember there were 12 years in-between those programs. > > They did not just...re-implement the same "existing methods" over and > over again all that time. Implementation details and exact workings are > very important [1]. I imagine the main reason this false distinction > (i.e. the "artificial difference" from my original post) is being made > is, IMHO, that you're all aware of the fine nuances of how AlphaGo DCNN > usage (for example) differs compared to previous efforts, but you're not > aware of the same nuances in Chiptest and successors etc. You may be completely right! And yes, I was thinking about Deep Blue in isolation, not that aware about general computer chess history. Do you have some suggested reading regarding Deep Blue and its lineage and their contributions to the field of AI at large? Thanks, -- Petr Baudis, Rossum Run before you walk! Fly before you crawl! Keep moving forward! If we fail, I'd rather fail really hugely. -- Moist von Lipwig ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Deep Blue the end, AlphaGo the beginning?
On Fri, Aug 18, 2017 at 09:06:41AM +0200, Gian-Carlo Pascutto wrote: > On 17-08-17 21:35, Darren Cook wrote: > > "I'm sure some things were learned about parallel processing... but the > > real science was known by the 1997 rematch... but AlphaGo is an entirely > > different thing. Deep Blue's chess algorithms were good for playing > > chess very well. The machine-learning methods AlphaGo uses are > > applicable to practically anything." > > > > Agree or disagree? > > Deep Thought (the predecessor of Deep Blue) used a Supervised Learning > approach to set the initial evaluation weights. The details might be > lost in time but it's reasonable to assume some were carried over to > Deep Blue. Deep Blue itself used hill-climbing to find evaluation > features that did not seem to correlate with strength much, and improve > them. > > A lot of the strength of AlphaGo comes from a fast, parallelized tree > search. > > Uh, what was the argument again? Well, unrelated to what you wrote :-) - that Deep Blue implemented existing methods in a cool application, while AlphaGo introduced some very new methods (perhaps not entirely fundamentally, but still definitely a ground-breaking work). And I completely agree with that argument. Nonwithstanding, it's clear that AlphaGo's methods take advantage of many convenient properties of Go and there's still a lot to do. I liked Andrej Karpathy's summary on this: https://medium.com/@karpathy/alphago-in-context-c47718cb95a5 -- Petr Baudis, Rossum Run before you walk! Fly before you crawl! Keep moving forward! If we fail, I'd rather fail really hugely. -- Moist von Lipwig ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Alphago and solving Go
BTW, if anyone is wondering about the "roughly" part, 361! = 1.438 * 10^768 while L19 = 2.081681994 * 10^170. On Sun, Aug 06, 2017 at 07:14:42PM -0700, David Doshay wrote: > Yes, that zeroth order number (the one you get to without any thinking about > how the game’s rules affect the calculation) is outdated since early last > year when this result gave us the exact number of legal board positions: > > https://tromp.github.io/go/legal.html <https://tromp.github.io/go/legal.html> > > So, a complete game tree for 19x19 Go would contain about 2.08 * 10^170 > unique nodes (see the paper for all 171 digits) but some number of duplicates > of those nodes for the different paths to each legal position. > > In an unfortunate bit of timing, it seems that many people missed this result > because of the Alpha Go news. > > Cheers, > David G Doshay > > ddos...@mac.com > > > > > > > On 6, Aug 2017, at 3:17 PM, Gunnar Farnebäck <gun...@lysator.liu.se> wrote: > > > > On 08/06/2017 04:39 PM, Vincent Richard wrote: > >> No, simply because there are way to many possibilities in the game, > >> roughly (19x19)! > > > > Can we lay this particular number to rest? Not that "possibilities in the > > game" is very well defined (what does it even mean?) but the number of > > permutations of 19x19 points has no meaningful connection to the game of go > > at all, not even "roughly". > > > > /Gunnar > > ___ > > Computer-go mailing list > > Computer-go@computer-go.org > > http://computer-go.org/mailman/listinfo/computer-go > > ___ > Computer-go mailing list > Computer-go@computer-go.org > http://computer-go.org/mailman/listinfo/computer-go -- Petr Baudis, Rossum Run before you walk! Fly before you crawl! Keep moving forward! If we fail, I'd rather fail really hugely. -- Moist von Lipwig ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] AlphaGo Retires
After winning against Ke Jie 3-0 https://deepmind.com/research/alphago/alphago-china/ AlphaGo retires from competitive Go. The team released 50 selfplay games, will work on a teaching tool and publishing a second paper. https://blog.google/topics/google-asia/alphagos-next-move/ https://deepmind.com/research/alphago/alphago-vs-alphago-self-play-games/ Congratulations and thank you, AlphaGo team, for your open scientific approach and publishing your methods. The Computer Go community learned a lot as well, as evident from nowadays high-ranked KGS bots. -- Petr Baudis, Rossum.ai Run before you walk! Fly before you crawl! Keep moving forward! If we fail, I'd rather fail really hugely. -- Moist von Lipwig ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Messages classified as spam.
Hello, On Thu, Jan 12, 2017 at 12:44:44PM +0100, Gian-Carlo Pascutto wrote: > On 12/01/2017 11:55, Rémi Coulom wrote: > > It is the mail server of this mailing list that is not well > > configured. Even my own messages are classified as spam for me now. > > The list does not send DKIM identification. for mailing lists, the topic of DKIM is complicated, it's not just about outgoing email. It saddens me if Remi's ISP free.fr goes as far as assuming emails without DKIM are spam, but I believe this is still quite uncommon and none of us probably has time to start fiddling with this either. > It's been a while since I looked at this in depth, but the problem seems > to be that it modifies the email but doesn't strip the original DKIM, > which then fails to validate. Even adding a DKIM from the mailinglist > wouldn't help, because in Patricks' case, his domain has a stated DMARC > policy, which requires a valid DKIM from that same domain. It's the > DMARC that makes this so much worse as just failing DKIM isn't usually > enough to get classified as spam. > > The list is on MailMan 2.1.18, which has support for working around this > problem: > http://www.spamresource.com/2016/09/dmarc-support-in-mailman.html > https://wiki.list.org/DEV/DMARC > > Admin, can you try this dmarc_moderation_action = Munge From? I just tried to enable this, even though the action taken is mildly horrifying for me - hopefully it will indeed happen only to emails from DMARC-reject domains. Thanks for the pointer! -- Petr Baudis Run before you walk! Fly before you crawl! Keep moving forward! If we fail, I'd rather fail really hugely. -- Moist von Lipwig ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Go Tournament with hinteresting rules
Hi! On Thu, Dec 08, 2016 at 11:23:50PM -0800, Freeman Ng wrote: > No, it's because the bots' mc based algorithms currently don't care how > much they win by. (At least I'm assuming that's what Ingo meant.) They just > try to maximize their odds of winning. > > I've often wondered about this, though, and maybe the bot developers here > can give me an answer. There's no reason why an mc-based go program > couldn't also factor winning margin into its decisions, is there? I assume > that at some point, what the mc analysis yields is a winning probability > for each candidate move, but at that point, you could still combine that > number with other factors, right? Some combination of winning probability > and probable winning margin, so that, for example, a 87% chance of winning > by 5 points could be rated lower than a 85% change of winning by 20. I > don't know what the ideal formula would be, and you'd probably want to > prevent the winning probability from ever getting too low, while also > ignoring potentially large winning margins beyond a certain point, but the > idea would be to generally make the bots play more like humans. I think many programs use this hack. (In Pachi, we eventually disabled it because it compromised strength noticeably.) The basic explanation for why this is not straightforward is that you never want your program to consider moves in the direction of low-probability wins, no matter how large margins they might have; the MC measurement function is very noisy with regards to individual samples. > Do any commercial Go programs work this way? If not, I'd like to request it > from the commercial developers here. It could be an option that you'd only > have in the commercial product, for your users to turn on if they prefer > it. You could still operate in pure mc mode for bot vs. bot play. A more robust version of this strategy, that is used commonly in many programs, is dynamic komi. But it can also exhibit unstable behavior in some cases, especially in late endgame. I didn't quite understand why is this important for commercial programs in particular? (For this mode in particular, e.g. Pachi has a special mode where it enables a variety of such features (but is weaker in general) when given the "maximize_score" parameter. I wonder if other programs also have multiple modes like this.) Petr Baudis ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] AlphaGo selfplay 3 games
On Wed, Sep 14, 2016 at 06:25:42PM +0900, Hiroshi Yamashita wrote: > Hi, > > DeepMind published AlphaGo's selfplay 3 games with comment. > > AlphaGo Games - English > https://deepmind.com/research/alphago/alphago-games-english/ > > OHASHI Hirofumi 6d pro said > "I understood AlphaGo is extremely strong even if 5sec/move." Wow. I have looked only at the first self-play game so far, but it really is impressive. To me, the most frightening move is 156, I wonder if after black B, AlphaGo would indeed play out the long and complex semeai correctly, or if it just "sensed". -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Zen19K: a KGS-9-dan in the making
On Sat, Aug 27, 2016 at 02:04:39PM +0200, "Ingo Althöfer" wrote:
> the cooperation of the Zen team and Dwango provides
> first fat harvest: Zen19K is on the path to become
> the first bot with a 9-dan rating on KGS:
> http://www.gokgs.com/gameArchives.jsp?user=zen19k
>
> Observe: this is not the Zen that will play against
> Luks Kraemer in the codecentric Challenge (from tomorrow on).
Silly question - why not? (Assuming this seems to be the strongest Zen
so far.)
Thanks,
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Commonsense Go
On Thu, Aug 11, 2016 at 11:22:17PM +0100, Gonçalo Mendes Ferreira wrote: > Hello, I'm sharing with you a document that was shared in the GNU Go > mailing list and I found interesting. Its author is currently muted from > this list, but I think it is very much worth sharing here instead. > > There haven't been many papers on a classical approach to Go in recent > years (decade?). > > Here it is > http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2818149 > > The original thread can be found at > http://lists.gnu.org/archive/html/gnugo-devel/2016-08/msg2.html lists.gnu.org isn't talking to me right now, but I've skimmed through the paper. It contains a high-level pseudocode for strategic planning of a Go-playing agent. However, it unfortunately doesn't explain how to implement the functions like influence() or how to efficiently read out the sequences appropriate for its kill() subroutine. From what I remember when I first started digging into GNUGo, the actual GNUGo's implementation might be actually very similar to what the paper describes! The trouble starts when one starts looking into the "implementation details" and how to avoid the combinatorial explosion of possible sequences. I'd encourage djhbrown to look into the GNUGo general strategy code (which is *not* just a general alpha-beta search) and consider why it doesn't work that well in practice. I have found debugging GNUGo's mistakes a great educational experience in the fundamental flaws of classic engines back then. -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] DarkForest is open-source now.
My personal opinion is that it's fine: https://github.com/facebookresearch/darkforestGo/issues/1 https://twitter.com/xpasky/status/741381620322738176 To me, this usage is very different to e.g. someone taking Pachi as a whole and integrating it in a non-GPL product, or even taking substantial Pachi code (board implementation, some more elaborate tactics heuristics, ...) and *building their non-GPL engine around that*. No time to elaborate about the nuances (of my personal legal opinion + IANAL) right now, but in general licencing is not so simple that any few lines of code will make the whole source tree GPL no questions asked. First, it must be actually copyrightable, which is not an automatic thing and a stretch to say about most of the bits outside dedicated Pachi directory (which are generally just scattered pieces of technical scaffolding). Second, it must make the rest of the source a derivative work, which imho is clearly not the case for the simple playout policy. [*] If someone distributes a compiled DarkForest binary with the "simple policy" of pachi subdirectory linked in, *that* is covered by GPL. But it should be a trivial matter not to even link it in. Let's not let this discussion overshadow the fact that we have the new strongest open source bot! Congratulations and huge thanks to FAIR for releasing it as open source. (At least if/until Pachi gets proper NN support as well. ;-) On Fri, Jun 10, 2016 at 11:02:15PM +0200, Xavier Combelle wrote: > for me it's clearly GPL violation > > 2016-06-10 22:17 GMT+02:00 Darren Cook <dar...@dcook.org>: > > > >> At 5d KGS, is this the world's strongest MIT/BSD licensed program? ... > > >> actually, is there any other MIT/BSD go program out there? (I thought > > >> Pachi was, but it is GPLv2) > > > > > > Huh, that's interesting, because Darkforest seems to have copy-pasted > > > the pachi playout policy: > > > > > > > > https://github.com/facebookresearch/darkforestGo/blob/master/board/pattern.c#L36 > > > > > > https://github.com/pasky/pachi/blob/master/playout/moggy.c#L101 > > > > Uh-oh. Though it does say "inspired by" at the top, and also that it is > > not used by the main engine: > > > > // This file is inspired by Pachi's engine > > // (https://github.com/pasky/pachi). > > // The main DarkForest engine (when specified > > // with `--playout_policy v2`) does not depend on it. > > // However, the simple policy opened with > > // `--playout_policy simple` will use this library. > > > > > > Darren > > > > ___ > > Computer-go mailing list > > Computer-go@computer-go.org > > http://computer-go.org/mailman/listinfo/computer-go > > > ___ > Computer-go mailing list > Computer-go@computer-go.org > http://computer-go.org/mailman/listinfo/computer-go -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Commercial Go software and high-end users
Hi! Couple of ideas. On Mon, May 30, 2016 at 06:19:39AM +0200, "Ingo Althöfer" wrote: > One point is: The absolute strength of the program need not to be > better than the strength of the player who uses it for analysis purposes. > It is enough that the program is tactically strong. But strong Go programs are traditionally strategically strong, but tactically *weak*. We still don't have a good publicly available tsumego solver. I think this makes their capabilities a lot less useful for game analysis. > Another point: Once you have a database program with nice functionality, > it is only a question of short time until it is supported by playing > programs. (I think we have pretty good web-based Go database engines now.) > > On the other hand, commercial engines are probably close to breaking the > > 1p barrier soon. At which point they'll become analysis tools even for > > the higher echelon of players, if initial resistance to "a new thing" > > can be overcome. > > And for that it would be very helpful to have a few popular top players > using it. So my main hypothesis is that the English-speaking market is very small, and the East Asian language barrier(s) prevent a lot of network effects to kick in; the Western audience is small and the barrier is hard to overcome. (In the Chess world, there probably was English-Russian barrier but the player distribution is still a lot more even, imho.) -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] new bot friendly go server.
Hi!
On Sun, May 22, 2016 at 08:56:09AM +, Henry Hemming wrote:
> Hello, I would like to invite all you go bot developers to my new go server.
>
> http://goratingserver.appspot.com
I tried a game last evening too. I didn't mind not being able to
choose my nickname too much (I just clicked until I got a rodent nick ;),
and I liked the mechanics and minimalism in general.
However, at the end of the game both me and my opponent became a bit
confused as we didn't realize we have to capture dead stones; I'd
strongly suggest adding ability to mark dead stones before releasing it
to wider audience; playing it out is really tedious and my opponent
didn't realize they had to do it at all (the message is not so well
visible, they might not know English or even know how to read).
I'm not sure if I'll return; if I wanted to play in the browser, I'd
pick OGS and it doesn't seem clear what the advantages of your server
are, possibly besides your unique rating algorithm (which I'd also love
to hear more about).
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Question on TPU hardware
On Sat, May 21, 2016 at 09:25:53AM +0200, "Ingo Althöfer" wrote:
> I have a question (maybe to Aja):
>
> Concerning the TPU hardware used in AlphaGo, how long will it take
> until that system (all together, including Go software) will be
> available for 20,000 Euro or less?
I don't have an answer, but want to note that the main power of TPU is
at training time. Unless a breakthrough happenned after the AlphaGo
paper in this regard as well, when using the TPUs during actual
gameplay, you probably quickly hit diminishing returns and you'd be just
as fine with using a bunch of GPUs.
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] Google used TPUs for AlphaGo
Hi, it seems that Google in fact used TPUs for AlphaGo rather than GPUs: https://cloudplatform.googleblog.com/2016/05/Google-supercharges-machine-learning-tasks-with-custom-chip.html It's be interesting to know what the speedup factor against, say, Tesla K40 is. In the Nature paper, they talk about GPUs, but they could have switched to TPUs for training only after then Fan Hui matches. Petr Baudis ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] KGS bot tournaments: structure
Hi!
On Tue, May 10, 2016 at 08:15:16AM +0100, Nick Wedd wrote:
> A problem with McMahon is that the scheduling software (a module of the KGS
> server, which I have no control over) uses the ratings assigned by KGS, and
> many bots do not have such ratings. I don't think it's reasonable to
> require all entrants to have rated bot status. Rated bot status is granted
> only to *stable* bots, ones which do not change rapidly in strength and
> thereby upset the ratings of their opponents.
When I was asking for ranked bot accounts, I was encouraged to create
new accounts whenever I changed something major. Therefore, worst case
scenario would be that before each tournament, an author of a rapidly
developing bot would create a new ranked bot account, get rated and
enter the tournament.
This assumes that the superadmin is responsive and not easily annoyed
by such requests. That seemed mostly the case many years ago, but could
have changed. Maybe they could delegate enabling ranks for bots to you?
Also, it doesn't seem bad to me to have such restrictions if (i) it
takes only reasonable effort on your side to meet them (i.e. you don't
get stuck because KGS superadmin disappears for weeks), and (ii) not all
tournaments have them (my suggestion to hold only every other tournament
as McMahon with reduced handicaps).
> Maybe we could combine the two suggestions. Have two divisions: upper
> division McMahon, with entrants required to have KGS ratings of 7k or
> better; lower division open. I would like to hear people's views on this -
> and any more suggestions they have.
I don't watch the tournaments that closely, but it seems to me the
average pool of entrants is not that big, so splitting them to multiple
divisions might not end up well.
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Congratulations to Zen!
Another matter is that, in case of MCTS programs, encouraging them to play well in handicap games was a troublesome point. This cuts both ways (may discourage participation, or encourage implementation of better handling of handicap games). A possible strategy would be: - Require ranked programs (with at least 30 rated games played in last 30 days using the tournament version) - Use McMahon scheduling - Use handicaps reduced by 2, topped at 4 stones. (More liberally, topped at 6 stones.) - Apply these rules only every other month to test it out; this should be out of phase with the other variations? This might be a lot more fun to watch. :) Handicap reduction is important to still give the stronger programs a good edge. On Mon, May 09, 2016 at 11:16:58PM +0200, Erik van der Werf wrote: > Why not McMahon? (possibly with reduced handicap). It works fine in human > Go tournaments. > > IMO KGS Swiss is pretty boring for most of the time, and the scheduler > often seems to have a lot of undesired influence on the final ranking. Also > at this point I'm really not that interested any more to see some top > engine win yet another bot tournament without serious competition; I'd be > more interested to see how many stones they could give to the rest. > Wouldn't it be fun to see how many stones AlphaGo could give to CS? > > E. > > > On Mon, May 9, 2016 at 10:29 PM, "Ingo Althöfer" <3-hirn-ver...@gmx.de> > wrote: > > > Hi Gian-Carlo, > > > > I have thought carefully about your question on > > determinning handicaps properly. > > It seems you are very right with your doubts > > > > > The first obvious question is then: how will you determine the handicaps? > > > > A naive approach would be to take the KGS ranks of the bots. > > But even for those who really have this may be a problem. Namely, > > the program may use other/stronger hardware in the tournament, > > or may have made a jump in performance without playing openly > > on KGS. > > > > > As to the "large gaps in strength": the actual rating of Zen is > > > 1 stone above abakus, which is 1 stone above HiraBot. That seems > > > to conflict with your classification. > > > > Yes, but only according to KGS ranks. My impression yesterday was > > that Zen has made another jump in performance and is now more > > an 8-dan than a 7-dan. But this is indeed only a personal opinion > > and can not be taken for "serious" handicapping. > > > > Concerning abakus and Hirabot, it is indeed my opinion that they > > are at most 1 stone apart of each other. > > > > In total: my handicap idea seems not to be practicable. > > > > Ingo. > > ___ > > Computer-go mailing list > > Computer-go@computer-go.org > > http://computer-go.org/mailman/listinfo/computer-go > > > ___ > Computer-go mailing list > Computer-go@computer-go.org > http://computer-go.org/mailman/listinfo/computer-go -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] OpenAI Gym
Hi,
OpenAI has released a "gym for reinforcement learning algorithms". It
offers many environments, includes games etc., but also 9x9 Go and 19x19
Go. (Behind the scenes, it seems to use Pachi somehow. ;-) Maybe as
a reference opponent.)
https://gym.openai.com/envs#board_game
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Is Go group pattern recognition by CNN possible?
Hi! Since "the record's stuck", I have found this as another rant without point, and djhbrown hasn't responded to my private request for staying on topic and friendly, I have taken the liberty to "cast the first stone" and enabled the moderation bit for djhbrown. I'll be happy to pass through any mail that could have an interesting insight, otherwise I invite those enjoying these reads to watch his blog and youtube channel. On Thu, Apr 21, 2016 at 11:52:01AM +1000, djhbrown . wrote: > Surely, someone, somewhere, has used, or tried to use, a CNN to label > groups in a Go game 361-pixellation? > > Q: what's the point of Go? > A: 361 > > (you would have thought someone else would have already thought of that one) > > Minsky and Papert threw a spanner into the works of the NN Magi of the > day, but whose grandchildren are now basking in the reflected glow of > their triumphal triumphant Man Who Would be King Apollo > Al(pha)exander who has conquered further far East than Kaffiristan - > Peace Be Upon Her prophet Kipling. > > The spanner was that the MPs found out that Perceptrons were Baron > Munchausen Walter Mittys who couldn't see the hole in a doughnut, > which meant that although they could learn to out-Pong space invaders, > they would become lost in a Pacman maze. As they did, as Dm hirelings > let slip out of the bag. > > Later, or before, depending on how you look at it, Backpropagators > claimed to have overcome this clog in their Jaquard's Loom in a Simple > Twist of Fate by claiming that Minsky was ancient history just as he > had claimed that they would so become [1], and now the new religion of > Stratified Convolutionism is claiming columnar accession to the throne > of AI, after Marchly breaking the back of the monster Orwellian > Goldstein gold standard Enemy of the Statespace, so it's just a few > weeks left to the Singularity, say the homeopathic snake-oil homology > self-promotional entrepreneurial salesmen. > > Sir Humphrey: "Everything is connected... who said that?" > Bernard: "The Cabinet Secretary?" > Sir H: "Nearly right; actually, it was Lenin" > > Norman Mailer once ranted that critics should be shot, but The Prince > Vespasian Flavius was cunninger, seeing the wisdom of his > Machiavelli-of-the-day Josephus that rather than claim to be the Sun > incarnate (as had his predecessors and as would his son's successors) > and attempt ViViVi by enfilade brute force, he could rule over the > southern desert troublemakers more easily and cheaply by spin > propaganda alone, simply by pretending he and his son Titus were the > earthly allegory of the heavenly born-again Messiah they yearned for > and put into that character's mouth the platitude that they should > render unto Caesar what is Caesar's, and love their enemies rather > than stone them. > > And it worked, for two thousand years, and is still going strong > despite a few seminal whacky leaks, just as Monty Python's Black > Adder Baldrick C(u)NN(ing) Plan has created a Reich that will last a > thousand years and upon which the sun will never set, so let us parrot > Hymn Number google in the Good Bok of Not the Nine O-Clock News [2] > and that other one: > > "it (symbolic reasoning) is an ex-parrot; it has ceased to be. Monty > is Great! I avow that there is no Go but Monty.". > > Apologies to those unfamiliar with the various historical allusions > that are variously common and uncommon knowledge among readers of A > History of the English-Speaking Peoples, to whom it will be somewhat > illusory without Googling the Gogglebox. which may cause the more > insecure among them to jump on the bandwagon of striking the first > blow and casting the first stone for the umpteenth time, anxious for > attention and the comfort blanket of communal hatred of any straw man > that stumbles across their blinkered monochrome landscape, so to > relieve the burden of thought, Sherpa the Sean suggests somewheres to > start: > > 1. http://www.webofstories.com/play/marvin.minsky/25 > > 2. https://www.youtube.com/watch?v=kqilW8OpeGc > > Only a Dostoyevskian Idiot-ic lone wolf apostate would dare leave the > quiet safety of the silent steppes to risk the monotonic ugly-mouthed > egg-throwing of self-righteous smug lion camp followers snug in their > schooled mutual hatred of anything or anyone with more melanin or a > different perspective than their straightjacket mindset. > > The record's stuck, the record's stuck. > ___ > Computer-go mailing list > Computer-go@computer-go.org > http://computer-go.org/mailman/listinfo/computer-go -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] AlphaGo Games Reviews?
Hi!
On Sat, Apr 16, 2016 at 10:26:06PM +1000, djhbrown . wrote:
> yes, it is an unusual configuration, deliberately so, because its
> emphasis is on the thought processes of the commentators rather than
> just the bland sequence of moves 1,2,3,4 etc; if you only want to see
> the main line, you can find it on gogameguru.com.
By the way, can anyone recommend good reviews of the games in
a different format than video? Dinerstain-style SGFs, GoWorld-style
texts, ...
There are some text reviews at gogameguru, but they are a bit too
terse (and tend to go through the game twice in the article, which is
hard for me to follow).
Thanks,
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Beginner question : how to choose a board representation
Hi!
On Sun, Apr 10, 2016 at 09:19:17AM +0200, Jean-Francois Romang wrote:
> Hello to everyone ; I'm a newcomer in this list and computer go programming.
> I have a chess programming background, but I want to start something new.
> :-)
> I'm currently in the early phases of developing GTP compatible go engine ;
> now it's time for me to choose a board representation : are there some
> articles or tips on this ?
I agree with the advice that it's not worth overthinking too much.
You will likely be interacting with your board through a set of methods
anyway, so you can always optimize the backend easily. For example,
some more optimized board representations use union-find chain
representation to be able to quickly join stone chains; but I'm not
sure if any of the higher level programs actually bothered to do it.
I'd also recommend that you do not overoptimize your board
representation for a simple Go engine - you may squeeze out a lot of
performance from your board representation, but then suddenly you
realize that for a more sophisticated Go-playing you also need to
quickly find out say the number of liberties of your group (or find
the actual liberties efficiently) - and at that moment, a lot of your
earlier tricks become quite worthless.
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] (no subject)
On Fri, Apr 01, 2016 at 07:08:34AM +0200, Robert Jasiek wrote:
> On 01.04.2016 02:22, djhbrown . wrote:
> >kogo is great for corner openings
>
> Kogo contains many mistakes. Too many kyus got their hands on it.
>
> It would be better to spend 3+ weeks using kombilo on GoGoD and create a new
> joseki tree. A summary of such an effort (with some interesting, additional,
> old variations) you find in Joseki 3 - Dictionary.
(If someone is lazy or has trouble setting up kombilo, a great and
extremely approachable way to try this online is http://ps.waltheri.net/ )
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] "English Explanations" based on Neural Networks
On Thu, Mar 31, 2016 at 08:51:30AM -0500, Jim O'Flaherty wrote:
> What I was addressing was more around what Robert Jasiek is describing in
> his joseki books and other materials he's produced. And it is exactly why I
> think the "explanation of the suggested moves" requires a much deeper
> baking into the participating ANN's (bottom up approach). And given what I
> have read thus far (including your above information), I am still seeing
> the risk extraordinarily high and the payoff exceedingly low, outside an
> academic context.
I think we may just have a different outcome in mind. To illustrate
where I think my approach could work, that could be for example
(slightly edited):
> White Q5 was played to compel Black to extend at the bottom.
> If Black doesn’t respond, White’s pincer at K4 will be powerful.
in https://gogameguru.com/lee-sedol-defeats-alphago-masterful-comeback-game-4/
Sure, it seems a bit outrageous, and for initial attempts, generating
utterances like
> White 126 was a very big move which helped to ensure White’s advantage.
is perhaps more realistic (though many of these sentences are a bit
of truisms and not terribly informative). But I'm quite convinced that
even the first example is completely plausible.
(But I'm *not* talking about generating pages of diagrams that
describe an opening position in detail. That's to ponder when we
get the simpler things right.)
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] "English Explanations" based on Neural Networks
On Wed, Mar 30, 2016 at 09:58:48AM -0500, Jim O'Flaherty wrote: > My own study says that we cannot top down include "English explanations" of > how the ANNs (Artificial Neural Networks, of which DCNN is just one type) > arrive a conclusions. I don't think that's obvious at all. My current avenue of research is using neural models for text comprehension (in particular https://github.com/brmson/dataset-sts) and the intersect with DCNNs is for example the work on automatic image captioning: http://cs.stanford.edu/people/karpathy/sfmltalk.pdf https://www.captionbot.ai/ (most recent example) One of my project ideas that I'm quite convinced could provide some interesting results would be training a neural network to caption Go positions based on game commentary. You strip the final "move selection" layer from the network and use the previous fully-connected layer output as rich "semantic representation" of the board and train another network to turn that into words (+ coordinate references etc). The challenges are getting a large+good dataset of commented positions, producing negative training samples, and representing sequences (or just coordinate points). But I think there's definitely a path forward possible here to train another neural network that provides explanations based on what the "move prediction" network sees. It could make a great undergraduate thesis or similar. (My original idea was simpler, a "smarter bluetable" chatbot that'd just generate "position-informed kibitz" - not necessarily *informative* kibitz. Plenty of data for that, probably. ;-) -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Nice graph
The thread is http://www.lifein19x19.com/forum/viewtopic.php?f=18=12922=201695 On Fri, Mar 25, 2016 at 09:16:07PM -0400, Brian Sheppard wrote: > Hmm, seems to imply a 1000-Elo edge over human 9p. But such a player would > literally never lose a game to a human. > > I take this as an example of the difficulty of extrapolating based on games > against computers. (and the slide seems to have a disclaimer to this effect, > if I am reading the text on the left hand side correctly). Computers have > structural similarities that exaggerates strength differences in head-to-head > comparisons. But against opponents that have different playing > characteristics, such as human 9p, then the strength distribution is > different. I agree. Well, computer vs. computer may be still (somewhat) fine as long as it's different programs. What I wrote in that thread: The word covered by the speaker's head is "self". Bot results in self-play are always(?) massively exaggerated. It's not uncommon to see a 75% self-play winrate in selfplay to translate to 52% winrate against a third-party reference opponent. c.f. fig 7&8 in http://pasky.or.cz/go/pachi-tr.pdf . Intuitively, I'd expect the effect to be less pronounced with very strong programs, but we don't know anything precise about the mechanics here and experiments are difficult. It's no doubt today's AlphaGo is much stronger than the Nature version. But how much? We'll have a better idea when they pit it in more matches with humans, and ideally when other programs catch up further. Without knowing more (like the rest of the slides or a statement by someone from Deepmind), I wouldn't personally read much into this graph. -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Congratulations to AlphaGo (Statistical significance of results)
Thank you, these are beautiful posts. I enjoyed very much reading a writeup by Go professional who also took the effort to understand the principles behind MCTS programs as well as develop a basic intution of the gameplay artifacts, strengths and weaknesses of MCTS. It also nicely describes the reason and consequences for Lee Sedol's different approaches during the match. I think these are really great posts for Go programmers to share with their Go-playing friends if they are curious about AlphaGo's strength and what went on in these games! On Tue, Mar 22, 2016 at 06:26:45PM -0400, Chun Sun wrote: > FYI. We have translated 3 posts by Li Zhe 6p into English. > > https://massgoblog.wordpress.com/2016/03/11/lee-sedols-strategy-and-alphagos-weakness/ > https://massgoblog.wordpress.com/2016/03/11/game-2-a-nobody-could-have-done-a-better-job-than-lee-sedol/ > https://massgoblog.wordpress.com/2016/03/15/before-game-5/ > > These may provide a slightly different perspective than many other pros. > > > On Tue, Mar 22, 2016 at 6:21 PM, Darren Cook <dar...@dcook.org> wrote: > > > > ... > > > Pro players who are not familiar with MCTS bot behavior will not see > > this. > > > > I stand by this: > > > > >> If you want to argue that "their opinion" was wrong because they don't > > >> understand the game at the level AlphaGo was playing at, then you can't > > >> use their opinion in a positive way either. > > > > Darren > > > > ___ > > Computer-go mailing list > > Computer-go@computer-go.org > > http://computer-go.org/mailman/listinfo/computer-go > > > _______ > Computer-go mailing list > Computer-go@computer-go.org > http://computer-go.org/mailman/listinfo/computer-go -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Congratulations to AlphaGo (Statistical significance of results)
On Tue, Mar 22, 2016 at 04:00:41PM +, Lucas, Simon M wrote: > With AlphaGo winning 4 games to 1, from a simplistic > stats point of view (with the prior assumption of a fair > coin toss) you'd not be able to claim much statistical > significance, yet most (me included) believe that > AlphaGo is a genuinely better Go player than Lee Sedol. > > From a stats viewpoint you can use this approach: > http://www.inference.phy.cam.ac.uk/itprnn/book.pdf > (see section 3.2 on page 51) > > but given even priors it won't tell you much. What complicates things further is that the coin distribution is non-stationary; definitely from the point of the human performance against a fixed program (how much AlphaGo with its novel RL component is fixed is of course another matter). In fact, as anyone watching bots playing on KGS knows, initially the non-stationarity is actually very extreme as the human gets "used to" the computer's style and soon are able to beat even a program that's formally quite stronger than the human player. At least that's the case for the weaker programs. I'm not sure if we can say with certainty that AlphaGo is significantly better Go player than Lee Sedol at this point. What we can say with certainty is that AlphaGo is in the same ballpark and at least roughly as strong as Lee Sedol. To me, that's enough to be really huge on its own accord! -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] UEC cup 1st day result
I think they are https://github.com/CGI-LAB http://www.aigames.nctu.edu.tw/ e.g. NiceGo, Amigo programs in the past. I'm curious if they are mainly reimplementing the AlphaGo paper or doing something else. On Sat, Mar 19, 2016 at 03:40:06PM +0100, "Ingo Althöfer" wrote: > Hello Hiroshi, > > thanks for the information. > > WHo are the peolbe behind CGI Go? > > Which hardware is used by the top participants in UEC cup? > > Ingo. > > > Gesendet: Samstag, 19. März 2016 um 14:32 Uhr > > Von: "Hiroshi Yamashita" <y...@bd.mbn.or.jp> > > An: computer-go@computer-go.org > > Betreff: [Computer-go] UEC cup 1st day result > > > > There are 32 participants, include one guest GNU GO. > > After 7 swiss round, > > > > 1st CGI7-0 > > 2nd CrazyStone 6-1 > > 3rd Zen6-1 > > 4th Aya6-1 > > 5th Gonanza5-2 > > 6th Ray5-2 > > 7th DolBaram 5-2 > > 8th darkforest 5-2 > > > > CrazyStone lost against Zen. > > Zen lost against CGI. > > DolBaram lost against Ray and CGI. > > darkforest lost against Zen and CrazyStone. > > > > Top 16 programs will play tommorow tournament. > > All top 8 prigrams except DolBaram? use DCNN. > > > > Thanks, > > Hiroshi Yamashita > > > > > > > > > > ___ > > Computer-go mailing list > > Computer-go@computer-go.org > > http://computer-go.org/mailman/listinfo/computer-go > ___ > Computer-go mailing list > Computer-go@computer-go.org > http://computer-go.org/mailman/listinfo/computer-go -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] Final score 4-1 - congratulations to AlphaGo team!
AlphaGo has won the final game, tenaciously catching up after a tesuji
mistake in the beginning - a great data point that it can also deal with
somewhat disadvantageous position well. It has received honorary 9p
from the KBA.
I can only quote David Silver: "Wow, what an amazing week this has
been." This is a huge leap for AI in general, maybe the most convincing
application demonstration of deep learning up to now.
(The take-away for me personally, even if obvious in retrospect, would
be not to focus on one field too much. I got similar ideas not long
after I actually stopped doing Computer Go and took a wide look at other
Machine Learning areas - well, three weeks later the Clark paper
came out. :) I came to believe that transferring ideas and models from
one field to another has one of the best effort / value tradeoffs, not
just personally but also for the scientific progress as a whole.)
I do hope that Aja will have time and be willing to answer some of our
technical questions now after taking a while to recover from what must
have been an exhausting week.
But now, onto getting pro Go players on our PCs, and applying this on
new things! :)
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] AlphaGo & DCNN: Handling long-range dependency
On Fri, Mar 11, 2016 at 09:33:52AM +0100, Robert Jasiek wrote:
> On 11.03.2016 08:24, Huazuo Gao wrote:
> >Points at the center of the board indeed depends on the full board, but
> >points near the edge does not.
>
> I have been wondering why AlphaGo could improve a lot between the Fan Hui
> and Lee Sedol matches incl. learning sente and showing greater signs of more
> global, more long-term planning. A rumour so far suggests to have used the
> time for more learning, but I'd be surprised if this should have sufficed.
My personal hypothesis so far is that it might - the REINFORCE might
scale amazingly well and just continuous application of it (or possibly
more frequent sampling to get more data points; once per game always
seemed quite conservative to me) could make AlphaGo amazingly strong.
We know that after 30mil. self-play games, the RL value network bumps
the strength by ~450 Elo, but what about after 300mil. self-play games?
(Possibly after training the RL policy further too.)
(My main clue for this was the comment that current AlphaGo self-play
games are already looking quite different from human games. Another
explanation for that might be that they found a way to replace the SL
policy with RL policy in the tree.)
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] AlphaGo won the second game!
In the press conference (https://youtu.be/l-GsfyVCBu0?t=5h40m00s), Lee Sedol said that while he saw some questionable moves by AlphaGo in the first game, he feels that the second game was a near-perfect play by AlphaGo and he did not feel ahead at any point of the game. On Thu, Mar 10, 2016 at 12:44:23PM +0200, Petri Pitkanen wrote: > This time I think game was tougher. Though too weak to judge. At the end > sacrifice a fistfull stones does puzzle me, but again way too weak to > analyze it. > > It seem Lee Sedol is lucky if he wins a game > > 2016-03-10 12:39 GMT+02:00 Petr Baudis <pa...@ucw.cz>: > > > On Wed, Mar 09, 2016 at 09:05:48PM -0800, David Fotland wrote: > > > I predicted Sedol would be shocked. I'm still routing for Sedol. From > > Scientific American interview... > > > > > > Schaeffer and Fotland still predict Sedol will win the match. “I think > > the pro will win,” Fotland says, “But I think the pro will be shocked at > > how strong the program is.” > > > > In that case it's time for Lee Sedol to start working hard on turning > > this match around, because AlphaGo won the second game too! :) > > > > Petr Baudis > > ___ > > Computer-go mailing list > > Computer-go@computer-go.org > > http://computer-go.org/mailman/listinfo/computer-go > ___ > Computer-go mailing list > Computer-go@computer-go.org > http://computer-go.org/mailman/listinfo/computer-go -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] AlphaGo won the second game!
On Wed, Mar 09, 2016 at 09:05:48PM -0800, David Fotland wrote:
> I predicted Sedol would be shocked. I'm still routing for Sedol. From
> Scientific American interview...
>
> Schaeffer and Fotland still predict Sedol will win the match. “I think the
> pro will win,” Fotland says, “But I think the pro will be shocked at how
> strong the program is.”
In that case it's time for Lee Sedol to start working hard on turning
this match around, because AlphaGo won the second game too! :)
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] AlphaGo won first game!
Hi!
On Wed, Mar 09, 2016 at 04:43:23PM +0900, Hiroshi Yamashita wrote:
> AlphaGo won 1st game against Lee Sedol!
Well, I have to eat my past words - of course, there are still four
games to go, but the first round does not look like a lucky win at all!
Huge congratulations to the AlphaGo team, you have done truly amazing
work, with potential to spearhead a lot of further advances in AI in
general! It does seem to me that you must have made a lot of progress
since the Nature paper though - is that impression correct?
Do you have some more surprising breakthroughs and techniques in store
for us, or was the progress mainly incremental, furthering the training
etc.?
By the way, there is a short snippet in the paper that maybe many
people overlooked (including me on the very first read!):
> We introduce a new technique that caches all moves from the search
> tree and then plays similar moves during rollouts; a generalisation of
> the last good reply heuristic. At every step of the tree traversal, the
> most probable action is inserted into a hash table, along with the
> 3 × 3 pattern context (colour, liberty and stone counts) around both the
> previous move and the current move. At each step of the rollout, the
> pattern context is matched against the hash table; if a match is found
> then the stored move is played with high probability.
This looks like it might overcome a lot of weaknesses re semeai etc.,
enabling the coveted (by me) information flow from tree to playouts, if
you made this to work well (it's similar to my "liberty maps" attempts,
which always failed though - I tried to encode a larger context, which
maybe wasn't good idea).
Would you say this improvement is important to AlphaGo's playing
strength (or its scaling), or merely a minor tweak?
Thanks,
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] CPU vs GPU
Also, reading more of that pull request, the guy benchmarking it had old nvidia driver version which came with about 50% performance hit. So I'm not sure what were the final numbers. (And whether current caffe version can actually match these numbers, since this pull request wasn't merged.) On Wed, Mar 02, 2016 at 12:29:41AM -0800, Chaz G. wrote: > Rémi, > > Nvidia launched the K20 GPU in late 2012. Since then, GPUs and their > convolution algorithms have improved considerably, while CPU performance > has been relatively stagnant. I would expect about a 10x improvement with > 2016 hardware. > > When it comes to training, it's the difference between running a job > overnight and running a job for the entire weekend. > > Best, > -Chaz > > On Tue, Mar 1, 2016 at 1:03 PM, Rémi Coulom <remi.cou...@free.fr> wrote: > > > How tremendous is it? On that page, I find this data: > > > > https://github.com/BVLC/caffe/pull/439 > > > > " > > These are setup details: > > > > * Desktop: CPU i7-4770 (Haswell), 3.5 GHz , DRAM - 16 GB; GPU K20. > > * Ubuntu 12.04; gcc 4.7.3; MKL 11.1. > > > > Test:: imagenet, 100 train iteration (batch = 256). > > > > * GPU: time= 260 sec / memory = 0.8 GB > > * CPU: time= 752 sec / memory = 3.5 GiB //Memory data is from system > >monitor. > > > > " > > > > This does not look so tremendous to me. What kind of speed difference do > > you get for Go networks? > > > > Rémi > > > > On 03/01/2016 06:19 PM, Petr Baudis wrote: > > > >> On Tue, Mar 01, 2016 at 09:14:39AM -0800, David Fotland wrote: > >> > >>> Very interesting, but it should also mention Aya. > >>> > >>> I'm working on this as well, but I haven’t bought any hardware yet. My > >>> goal is not to get 7 dan on expensive hardware, but to get as much > >>> strength > >>> as I can on standard PC hardware. I'll be looking at much smaller nets, > >>> that don’t need a GPU to run. I'll have to buy a GPU for training. > >>> > >> But I think most people who play Go are also fans of computer games that > >> often do use GPUs. :-) Of course, it's something totally different from > >> NVidia Keplers, but still the step up from a CPU is tremendous. > >> > >> Petr Baudis > >> ___ > >> Computer-go mailing list > >> Computer-go@computer-go.org > >> http://computer-go.org/mailman/listinfo/computer-go > >> > > > > ___ > > Computer-go mailing list > > Computer-go@computer-go.org > > http://computer-go.org/mailman/listinfo/computer-go > ___ > Computer-go mailing list > Computer-go@computer-go.org > http://computer-go.org/mailman/listinfo/computer-go -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Deep Zen - do we have a race now?
On Tue, Mar 01, 2016 at 02:51:03PM -0800, David Fotland wrote:
> > Also, if you are training on a GPU you can probably avoid a lot of
> > hassle if you expect to run it on a GPU as well. I don't know how other
> > NN implementations handle it, but the GPU-to-CPU conversion script that
> > comes with the Theano-based pylearn2 kit doesn't work very reliably.
> I'll keep it in mind. I'm using caffe, which has a compile-time flag, so I'm
> not sure it will work with GPU enabled on a machine without a GPU.
I'm not sure about Michael's specific problem, but in my experience,
there is no trouble at all transferring stuff between CPU and GPU - your
model is, after all, just the weight matrices. In Caffe, you should
be able to switch between GPU and CPU completely freely.
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Deep Zen - do we have a race now?
On Tue, Mar 01, 2016 at 09:14:39AM -0800, David Fotland wrote:
> Very interesting, but it should also mention Aya.
>
> I'm working on this as well, but I haven’t bought any hardware yet. My goal
> is not to get 7 dan on expensive hardware, but to get as much strength as I
> can on standard PC hardware. I'll be looking at much smaller nets, that
> don’t need a GPU to run. I'll have to buy a GPU for training.
But I think most people who play Go are also fans of computer games that
often do use GPUs. :-) Of course, it's something totally different from
NVidia Keplers, but still the step up from a CPU is tremendous.
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] longest 3x3 game
On Sun, Feb 21, 2016 at 09:00:54PM +0100, Petr Baudis wrote: > I'm wondering if there's some framework for studying combinatoric > aspects of games that are not only technically Go, but also actually > resemble real Go games played by competent players? > > This research doesn't touch my heart very deeply because it seems > that the astonishing numbers rise up only while exploiting "loopholes" > in the technical rules formulation rather than their intention - passing > while you still have moves that'd improve your score, putting > whole-board groups in self-atari instead of capturing enemy groups > in atari, etc. > > How would the results change if we approximated more realistic games > by introducing just the same basic restriction that we use in Monte > Carlo simulations - (i) filling your own true eye is invalid move, > (ii) do not pass if a move is avilable. Maybe a more formal way to express my concern: it should be easy to come up with (of course ugly or expensive to verify) rule modifications that would still allow >99.9% or more pro games to be valid, but invalidate games proving these results in just a few moves. Can we reach some results (re longest games, number of games, etc.) that don't have this property? -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] longest 3x3 game
Hi! On Sun, Feb 21, 2016 at 01:55:05PM -0500, John Tromp wrote: > > very interesting. Is it allowed for players > > to pass in between? Do these passes count like > > normal moves? > > Yes, passes are implied whenever two consecutively played stones > are of the same color. I'm wondering if there's some framework for studying combinatoric aspects of games that are not only technically Go, but also actually resemble real Go games played by competent players? This research doesn't touch my heart very deeply because it seems that the astonishing numbers rise up only while exploiting "loopholes" in the technical rules formulation rather than their intention - passing while you still have moves that'd improve your score, putting whole-board groups in self-atari instead of capturing enemy groups in atari, etc. How would the results change if we approximated more realistic games by introducing just the same basic restriction that we use in Monte Carlo simulations - (i) filling your own true eye is invalid move, (ii) do not pass if a move is avilable. Naybe on 3x3, the games could still end up potentially quite long, but perhaps more interesting. And is there some way to quantify how harmful that restriction is, besides the famous example of forcing a bulky five (and how much that one matters at least on small boards like 5x5)? How often do 3x3 positions arise in random games that require filling your own eye to win? > > > Found a 582 move 3x3 game... > > Can you give us sgf? > > I took the effort of trying to format the 582 game in a more insightful way. > I ended up with lines of positions that mostly add stones, only starting > a new line when a capture of more than 1 stone left at most 4 stones: > The result is attached. I think there is clearly > room for improvement, i.e. make this game much longer. This was quite instructive, thank you very much for that! -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] 57%
Hi! On Wed, Feb 03, 2016 at 10:24:51AM +0100, Robert Jasiek wrote: > AlphaGo is said to predict 57% of professionals' moves. How is this number > measured and from which sample? > > At some turns, there is only one correct move - at other turns, strong go > players would say that there are several valid supposedly correct moves. > This is one of the reasons why 100% cannot be the optimum but a smaller > percentage must be the best. > > Pro players, or players of the database sample (incl. real world 3d players > being 9d on KGS), make mistakes. A neural net learns from a sample and > therefore also learns the mistakes. This is the most important reason why > 100% cannot be the optimum but a smaller percentage must be the best. > > (Roughly) which percentage is optimal? Why? Is the optimum greater or > smaller than 57%? You are right about these questions. This is from the KGS dataset http://u-go.net/gamerecords/ that contains 7d+ games. Yes, optimum is very far below 100%; there was some discussion on this mailing list in the past about checking strong human performance on this dataset, but AFAIK nothing came out of that yet... My impression is that current neural networks seem to converge to about 60%. It would be interesting if humans can still do better. Another idea would be considering accuracy as a top N measure among selected moves, whether it has better discernive power for currently used models. -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Zen19X achieved stable KGS 7d
On Sun, Jan 31, 2016 at 10:16:25AM +0900, Hideki Kato wrote: > Petr Baudis: <20160130150502.gf12...@machine.or.cz>: > > Hi, > > > > it seems that Zen19X grabbed at KGS 7d and looks like it's gonna hold! > > > > > > http://www.gokgs.com/gameArchives.jsp?user=zen19x=2016=1=y > > > >It's fairly fast, but not terribly so, and while it's unfortunate most of > >the games are handicaps against low dans, there probably isn't any other > >way on KGS these days. > > > > Congratulations to the Zen team! Weren't AlphaGo announced pretty > >much at the same moment Zen19X started playing, this would be a really > >huge news, bumping the state-of-art by two KGS ranks; this was quite > >an unlucky timing for Zen... Still, a treat for KGS denizens. :-) > > Thanks Pasky, but the timing could be the worst :). It took > almost 4 years from 6d to 7d. One good thing is that Zen19X is > running on not a clsuter but just a dual-Xeon (2 x 12 core) > server. The kiblitz asked me about AlphaGo but that's all. > Their support for Zen is unchanged at all because, I guess, they > can't play with AlphaGo but Zen and either is strong enough for > them. There were more than 120 watchers on a game with an 8d. Yesterday, this Zen version has beaten Pavol Lisy 1p in a no komi game! It was a blitz game, but imho this was unthinkable until very recently anyway: http://www.lifein19x19.com/forum/viewtopic.php?p=198362#p198362 http://files.gokgs.com/games/2016/1/31/cheater-Zen19X.sgf These are great times for Computer Go. :) -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Mastering the Game of Go with Deep Neural Networks and Tree Search
Hi! On Mon, Feb 01, 2016 at 01:38:28PM +, Aja Huang wrote: > On Mon, Feb 1, 2016 at 11:38 AM, Petr Baudis <pa...@ucw.cz> wrote: > > > > That's right, but unless I've overlooked something, I didn't see Fan Hui > > create any complicated fight, there wasn't any semeai or complex > > life (besides the by-the-book oonadare). This, coupled with the > > fact that there is no new mechanism to deal with these (unless the value > > network has truly astonishing generalization capacity, but it just > > remembering common tsumego and joseki shapes is imho a simpler > > explanation), leads me to believe that it remains a weakness. > > > > If you check Myungwan Kim 9p's comments in the video, in the 4th game there > was a semeai that AlphaGo read out at top side. See the game at > > http://britgo.org/deepmind2016/summary (It's at ~1:33:00+ https://www.youtube.com/watch?v=NHRHUHW6HQE) Well, there was a potential semeai, but did AlphaGo read it out? I don't know, you probably do. :-) > Unfortunately before the Lee match I'm not allowed to answer some of the > interesting questions raised in this thread, or mention how strong is > AlphaGo now. But for now what I can say is that in the nature paper (about > 5 months ago) AlphaGo reached nearly 100% win rate against the latest > commercial versions of Crazy Stone and Zen, and AlphaGo still did well even > on 4 handicap stones, suggesting AlphaGo may do much better in tactical > situations than Crazy Stone and Zen. But CrazyStone and Zen are also pretty bad at semeai and tsumego, it's a bit of a self-play problem; when playing against MCTS programs, some mistakes aren't revealed. (I guess that you probably played tens of games against AlphaGo yourself, so you'll have a pretty good idea about its capabilities. I just can't imagine how will the value network count and pick liberties or tsumego sequence combinations; it might just have more memory capacity than we'd imagine.) > I understand you bet on Lee but I hope you will enjoy watching the match. :) I certainly will! And in my heart, maybe I root for AlphaGo too :) -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Mastering the Game of Go with Deep Neural Networks and Tree Search
On Mon, Feb 01, 2016 at 12:24:21PM +0100, Olivier Teytaud wrote:
> If AlphaGo had lost at least one game, I'd understand how people can have
> an upper bound on its level, but with 5-0 (except for Blitz) it's hard to
> have an upper bound on his level. After all, AlphaGo might just have played
> well enough for crushing Fan Hui, and a weak move while the position is
> still in favor of AlphaGo is not really a weak move (at least in a
> game-theoretic point of view...).
That's right, but unless I've overlooked something, I didn't see Fan Hui
create any complicated fight, there wasn't any semeai or complex
life (besides the by-the-book oonadare). This, coupled with the
fact that there is no new mechanism to deal with these (unless the value
network has truly astonishing generalization capacity, but it just
remembering common tsumego and joseki shapes is imho a simpler
explanation), leads me to believe that it remains a weakness.
Of course there are other possibilities, like AlphaGo always steering
the game in a calmer direction due to some emergent property. But
sometimes, you just have to go for the fight, don't you?
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Mastering the Game of Go with Deep Neural Networks and Tree Search
Hi! On Mon, Feb 01, 2016 at 09:19:56AM +, Darren Cook wrote: > > someone cracked Go right before that started. Then I'd have plenty of > > time to pick a new research topic." It looks like AlphaGo has > > provided. > > It seems [1] the smart money might be on Lee Sedol: > > 1. Ke Jie (world champ) – limited strength…but still amazing… Less than > 5% chance against Lee Sedol now. But as it can go stronger, who knows > its future… > 2. Mi Yuting (world champ) – appears to be a ‘chong-duan-shao-nian (kids > on the path to pros)’, ~high-level amateur. > 3, Li Jie (former national team player) – appears to be pro-level. one > of the games is almost perfect (for AlphaGo) > > > On the other hand, AlphaGo got its jump in level very quickly (*), so it > is hard to know if they just got lucky (i.e. with ideas things working > first time) or if there is still some significant tweaking possible in > these 5 months of extra development (October 2015 to March 2016). AlphaGo's achievement is impressive, but I'll bet on Lee Sedol any time if he gets some people to explain the weaknesses of computers and does some serious research. AlphaGo didn't seem to solve the fundamental reading problems of MCTS, just compensated with great intuition that can also remember things like corner life shapes. But if Lee Sedol gets the game to a confusing fight with a long semeai or multiple unusual life shapes, I'd say based on what I know on AlphaGo that it'll collapse just as current programs would. And, well, Lee Sedol is rather famous for his fighting style. :) Unless of course AlphaGo did achieve yet another fundamental breakthrough since October, but I suspect it'll be a long process yet. For the same reason, I think strong players that'd play against AlphaGo would "learn to beat it" just as you see with weaker players+bots on KGS. I wonder how AlphaGo would react to an unexpected deviation from a joseki that involves a corner semeai. > [1]: Comment by xli199 at > http://gooften.net/2016/01/28/the-future-is-here-a-professional-level-go-ai/ > > [2]: When did DeepMind start working on go? I suspect it might only > after have been after the video games project started to wound down, > which would've Feb 2015? If so, that is only 6-8 months (albeit with a > fairly large team). Remember the two first authors of the paper: * David Silver - his most cited paper is "Combining online and offline knowledge in UCT", the 2007 paper that introduced RAVE * Aja Huang - the author of Erica, among many other things So this isn't a blue sky research at all, and I think they had Go in crosshairs for most of the company's existence. I don't know the details of how DeepMind operates, but I'd imagine the company works on multiple things at once. :-) -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] AlphaGo MCTS & Reinforcement Learning?
On Sun, Jan 31, 2016 at 03:20:16PM +, Greg Schmidt wrote: > The articles I've read so far about AlphaGo mention both MCTS and > RL/Q-Learning. Since MCTS (and certainly UCT) keeps statistics on wins and > propagates that information up the tree, that in and of itself would seem to > constitute RL, so how does it make sense to have both? It seems redundant to > me. Any thoughts on that? I agree with Alvaro's suggestion. :-) But since the general notion is interesting and maybe worth re-iterating [1]: * MCTS can be concaptualized as *on-the fly machine learning* that uses RL to learn which actions are how good in the current context (or a wider class of contexts in case of AMAF). * AlphaGo uses machine learning also in a preparation stage where reinforcement learning is used to find values of actions in fuzzy defined contexts. This is then used as a prior for initializing the action values as they are "tuned on-the-fly" during actual MCTS game search. On context: in classic MCTS, the context is "this precise board position", we are trying to figure out the action (move) value for each context separately and independently. [2] However, this is pretty wasteful, so we also use localized contexts (based on B-T patterns for example, or trivial tactics like atari) in real engines as priors for these action values. The value network provides another way to map context to action move values, and can be thought of imho pretty accurately as a "smart cache" for the playout-computed action values. It's "smart" because ANNs are fuzzy computational engines that do not require a precisely matched board position but will learn things like "in contexts with this corner shape, this vital point move will have high action value". [1] BTW, there has been a good influx of new mailing list subscriptions in the last few days! [2] AMAF is then a common prefix context, but let's ignore it as AlphaGo doesn't use it. -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] Zen19X achieved stable KGS 7d
Hi, it seems that Zen19X grabbed at KGS 7d and looks like it's gonna hold! http://www.gokgs.com/gameArchives.jsp?user=zen19x=2016=1=y It's fairly fast, but not terribly so, and while it's unfortunate most of the games are handicaps against low dans, there probably isn't any other way on KGS these days. Congratulations to the Zen team! Weren't AlphaGo announced pretty much at the same moment Zen19X started playing, this would be a really huge news, bumping the state-of-art by two KGS ranks; this was quite an unlucky timing for Zen... Still, a treat for KGS denizens. :-) Is this a result of adding a DCNN move classifier to the Zen MCTS as another prior, or some other improvement? -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] Replicating AlphaGo results
Hi! Since I didn't say that yet, congratulations to DeepMind! (I guess I'm a bit disappointed that no really new ML models had to be invented for this though, I was wondering e.g. about capsule networks or training simple iterative evaluation subroutines (for semeai etc.) by NTM-based approaches. Just like everyone else, color me very awed by such an astonishing result with just what was presented.) On Wed, Jan 27, 2016 at 11:15:59PM -0800, David Fotland wrote: > Google’s breakthrough is just as impactful as the invention of MCTS. > Congratulations to the team. It’s a huge leap for computer go, but more > importantly it shows that DNN can be applied to many other difficult problems. > > I just added an answer. I don’t think anyone will try to exactly replicate > it, but a year from now there should be several strong programs using very > similar techniques, with similar strength. > > An interesting question is, who has integrated or is integrating a DNN into > their go program? I’m working on it. I know there are several others. > > David > > From: Computer-go [mailto:computer-go-boun...@computer-go.org] On Behalf Of > Jason Li > Sent: Wednesday, January 27, 2016 3:14 PM > To: computer-go@computer-go.org > Subject: Re: [Computer-go] Mastering the Game of Go with Deep Neural Networks > and Tree Search > > Congratulations to Aja! > > A question to the community. Is anyone going to replicate the experimental > results? > > https://www.quora.com/Is-anyone-replicating-the-experimental-results-of-the-human-level-Go-player-published-by-Google-Deepmind-in-Nature-in-January-2016? A perfect question, I think - what can we do to replicate this, without Google's computational power? I probably couldn't have resisted giving it a try myself (especially given that a lot of what I do nowadays are deep NNs, though on NLP), but thankfully I have two deadlines coming... ;-) I'd propose these as the major technical points to consider when bringing a Go program (or a new one) to an Alpha-Go analog: * Asynchronous integration of DNN evaluation with fast MCTS. I'm curious about this, as I thought this would be a much bigger problem that it apparently is, based on old results with batch parallelization. I guess virtual loss makes a lot of difference? Is 1 lost playout enough? I wonder if Detlef has already solved this sufficiently well in oakfoam? What's the typical lag of getting the GPU evaluation (in, I guess, #playouts) in oakfoam and is the throughput sufficient to score all expanded leaf nodes (what's the #visits?)? Sorry if this has been answered before. * Are RL Policy Networks essential? AIUI by quick reading, they are actually used only for RL of the value networks, and based on Fig. 4 the value network didn't use policy network for training on but still got quite stronger than zen/crazystone? Aside of extra work, this'd save us 50 GPU-days. (My intuition is that RL policy networks are the part that allows embedding knowledge about common tsumego/semeai situations in the value networks, because they probably have enough capacity to learn them. Does that make sense?) * Seems like the push for SL Policy Network prediction accuracy from 50% to 60% is really important for real-world strength (Fig. 2). I think right now the top open source solution has prediction accuracy 50%? IDK if there's any other factor (features, dataset size, training procedure) involved in this than "Updates were applied asynchronously on 50 GPUs using DistBelief 60; gradients older than 100 steps were discarded. Training took around 3 weeks for 340 million training steps." * Value Networks require (i) 30 million self-play games (!); (ii) 50 GPU-weeks to train the weights. This seems rather troublesome, even 1/10 of that is a bit problematic for individual programmers. It'd be interesting to see how much of that are diminishing returns and if a much smaller network on smaller data (+ some compromises like sampling the same game a few times, or adding the 8 million tygem corpus to the mix) could do something interesting too. In summary, seems to me that the big part of why this approach was so successful are the huge computational resources applied to this, which is of course an obstacle (except the big IT companies). I think the next main avenue of research is exploring solutions that are much less resource-hungry. The main problem here is hungry at training time, not play time. Well, the strength of this NN running on a normal single-GPU machine is another big question mark, of course. Petr Baudis ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Replicating AlphaGo results
On Thu, Jan 28, 2016 at 10:29:29AM -0600, Jim O'Flaherty wrote: > I think the first goal was and is to find a pathway that clearly works to > reach into the upper echelons of human strength, even if the first version > used a huge amount of resources. Once found, then the approach can be > explored for efficiencies from both directions, top down (take this away > and see what we lose, if anything) and bottom up (efficiently reoriginate a > reflection of a larger pattern in a much more constrained environment). > >From what I can see in the chess community, this is essentially what > happened following Deep Blue's win against Kasperov. And now their are > solutions on single desktops that can best what Deep Blue did with far more > computational resources. Certainly! Also, reflecting on what I just wrote, > On Thu, Jan 28, 2016 at 10:07 AM, Petr Baudis <pa...@ucw.cz> wrote: > > > > (I guess I'm a bit disappointed that no really new ML models had to be > > invented for this though, I was wondering e.g. about capsule networks or > > training simple iterative evaluation subroutines (for semeai etc.) by > > NTM-based approaches. Just like everyone else, color me very awed by > > such an astonishing result with just what was presented.) > > > > In summary, seems to me that the big part of why this approach was so > > successful are the huge computational resources applied to this, which > > is of course an obstacle (except the big IT companies). this is not meant at all as a criticism of AlphaGo, purely just a discussion point! Even if you have a lot of hardware, it's *hard* to make it add value, as anyone who tried to run MCTS on a cluster could testify - it's not just a matter of throwing it at the problem, and the challenges aren't just engineering-related either. So maybe I'd actually say that this was even understated in the paper - that AlphaGo uses an approach which scales so well with available computational power (at training time) compared to previous approaches. -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Number of Go positions computed at last
On Thu, Jan 21, 2016 at 11:18:25PM -0500, John Tromp wrote:
> It's been a long journey, and now it's finally complete!
>
> http://tromp.github.io/go/legal.html
>
> has all the juicy details...
Congratulations!
(Piece of trivia: Michal Koucky who collaborated on this research is
essentially in the same department where I was when I was working on
Pachi, and where most of Pachi tuning and testing happenned, but we
don't really know each other (I was already external when he joined).
And the department head is the 1985 Czech Go champion, though he
doesn't play Go anymore. And none of these facts are causally
connected in any way AFAIK!)
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Board evaluation using a convolutional neural network
Hi!
On Fri, Jan 15, 2016 at 04:54:18PM -0500, Álvaro Begué wrote:
> In their standard configuration, MCTS engines will sometimes let lots of
> groups die after they know the game is hopeless, or if they have a large
> advantage and they still see a guaranteed victory after the group dies.
> That's why I tried to configure Pachi to maximize score for this particular
> purpose. However, as I said, I couldn't get Pachi to really maximize score
> and play the games to the bitter end; in a good fraction of the games there
> were dead stones left on the board, and in some games the penultimate eye
> of a group was plugged for no good reason (probably because of some bug in
> determining if it's OK to pass).
Two ideas re Pachi:
(i) In uct/uct.c maximize_score section, try changing the
max_losing_komi from 30 to, say, 300.
(ii) Try to work out that if Pachi decides it's losing, the gameplay
is switched over to GNUGo to finish the game.
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Computer-go Digest, Vol 71, Issue 22
On Tue, Dec 29, 2015 at 08:59:52AM -0800, Michael Alford wrote:
> On 12/29/15 4:10 AM, amanda oregon wrote:
>
> >
> >You can reach the person managing the list at
> >computer-go-ow...@computer-go.org
> >
>
> Is veg no longer the manager?
He's the list owner and pays the bills for computer-go.org; I do most of
the day-to-day (well, month-to-month) administration and moderation.
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] CNN with 54% prediction on KGS 6d+ data
//data[size*size+size*j+k]=0.0;
> > }
> > else if (board->getColor(pos)==Go::WHITE)
> > {
> > //data[j*size+k]=0.0;
> > data[(4+libs)*size*size + size*j + k]=1.0;
> > }
> > else if
> > (board->getColor(Go::Position::xy2pos(j,k,size))==Go::EMPTY)
> > {
> > data[8*size*size + size*j + k]=1.0;
> > }
> > }
> > }
> > if (col==Go::WHITE) {
> > for (int j=0;j<size;j++)
> > for (int k=0;k<size;k++)
> > {//fprintf(stderr,"%d %d %d\n",i,j,k);
> > for (int l=0;l<caffe_test_net_input_dim;l++)
> > data[l*size*size+size*j+k]=0;
> > //fprintf(stderr,"%d %d %d\n",i,j,k);
> > int pos=Go::Position::xy2pos(j,k,size);
> > int libs=0;
> > if (board->inGroup(pos))
> > libs=board->getGroup(pos)->numRealLibs()-1;
> > if (libs>3) libs=3;
> > if (board->getColor(pos)==Go::BLACK)
> > {
> > data[(4+libs)*size*size + size*j + k]=1.0;
> > //data[size*size+size*j+k]=0.0;
> > }
> > else if (board->getColor(pos)==Go::WHITE)
> > {
> > //data[j*size+k]=0.0;
> > data[(0+libs)*size*size + size*j + k]=1.0;
> > }
> > else if (board->getColor(pos)==Go::EMPTY)
> > {
> > data[8*size*size + size*j + k]=1.0;
> > }
> > }
> > }
> > if (caffe_test_net_input_dim > 9) {
> > if (board->getLastMove().isNormal()) {
> > int j=Go::Position::pos2x(board->getLastMove().getPosition(),size);
> > int k=Go::Position::pos2y(board->getLastMove().getPosition(),size);
> > data[9*size*size+size*j+k]=1.0;
> > }
> > if (board->getSecondLastMove().isNormal()) {
> > int
> > j=Go::Position::pos2x(board->getSecondLastMove().getPosition(),size);
> > int
> > k=Go::Position::pos2y(board->getSecondLastMove().getPosition(),size);
> > data[10*size*size+size*j+k]=1.0;
> > }
> > if (board->getThirdLastMove().isNormal()) {
> > int
> > j=Go::Position::pos2x(board->getThirdLastMove().getPosition(),size);
> > int
> > k=Go::Position::pos2y(board->getThirdLastMove().getPosition(),size);
> > data[11*size*size+size*j+k]=1.0;
> > }
> > if (board->getForthLastMove().isNormal()) {
> > int
> > j=Go::Position::pos2x(board->getForthLastMove().getPosition(),size);
> > int
> > k=Go::Position::pos2y(board->getForthLastMove().getPosition(),size);
> > data[12*size*size+size*j+k]=1.0;
> > }
> > }
> >
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2.0.22 (GNU/Linux)
> >
> > iQIcBAEBAgAGBQJWZvOlAAoJEInWdHg+Znf4t8cP/2a9fE7rVb3Hz9wvdMkvVkFS
> > 4Y3AomVx8i56jexVyXuzKihfizVRM7x6lBiwjYBhj4Rm9UFWjj2ZvDzBGCm3Sy4I
> > SpG8D01VnzVR6iC1YTu3ecv9Wo4pTjc7NL5pAxiZDB0V7OTRklfZAYsX4mWyHygn
> > cr1pIb79/9QfBf/johmuutXJIwYfVG9ShR1+udbxs3aU3QDAbJJ4eTs8oj+NqFpg
> > JolEEEg3wY693e77SqbUbjxR3kSsysoz9h1nKnR/ZjHByqlwNvSz9ho9eU0rKhaK
> > GSQ22/c1VPIZhr24FYBbYNYweOzDtonLpuUFCPSnYVels3h/I/LlqV3MeDo6wuZ2
> > QCPp5+11o4JzvEt7A4zfJCtEOEH0W2/+IjRcIkAVOo65OV/pPsz2EjHehMU6PC6m
> > vXA/kPx0jqUm1qSb0qCgMq5ZvSqfpcCY7JOlkEwkDBS1fty9sU0hqst3zXR0KGtn
> > rFuoREmQYi/mkjZfS2Q4AHiZUDbDZUKzRegUA+gR/eKAmJsmWeTDEI9ZAXgxL0cB
> > p1HGBNDEUKGk+ruq0gIe5vYygyBcJV0BbbBnweDjeZnlG8vLUAVoMF6V/q3gkZb1
> > P61rfE4d9dohfGBsZ+UWltRyWMj09ieR2G2zCDpIXyxEuoV6CTAlLzDuhmqFa2ma
> > Fp3lK/uLhOucXwBtStdx
> > =E47K
> > -END PGP SIGNATURE-
> > ___
> > Computer-go mailing list
> > Computer-go@computer-go.org
> > http://computer-go.org/mailman/listinfo/computer-go
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] CNN with 54% prediction on KGS 6d+ data
Hi! Well, for this to be practical the entire playout would have to be executed on the GPU, with no round-trips to the CPU. That's what my email was aimed at. On Tue, Dec 08, 2015 at 04:37:05PM +, Josef Moudrik wrote: > Regarding full CNN playouts, I think that problem is that a playout is a > long serial process, given 200-300 moves a game. You need to construct > planes and transfer them to GPU for each move and read result back (at > least with current CNN implementations afaik), so my guess would be that > such playout would take time in order of seconds. So there seems to be a > tradeoff, CNN playouts are (probably much) better (at "playing better > games") than e.g. distribution playouts, but whether this is worth the > implied (probably much) lower height of the MC tree is a question. > > Maybe if you had really a lot of GPUs and very high thinking time, this > could be the way. > > Josef > > On Tue, Dec 8, 2015 at 5:17 PM Petr Baudis <pa...@ucw.cz> wrote: > > > Hi! > > > > In case someone is looking for a starting point to actually implement > > Go rules etc. on GPU, you may find useful: > > > > > > https://www.mail-archive.com/computer-go@computer-go.org/msg12485.html > > > > I wonder if you can easily integrate caffe GPU kernels in another GPU > > kernel like this? But without training, reimplementing the NN could be > > pretty straightforward. > > > > On Tue, Dec 08, 2015 at 04:53:14PM +0100, Michael Markefka wrote: > > > Hello Detlef, > > > > > > I've got a question regarding CNN-based Go engines I couldn't find > > > anything about on this list. As I've been following your posts here, I > > > thought you might be the right person to ask. > > > > > > Have you ever tried using the CNN for complete playouts? I know that > > > CNNs have been tried for move prediction, immediate scoring and move > > > generation to be used in an MC evaluator, but couldn't find anything > > > about CNN-based playouts. > > > > > > It might only be feasible to play out the CNN's first choice move for > > > evaluation purposes, but considering how well the performance of batch > > > sizes scales, especially on GPU-based CNN applications, it might be > > > possible to setup something like 10 candidate moves, 10 reply > > > candidate moves and then have the CNN play out the first choice move > > > for those 100 board positions until the end and then sum up scores > > > again for move evaluation (and/or possibly apply some other tried and > > > tested methods like minimax). Given that the number of 10 moves is > > > supposed to be illustrative rather than representative, other > > > configurations of depth and width in position generation and > > > evaluation would be possible. > > > > > > It feels like CNN can provide a very focused, high-quality width in > > > move generation, but it might also be possible to apply that quality > > > to depth of evaluation. > > > > > > Any thoughts to share? > > > > > > > > > All the best > > > > > > Michael > > > > > > On Tue, Dec 8, 2015 at 4:13 PM, Detlef Schmicker <d...@physik.de> wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA1 > > > > > > > > Hi, > > > > > > > > as somebody ask I will offer my actual CNN for testing. > > > > > > > > It has 54% prediction on KGS 6d+ data (which I thought would be state > > > > of the art when I started training, but it is not anymore:). > > > > > > > > it has: > > > > 1 > > > > 2 > > > > 3 > > > >> 4 libs playing color > > > > 1 > > > > 2 > > > > 3 > > > >> 4 libs opponent color > > > > Empty points > > > > last move > > > > second last move > > > > third last move > > > > forth last move > > > > > > > > input layers, and it is fully convolutional, so with just editing the > > > > golast19.prototxt file you can use it for 13x13 as well, as I did on > > > > last sunday. It was used in November tournament as well. > > > > > > > > You can find it > > > > http://physik.de/CNNlast.tar.gz > > > > > > > > > > > > > > > > If you try here some points I like to get discussion: > > > > > > > > - - it seems to me, that th
Re: [Computer-go] Facebook Go AI
On Sat, Dec 05, 2015 at 02:47:50PM +0100, Detlef Schmicker wrote:
> I understand the idea, that long term prediction might lead to a
> different optimum (but it should not lead to one with a higher one
> step prediction rate: it might result in a stronger player with the
> same prediction rate...)
I think the whole idea is that it should improve raw prediction rate
on unseen samples too. The motivation of the increased suprevision is
to improve the hidden representation in the network, making it more
suitable for longer-term tactical predictions and therefore "stronger"
and better encompassing the board situation. This should result in
better one-move predictions in a situation where the followup is also
important.
It sounds rather reasonable to me...?
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Facebook Go AI
On Tue, Nov 24, 2015 at 01:39:00PM +0100, Petr Baudis wrote:
> On Mon, Nov 23, 2015 at 10:00:27PM -0800, David Fotland wrote:
> > 1 kyu on KGS with no search is pretty impressive.
>
> But it doesn't correlate very well with the reported results against
> Pachi, it seems to me.
>
> ("Pachi 10k" should correspond to ~5s thinking time on 8-thread FX8350.)
>
> > Perhaps Darkforest2 is too slow.
>
> Darkfores2 should be just different parameters when training the
> network, according to the paper if I understood it right.
Never mind, darkfores2 is now on KGS and got a 3d rank, which totally
fits the reported results. Wow.
Very impressive - computers can now play "just by intuition" better
than most people who spend many years studying and playing the game.
(Noone can call this "brute force".)
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] 7x7 Go is weakly solved
On Mon, Nov 30, 2015 at 11:52:47AM +, Aja Huang wrote: > Hi Erik, > > On Mon, Nov 30, 2015 at 10:37 AM, Erik van der Werf < > erikvanderw...@gmail.com> wrote: > > > Hi Aja, > > > > This result seems consistent with earlier claimed human solutions for 7x7 > > dating back to 1989. So what exactly is new? Did he write a program that > > actually calculates the value? > > > > Did you mean 7x7 Go was weakly solved before? I think the question is whether it was exhaustively searched (can be mathematically proven / reproduced) or just (thoroughly) investigated by a human. Petr Baudis ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] [66,866 human-pachi games]
Hi!
Would anyone find these useful?
- Forwarded message from Jonathan Chetwynd -
I recently took pachi/peepo.com offline due to excessive use, mostly from
China.
a visualisation of the site statistics by country and player is here:
peepo.com/pics/oursin.svg
there are 66,866 human-pachi games in database,
if anyone has idea how to use, let me know.
~:"
I may update to Pachi 11.0 but this is dependent on new web server.
- End forwarded message -
There's probably no way to label the games by opponent strength, and
I don't know if these are necessarily complete games. But they are all
played against a fixed opponent, MCTS program.
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Facebook Go AI
On Mon, Nov 23, 2015 at 10:00:27PM -0800, David Fotland wrote:
> 1 kyu on KGS with no search is pretty impressive.
But it doesn't correlate very well with the reported results against
Pachi, it seems to me.
("Pachi 10k" should correspond to ~5s thinking time on 8-thread FX8350.)
> Perhaps Darkforest2 is too slow.
Darkfores2 should be just different parameters when training the
network, according to the paper if I understood it right.
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Facebook Go AI
The numbers look pretty impressive! So this DNN is as strong as
a full-fledged MCTS engine with non-trivial thinking time. The increased
supervision is a nice idea, but even barring that this seems like quite
a boost to the previously published results? Surprising that this is
just thanks to relatively simple tweaks to representations and removing
features... (Or is there anything important I missed?)
I'm not sure what's the implementation difference between darkfores1 and
darkfores2, it's a bit light on detail given how huge the winrate delta
is, isn't it? ("we fine-tuned the learning rate") Hopefully peer review
will help.
Do I understand it right that in the tree, they sort moves by their
probability estimate, keep only moves whose probability sum up to
0.8, prune the rest and use just plain UCT with no priors afterwards?
The result with +MCTS isn't at all convincing - it just shows that
MCTS helps strength, which isn't so surprising, but the extra thinking
time spent corresponds to about 10k->150k playouts increase in Pachi,
which may not be a good trade for +27/4.5/1.2% winrate increase.
On Mon, Nov 23, 2015 at 09:54:37AM +0100, Rémi Coulom wrote:
> It is darkforest, indeed:
>
> Title: Better Computer Go Player with Neural Network and Long-term
> Prediction
>
> Authors: Yuandong Tian, Yan Zhu
>
> Abstract:
> Competing with top human players in the ancient game of Go has been a
> long-term goal of artificial intelligence. Go's high branching factor makes
> traditional search techniques ineffective, even on leading-edge hardware,
> and Go's evaluation function could change drastically with one stone change.
> Recent works [Maddison et al. (2015); Clark & Storkey (2015)] show that
> search is not strictly necessary for machine Go players. A pure
> pattern-matching approach, based on a Deep Convolutional Neural Network
> (DCNN) that predicts the next move, can perform as well as Monte Carlo Tree
> Search (MCTS)-based open source Go engines such as Pachi [Baudis & Gailly
> (2012)] if its search budget is limited. We extend this idea in our bot
> named darkforest, which relies on a DCNN designed for long-term predictions.
> Darkforest substantially improves the win rate for pattern-matching
> approaches against MCTS-based approaches, even with looser search budgets.
> Against human players, darkforest achieves a stable 1d-2d level on KGS Go
> Server, estimated from free games against human players. This substantially
> improves the estimated rankings reported in Clark & Storkey (2015), where
> DCNN-based bots are estimated at 4k-5k level based on performance against
> other machine players. Adding MCTS to darkforest creates a much stronger
> player: with only 1000 rollouts, darkforest+MCTS beats pure darkforest 90%
> of the time; with 5000 rollouts, our best model plus MCTS beats Pachi with
> 10,000 rollouts 95.5% of the time.
>
> http://arxiv.org/abs/1511.06410
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Strong engine that maximizes score
Hi!
On Tue, Nov 17, 2015 at 07:05:34AM -0500, Álvaro Begué wrote:
> If anyone knows of a program that can actually use something like expected
> score in the UCT move selection formula, that's probably what I need. I
> might end up modifying Pachi to do this, but it sounds daunting.
That's already implemented - see the options described in uct/uct.c
under the heading "Node value result scaling".
This even is one of the things that happens when you enable
maximize_score, but the score takes just (at most) 0.01 of the value,
where 0.99 is depending on win/loss. You might try to see what happens
if, in addition to maximize_score, you also pass
val_scale=0.1
(instead of the default 0.01) or even larger value. Not sure what
effect on strength it might have.
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Standard Computer Go Datasets - Proposal
Hi!
On Fri, Nov 13, 2015 at 08:39:20AM +, Josef Moudrik wrote:
> There has been some debate in science about making the research more
> reproducible and open. Recently, I have been thinking about making a
> standard public fixed dataset of Go games, mainly to ease comparison of
> different methods, to make results more reproducible and maybe free the
> authors of the burden of composing a dataset. I think that the current
> practice can be improved a lot.
I think the current de facto standard dataset is GoGoD (some year, not
quite fixed). So I think it's useful to differentiate your proposal
against this dataset - what are the current problems and what will be
the advantage?
One advantage would be of course if the dataset is freely available.
But it's not clear how to achieve that, i.e. where to get a large
professional game collection without copyright protection.
> 2a) Size: My current view is that at least 2 sizes are necessary: small
> (1000-2000 games?) and large dataset (5-6 games).
What's the usecase for a small dataset?
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Standard Computer Go Datasets - Proposal
Hi!
On Fri, Nov 13, 2015 at 09:46:54AM +, Darren Cook wrote:
> (I did wonder about storing player ranks, e.g. if a given position has a
> move chosen by only a single 9p, and you can then extract each follow-up
> position, you could extract a game. But, IMHO, you cannot regenerate any
> particular game collection this way. If it is a concern, it can be
> solved by only using a random 80% of moves from games.)
Dropping player names and some positions is a nice idea - especially,
from a moral standpoint, if the collection includes a prominent notice
encouraging voluntary donations by the users to the source collection,
e.g. GoGoD.
(A technical notice: you want info about last + second-to-last move
in the position as that's a feature that's often used in patterns.
Plus, bridging over just a 1-3 moves seems pretty easy to do by brute
force. A better scheme might be to drop, say, a block of 20 moves
starting at move 40-80 at random.)
I think a good question is what other uses besides learning move
patterns do people envision.
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Komi 6.5/7.5
On Thu, Nov 05, 2015 at 09:03:38AM +0200, Petri Pitkanen wrote: > 2015-11-05 0:04 GMT+02:00 Hideki Kato <hideki_ka...@ybb.ne.jp>: > > > The correct komi value assuming both players are perfect. Or, black > > utilize his advantage (maybe in an early stage) perfectly. Actual > > players, even strong pros, are not perfect and cannot fully utilize > > their advantages. As a conclusion, white is favored. > > Let alone we do not have even sufficient understanding of perfect play to > say what is correct komi in absolute sense. Nor it is it even meaningful > concept. Correct komi is a komi that produces about 50/50 result. Obviously > komi that will result in 50/50 for professionals will probably favour white > in your average weekend tournaments. Just like in chess 1st move advantage > is clearly less meanigfull for weaker players than top professionals. I find the notion above really counterintuitive, personally. Do you have any statistical evidence for this? I.e. increasing portions of white wins in even games as the player rating decreases? Petr Baudis ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Komi 6.5/7.5
On Thu, Nov 05, 2015 at 02:42:20PM +0200, Petri Pitkanen wrote:
> I do doubt that there is sufficient data available on Go as it is not
> popular enough.
How much data is enough? The games from KGS alone ought to be in
millions, and even EGD must carry at least tens of thousands of serious
tournament games. A trend ought to be visible there, if you want to
substantiate that argument.
> But lets face it 7 points guaranteed profit is way easier
> to utilize than initiative.
But is it? I'm not that strong myself (EGF 2k) but I'm fine with
initiative. It depends on playing style as much as anything. But
others in this thread made my argument better.
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Understanding statistics for benchmarking
On Tue, Nov 03, 2015 at 09:46:00AM +0100, Rémi Coulom wrote: > The intervals given by gogui are the standard deviation, not the usual 95% > confidence intervals. > > For 95% confidence intervals, you have to multiply the standard deviation by > two. > > And you still have the 5% chance of not being inside the interval, so you > can still get the occasional non-overlapping intervals. > > Likelihood of superiority is an interesting statistical tool: > https://chessprogramming.wikispaces.com/LOS+Table > > For more advanced tools for deciding when to stop testing, there is SPRT: > http://www.open-chess.org/viewtopic.php?f=5=2477 > https://en.wikipedia.org/wiki/Sequential_probability_ratio_test An important corollary to this (noted on this list every few years) is that in the most naive scenario where your statistical test is just SD-based overlap after N games, you should fix your N number of games in advance and not rig it by terminating out of schedule. If you look at the progress of your playtesting often, you could spot a few moments where the intervals do not overlap, enve if in the long run they typically would. (The situation is a bit dire if you have limited computing resources. I admit that sometimes I didn't follow the above myself in less formal exploratory experiments, but at least I tried to look only "infrequently", e.g. single check every few hours, only at "round" numbers of playouts, etc. I hope it's not a grave sin.) -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] Facebook Go AI
Hi! Facebook is working on a Go AI too, now: https://www.facebook.com/Engineering/videos/10153621562717200/ https://code.facebook.com/posts/1478523512478471 http://www.wired.com/2015/11/facebook-is-aiming-its-ai-at-go-the-game-no-computer-can-crack/ The way it's presented triggers my hype alerts, but nevertheless: does anyone know any details about this? Most interestingly, how strong is it? -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Understanding and implementing RAVE
On Mon, Oct 26, 2015 at 11:36:51AM +0100, Urban Hafner wrote:
> With the help of Michi <https://github.com/pasky/michi> (thank you Petr!)
> I’m currently working on adding RAVE to my UCT tree search. Before I get
> too deep into it I’d like to make sure I actually understand it correctly.
> It would be great if you could have a quick look at my pseudo code (mostly
> stolen from michi).
>
> Give a Node with the fields
>
> * color
> * visits,
> * wins
> * amaf_visits
> * amaf_wins
>
> The tree is updated after a playout in the following way:
>
> We traverse the tree according to the moves played. visits gets incremented
> unconditionally, and wins gets incremented if the playout was a win for
> color. That is the same as UCT.
>
> Then we have a look at the children of the node and increment amaf_visits
> for the children if color of that particular (child) node was the first to
> play on that intersection in the playout. If the playout was also a win for
> the (child) node then we also increment amaf_wins.
Sounds right.
> Then we also need to change the formula to select then next node. I must
> admit I just copied the one from Michi (RAVE_EQUIV = 3500. Stolen from
> Michi):
>
> win_rate = wins / plays (assumes plays will never be 0)
> if amaf_plays == 0 {
> return win_rate
> } else {
> rave_winrate = amaf_wins / amaf_plays
> beta = amaf_plays / ( amaf_plays + plays + plays * amaf_plays /
> RAVE_EQUIV)
> return beta * rave_winrate + (1 - beta) * winrate
> }
>
> Obviously I’m not expecting anyone to actually check the formula, but it
> would be great if I could get a thumbs up (or down) on the general idea.
This RAVE formula has been derived by David Silver as follows
(miraculously hosted by Hiroshi-san):
http://www.yss-aya.com/rave.pdf
Also note that RAVE_EQUIV (q_{ur} * (1-q_{ur}) / b_r^2) varies widely
among programs, IIRC; 3500 might be on the higher end of the spectrum,
it makes the transition from AMAF to true winrate fairly slow. You
typically set the value by parameter tuning.
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Understanding and implementing RAVE
On Mon, Oct 26, 2015 at 04:51:39PM +, Gonçalo Mendes Ferreira wrote: > >I must admit that I don’t quite follow how you’ve implemented things, but > >then you seem to be further along than me as I haven’t even started with > >transposition tables. > > > >Urban > > > Well I took the liberty to steal and very crudely modify a MCTS diagram from > wikipedia: > > http://pwp.net.ipl.pt/alunos.isel/35393/mcts.png > > Maybe with images it is clearer. You seem to be using an acyclic graph with > pointers for the arcs. Ah. In Pachi, at one point I wanted to rewrite things this way to get awesome cache locality, but it was such a dull work that I gave up. :-) So I wanted to do it when I was writing this again in Michi, but this approach breaks encapsulation (you can't just pass around a node object reference, but need a (parent, coord) tuple) which makes the code a bit dense and clumsy, so I decided it's not very pedagogical to do it this way... > When you need to find transpositions, and free > malloc'd nodes because you're out of memory, I find my solution much more > practical because all the information for selecting what play to make is in > the current node. But Pachi is no small program so I'm sure I'm wrong > somewhere. To clarify, Pachi and Michi do not use transposition tables but a simple tree structure. Transpositions (and meaningfully explored transpositions at that) are relatively rare in Go, plus there are pitfalls when propagating updates, aren't there? OTOH having a fixed-size list of followups carries some overhead when the board is getting filled up. So I never bothered to do this; but I know that some other strong programs do use transposition tables. -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Understanding and implementing RAVE
On Mon, Oct 26, 2015 at 05:29:57PM +0100, Urban Hafner wrote: > On Mon, Oct 26, 2015 at 5:03 PM, Gonçalo Mendes Ferreira <go...@sapo.pt> > wrote: > > > I think we mean the same. So when black plays at a1 first we count it for > >> black everywhere but never for white. Correct? > >> > > The question is, if both black and white play a1 - because there were > > captures in the middle - whether both of them will update a1 in some of > > their nodes. I believe so. > > > I see. Yes, that is also an option. I’ve only checked Michi and it only > counts the first one. It’s possible that this is just out of performance > considerations, but it could also be argued that so many captures happen in > the playouts that the information at the end of the game (where captures > are more likely to happen) isn’t worth recording. I agree. It may be worthwhile to think a bit abstractly about what's our goal with the AMAF statistics - we want to notice plays that are important for winning and therefore should be prioritized to play right away. Should we prioritize a move that we otherwise get around to only under the stones? Also, if you step through a bunch of MC simulations, you may notice that often a large+strong group gets captured because of something silly and then totally unrelated moves appear in the freed up space. Playing under the stones is thus a strong indicator that we are in the "nonsense endgame" phase of MC. -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Playout speed... again
On Wed, Oct 14, 2015 at 06:00:56PM -0700, Dusty Leary wrote:
> The trick to avoid recursively counting liberties:
> Track the liberties for a group/chain using a simplified data structure
> that looks like struct ChainLibertyInfo { int liberty_count; int
> liberty_sum; int liberty_sum_squares; }
>
> The interesting thing about this data structure is that it's a Set which
> can answer the isInAtari() query and the getAtariPoint() query, without
> having to track a lot of data. But it doesn't support enumerating all the
> liberties.
This is a nice trick I once implemented too. But for any kind of
interesting tactical evaluation (which is an important ingredient for
a strong program), you end up needing to be able to enumerate at least
two liberties, ideally even three. Then, you can't use this trick.
In Pachi, I got inspired by GNUGo and track liberties only up to
N liberties (N=5 I think). Any group with more than N is regarded
as having N libs. This cuts off a lot of overhead, IIRC it helped
me a lot.
If you are doing probability distribution stuff, I think a popular
trick is first deciding whether you are going to look just in last move
neighborhood or tenuki; most of the time, your roll will go with the
last move neighborhood and you won't need to spend a lot of time going
through the whole board.
In general, you may simply want to look at how other programs do
things... There's plenty of fast open source stuff out there.
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Playout speed... again
Hi!
On Wed, Oct 14, 2015 at 11:27:27PM +0100, Gonçalo Mendes Ferreira wrote:
> Hi, I've been searching the mailing list archive but can't find an answer to
> this.
>
> What is currently the number of playouts per thread per second that the best
> programs can do, without using the GPU?
>
> I'm getting 2075 in light playouts and just 55 in heavy playouts. My heavy
> playouts use MoGo like patterns and are probability distributed, with
> liberty/capture counts/etc only updated when needed, so it should be pretty
> efficient.
>
> What would be a good ballpark for this?
What board size are we talking about?
...Pachi does roughly 2000 heavy playouts per second per thread on
19x19. It doesn't do it probability distribution style, which is though
just about 0.25 to 0.5 slowdown iirc. Profile your program to find
hotspots.
Maybe you are doing it in Python? Michi's heavy playouts (also not
probability distribution) are about 15 per second per thread on 13x13.
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Computer-go Digest, Vol 69, Issue 14
On Fri, Oct 09, 2015 at 12:22:36PM +0800, Cai Gengyang wrote:
> I just defeated Hirabot12(2d) by resignation. This bot is not very strong,
> prone to making huge calculation errors in life-and-death situations ..
Which bot isn't? :-)
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Goggernaut Russia+China vs The World stalled machine cycles
On Sat, Oct 03, 2015 at 08:48:57PM -0500, Jim O'Flaherty wrote:
> Finally, I'm not seeing how this particular post is related or connected to
> computer Go. But, I'm also somewhat hesitant to ask you to explain the
> connection, as I'm not willing to agree to read or watch what you might
> produce as a response.
I would like to encourage readers of djhbrown's posts who don't see
any actual contribution to computer go discussions in these posts
to ignore them, either by technical means or just not replying
to them.
As long as there are replies (of *any* kind), that demonstrates interest
(and consequently value) to both the original poster (encouraging
further posts) and moderators.
Kind regards,
Petr Baudis
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Building a Go AI Machine
On Sat, Sep 26, 2015 at 11:23:23PM +0800, Cai Gengyang wrote:
> So I am back and ready to get started with building a Go AI Machine. I am
> genuinely quite intrigued by the potential impact of AI on Go and also
> other applications ... Where / How do i start learning how to build this?
Haven't you already asked a month ago?
http://computer-go.org/pipermail/computer-go/2015-August/007794.html
If you are unsatisfied by the answers, perhaps continuing that thread
would be better.
On Sun, Sep 27, 2015 at 07:11:10PM +1000, djhbrown . wrote:
> Whichever route you try, you are unlikely to get anywhere non-trivial doing
> it on your own, unless you are a Mozart of the keyboard and had produced
> impressive programs by the age of 8 years old. After you reach the ripe
> old age of 19, your brain basically stops growing except for a few neurons
> in your neocortex to stop you doing thoughtless teenage things; apart from
> that, your learning curve is downhill from then on...
I believe most of the strong programs are actually works of programmers
working mostly alone.
(SCNR, even though these posts are getting more and more unpleasant.)
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Mental Imagery in Go - playlist
On Tue, Aug 04, 2015 at 10:33:30AM +1000, djhbrown . wrote: However, i have to admit that in 1979 i was a false prophet when i claimed the brute-force approach is a no-hoper for Go, even if computers become a hundred times more powerful than they are now [Brown, D and S. Dowsey, S. The Challenge of Go. *New Scientist* 81, 303-305, 1979.]. I think you are right, though. In my opinion, calling MCTS brute force isn't really fair, the brute force portion really doesn't work and you need to add a lot of smarts both to the simulations and to the way you pick situations to simulate to make things work. -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] EGC2015 Events / Proceedings of the International Go Game Science Conference 2015
Hi! On Tue, Jul 28, 2015 at 03:35:10PM +0200, remi.cou...@free.fr wrote: https://github.com/pasky/iggsc2015proc On Wed, Jul 29, 2015 at 08:21:00PM +0200, Petr Baudis wrote: There are several Computer Go events on EGC2015. Today, we have several IGGSC2015 events, all of them will be streamed over Youtube. Right now (already in progress, sorry for the link delay) the live stream from the science presentations: https://www.youtube.com/watch?v=8AZsWAV2org From 12:30, a match of Ingo's human-computer team (w/ CrazyStone) vs. a professional. From 15:00, some popular lectures. Please watch the EGC2015 youtube channel for live streams and recordings. -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] EGC2015 Events / Proceedings of the International Go Game Science Conference 2015
Hi! On Thu, Jul 30, 2015 at 10:44:36AM +0200, Petr Baudis wrote: From 12:30, a match of Ingo's human-computer team (w/ CrazyStone) vs. a professional. Unfortunately, the transmission of this event did not work out that well - we hoped to show mainly the CrazyStone screen with move rating, but couldn't make Ingo's notebook talk to our projector, despite positive tests from yesterday. We apologize! Petr Baudis ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] EGC2015 Events
Indeed. We (well, mainly I) thought that since Aya is running on a weaker computer, 5 stones might be about right, but now I'm a bit worried that I made the game too tough for white after all. Still, there's a big audience (surprised us a bit), maybe 150 people, and they seem to be enjoying it! On Wed, Jul 29, 2015 at 09:14:14PM +0200, Rémi Coulom wrote: Great! Thanks. 5 stones against Aya is brave. On 07/29/2015 08:21 PM, Petr Baudis wrote: Hi! There are several Computer Go events on EGC2015. There was a small tournament of programs, played out on identical hardware by each, won by Aya: https://www.gokgs.com/tournEntrants.jsp?sort=sid=981 Then, one of the games, Aya vs. Many Faces, was reviewed by Lukas Podpera 6d: https://www.youtube.com/watch?v=_3Lk1qVoiYM Right now, Hajin Lee 3p (known for her live commentaries on Youtube as Haylee) is playing Aya (giving 5 stones) and commenting live: https://www.youtube.com/watch?v=Ka2ilmu7Eo4 ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] EGC2015 Events
Hi! There are several Computer Go events on EGC2015. There was a small tournament of programs, played out on identical hardware by each, won by Aya: https://www.gokgs.com/tournEntrants.jsp?sort=sid=981 Then, one of the games, Aya vs. Many Faces, was reviewed by Lukas Podpera 6d: https://www.youtube.com/watch?v=_3Lk1qVoiYM Right now, Hajin Lee 3p (known for her live commentaries on Youtube as Haylee) is playing Aya (giving 5 stones) and commenting live: https://www.youtube.com/watch?v=Ka2ilmu7Eo4 -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Determining the final board state for finished games
On Sun, Jul 26, 2015 at 12:22:57AM -0400, David Fotland wrote:
In general this is beyond the state of the art of the strongest go programs.
You can’t score without determining the status of every group (live, dead,
seki), and you may need to identify required interior defensive moves that
have not been played.
While in general that's true, I think for practical concerns, this
paints a too gloomy picture.
In general, the algorithm (when using Chinese rules) is pretty simple:
A. Identify dead groups and remove them from the board.
B. For each continuous empty area, determine if it touches only stones
of a single color. In that case, color it that way.
C. Count number of intersections colored each way.
The trick is of course in the step A.
I'd be interested to hear if anyone tried and could measure+compare the
accuracy of the following approaches:
* Use gnugo --score {estimate,finish,aftermath} to determine the score
and group status.
* Use one of the Monte Carlo engines to run N hundred simulations from
the end position; if an intersection is colored by color X in =80%
of Monte Carlo final positions, declare it X's territory.
* Use Benson life algorithm and some simple heuristics to determine
life and death. (optional)
--
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] new kgsGtp client does not work for me, tournament soon....
) at org.igoweb.igoweb.client.gtp.c.a(kgsgtp:158) at org.igoweb.igoweb.client.gtp.al.a(kgsgtp:48) at org.igoweb.igoweb.client.gtp.am.a(kgsgtp:431) at org.igoweb.igoweb.client.gtp.aq.run(kgsgtp:298) at org.igoweb.igoweb.client.gtp.at.a(kgsgtp:18) at org.igoweb.igoweb.client.gtp.au.run(kgsgtp:97) at java.lang.Thread.run(Thread.java:745) java.lang.NullPointerException at com.gokgs.client.gtp.y.a(kgsgtp:22) at com.gokgs.client.gtp.z.a(kgsgtp:58) at org.igoweb.igoweb.client.gtp.aT.a(kgsgtp:107) at org.igoweb.igoweb.client.gtp.aM.b(kgsgtp:85) at org.igoweb.igoweb.client.gtp.aa.a(kgsgtp:246) at org.igoweb.igoweb.client.gtp.c.a(kgsgtp:398) at org.igoweb.igoweb.client.gtp.c.a(kgsgtp:378) at org.igoweb.igoweb.client.gtp.c.d(kgsgtp:368) at org.igoweb.igoweb.client.gtp.ad.a(kgsgtp:164) at org.igoweb.igoweb.client.gtp.c.a(kgsgtp:158) at org.igoweb.igoweb.client.gtp.al.a(kgsgtp:48) at org.igoweb.igoweb.client.gtp.am.a(kgsgtp:431) at org.igoweb.igoweb.client.gtp.aq.run(kgsgtp:298) at org.igoweb.igoweb.client.gtp.at.a(kgsgtp:18) at org.igoweb.igoweb.client.gtp.au.run(kgsgtp:97) at java.lang.Thread.run(Thread.java:745) IN: clear_board VII 25, 2015 9:58:49 DOP. com.gokgs.client.gtp.GtpClient d FINEST: Got successful response to command clear_board: = VII 25, 2015 9:58:49 DOP. com.gokgs.client.gtp.GtpClient d FINEST: Queued command sent to engine: komi 7.5 Joseki dictionary for board size 19 loaded. IN: komi 7.5 VII 25, 2015 9:58:49 DOP. com.gokgs.client.gtp.GtpClient d FINEST: Got successful response to command komi 7.5: = IN: kgs-time_settings canadian 3600 30 10 time_settings 3600 30/10*0 VII 25, 2015 9:58:49 DOP. com.gokgs.client.gtp.GtpClient d FINEST: Queued command sent to engine: kgs-time_settings canadian 3600 30 10 VII 25, 2015 9:58:49 DOP. com.gokgs.client.gtp.GtpClient d FINEST: Got successful response to command kgs-time_settings canadian 3600 30 10: = VII 25, 2015 9:58:49 DOP. com.gokgs.client.gtp.GtpClient e FINE: Normal disconnection from server. VII 25, 2015 9:59:00 DOP. com.gokgs.client.gtp.GtpClient main FINE: KGS GTP Client v3.5.20 starting up ... The exception happens in a different thread than bot/KGS communication as sometimes even a genmove (esp. a quick one) gets through, so the program ends up slowly playing on. I have found that the unknown channel warnings printed by kgsGtp are not fatal, so my workaround is to use kgsGtp-3.5.4 for now. What did others do? -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] EGC2015 Computer Go Tournament: Reminder
Hi! We have extended the registration deadline to July 20 - you still have a chance to participate! (http://pasky.or.cz/iggsc2015/compgo_spec.html) We'd also like to ask for some feedback - what would make the tournament more attractive for you to attend? We offer prize money, some reasonably nice hardware, the games will be played on KGS and we can arrange on-site operators for a limited number of developers who cannot attend in person. Unfortunately, only single (1) participant has registered so far... On Tue, Jun 16, 2015 at 12:07:17PM +0200, Petr Baudis wrote: On Mon, Jun 15, 2015 at 01:21:49PM +, Josef Moudrik wrote: The tournament will take place on 29th July 2015. The winner of the tournament will have a chance to play against a strong professional player In the evening. The programs will compete on equal hardware arranged by the organizer. We can guarantee a prize budget of 600 EUR. I would like to invite operator/bot teams to participate in the tournament! If you are interested, the full specification is available here: http://pasky.or.cz/iggsc2015/compgo_spec.html We'd also like to remind you that the registration deadline is as soon as July 4. (Officially, it is your responsibility to find an operator to run your program on-site if you don't attend in person. But we may be able to help in a limited number of cases, roughly on a first come, first served basis.) -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Strange GNU Go ladder behavior
Hi! I've observed the same thing when playtesting Pachi against GNUGo, since very long ago. If you look a few moves back, you will see GNUGo already taking progressively longer time as the ladder is played out. IMHO there's some crazy exptime backtrack that gets out of hand at some point. It'd be interesting to see if giving GNUGo some time limit helps. On Thu, Jun 18, 2015 at 03:45:18PM -0700, Peter Drake wrote: Nope, we're still getting these crashes with more memory in the system. It still looks like it's always GNU Go that's crashing, and it always happens some way into a ladder that Orego shouldn't really be playing out. On Thu, Jun 18, 2015 at 3:24 PM, Peter Drake dr...@lclark.edu wrote: I have no idea what GNU Go does for memory management, but that does offer up a possibility: maybe the machine in question (a Google Compute Engine instance) is running out of memory. I've been using the highcpu machine types; I'll try a standard one (which has more memory) and see if the same thing happens. On Thu, Jun 18, 2015 at 1:41 PM, uurtamo . uurt...@gmail.com wrote: What does it do for memory management? Is it ungracefully failing while evaluating the ladder itself due to ram issues? steve On Jun 18, 2015 12:15 PM, Peter Drake dr...@lclark.edu wrote: This list may not be able to help, but I'm running out of clues on this one. I'm trying to run an experiment playing Orego against GNU Go in many games. Some of the games don't end properly. As far as I can tell, here's what happens: 1) Orego plays out a losing ladder. (That needs to be fixed, but that's another problem.) 2) At some point in the ladder, GNU Go quietly dies without responding to the move request. Has anyone else encountered this? -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Computer Go Turnament at EGC 2015: Call for Participation
Hi! On Tue, Jun 16, 2015 at 11:11:01AM +0100, Aja Huang wrote: Thanks. I'll attend but I'll play Go myself rather than entering a Go program. :) It'll be great to meet you! (Just to clarify - the Computer Go tournament is on a Wednesday, which is a free day without official tournament game, so participants wouldn't miss that. However, of course there will some other things to do on that day like side tournaments or trips. :-) -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] CFP #2: Second International Go Game Science Conference, Liberec 2015
Hello! This is a reminder that the deadline for paper submission for the IGGSC 2015 at the European Go Congress is in two weeks. Call for Papers - Second International Go Game Science Conference = Liberec, Czech Republic, 29th-30th July 2015, as a part of EGC 2015 http://pasky.or.cz/iggsc2015/ :: iggsc2...@v.or.cz Web version of the CFP: http://pasky.or.cz/iggsc2015/cfp.html Overview The Second International Go Game Science Conference (IGGSC 2015) will present results in various fields related to board games, with the main focus being on the game of Go (Baduk, Weiqi). The conference hopes to bring together researchers, scientists and practitioners from diverse fields spanning from Artificial Intelligence and Mathematics, through History, to Pedagogy and Psychology of board games. Authors are encouraged to contribute to the conference by submitting scientific papers on their research results, projects and various studies. Topics -- Potential topics for submissions include, but are not limited to: * Computer Go and AI in Games; CGT – Combinatorial Game Theory * Science of Go Rules, Game Concepts and Situations * Psychology and Pedagogy of Go and other mind games * History and Culture of Go and other board games Publication --- Submitted papers are expected to contain at least 30% original work not published at other venues yet. The papers will be subject to anonymous peer review organized by the Program Committee (we aim to seek at least two reviews for each paper). Accepted papers will be published in hard copy conference proceedings (with ISBN) and online on the conference website as open access; authors are expected to sign a simple non-exclusive copyright licence permitting typesetting editing and such publication. Authors of Computer Science papers are also encouraged to submit their preprints to arXiv/CoRR. We also aim to send the accepted papers for indexing by the Web of Science if possible. Submission -- The Paper Submission Deadline is on May 18, 2015. Please submit papers by sending them to email address iggsc2...@v.or.cz (with subject IGGSC2015 Paper Submission). We expect the papers in a PDF format, written in English and including full bibliography. A LaTeX template is available, users of Word and other software are expected to at least roughly match the visual style. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] 25x25 experiment
Hi! On Mon, Apr 27, 2015 at 02:24:42PM +0200, Detlef Schmicker wrote: but I offer my trained DCNN http://physik.de/net.tgz it has about 44% prediction rate and uses only the position Thanks so much for sharing this! It's a little too raw for me personally to spend much time playing with it at this point (now I just hoped to try to pair it up with other opponents) but maybe others will make use of it. Petr Baudis ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] 25x25 experiment
On Sun, Apr 26, 2015 at 11:26:42PM +0200, Petr Baudis wrote: On Sun, Apr 26, 2015 at 12:17:01PM +0200, remi.cou...@free.fr wrote: Hi, I thought it might be fun to have a tournament on a very large board. It might also motivate research into more clever adaptive playouts. Maybe a KGS tournament? What do you think? That's a cool idea - even though I wonder if 39x39 is maybe too extreme (I guess the motivation is maximum size KGS allows). I think that actually, GNUGo could become stronger than even the top MCTS programs at some point when expanding the board size, but it's hard for me to estimate exactly when - if at 25x25 or at 49x49... I've let play Pachi (in the same configuration that ranks it as 2d on KGS, but with 15s/move) to play GNUGo for a few games on 25x25 just to see how it would go. I'm attaching three SGFs if anyone would like to take a look, Pachi never had trouble beating GNUGo. Couple of observations: (i) The speed is only about 60% playouts in the same time compared to 19x19. (ii) GNUGo needs to be recompiled to work on larger boards, modify the MAX_BOARD #define in engine/board.h. (Same with Pachi.) (iii) As-is, Pachi might get into stack overflow trouble if ran on larger boards than 25x25. (iv) 25x25 is the last board size where columns can be represented by single English alphabet letters. This is the reason for the GTP limitation, but might trigger other limitations in debug routines etc. (v) The very first game (not included), Pachi lost completely. I discovered that my max playout length was 600 moves; bumping that to 1200 made things boring again. (vi) Some typically fast operations take much longer on large boards, e.g. tree pruning (because much wider tree breadth; on 19x19 it's rarely more than 100ms but it can take seconds on 25x25 for some reason); this would actually make Pachi occassionally lose byoyomi periods by a second or two without a manual time allocation adjustment. And a conjencture: (vii) (Even) games against GNUGo still aren't interesting on 25x25. The same factors that might benefit GNUGo compared to MCTS programs should also benefit DNN players and the difference might be more visible because a DNN should be much stronger than GNUGo. I wonder if the oakfoam or any other effort on building an open source DNN implementation can already play standalone games and how well it works? -- 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 z3-0.sgf Description: application/go-sgf z4-0.sgf Description: application/go-sgf z5-0.sgf Description: application/go-sgf ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] 25x25 experiment
On Mon, Apr 27, 2015 at 12:35:05PM +0200, Detlef Schmicker wrote: I dont see a reason, why there should be any problems using it with DNN on 19x19 trained network. If a 25x25 will be sheduled, I will take part :) I'm sorry for being unclear! I actually meant DCNN as a standalone player, not part of MCTS. Is it possible to run oakfoam's DCNN implementation like that? (Have you measured its stength?) Thanks, Petr Baudis ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] How about a 39x39 tournament?
On Sun, Apr 26, 2015 at 12:17:01PM +0200, remi.cou...@free.fr wrote: Hi, I thought it might be fun to have a tournament on a very large board. It might also motivate research into more clever adaptive playouts. Maybe a KGS tournament? What do you think? That's a cool idea - even though I wonder if 39x39 is maybe too extreme (I guess the motivation is maximum size KGS allows). I think that actually, GNUGo could become stronger than even the top MCTS programs at some point when expanding the board size, but it's hard for me to estimate exactly when - if at 25x25 or at 49x49... Petr Baudis ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] What's a good playout speed?
Hi! On Tue, Apr 07, 2015 at 12:03:12PM +0200, Urban Hafner wrote: Now that I have a bit of time again, what would be a good starting point to improve upon UCT and light playouts? RAVE definitely comes to mind, as well as enhancing the playouts with heuristics like the MoGo 3x3 patterns. Well, my suggestions would be in the form of Michi (and its git history). ;-) there are any good papers on adding priors to the search tree (and where the underlying data is coming from)? I'm sure there must be, but I think I just don't know how to search for it. Basically, you can either do progressive widening / unpruning / bias. The terminology is rather confusing. In case of progressive bias, you can either initialize the winrate with N wins (positive bias) and M losses (negative bias) with N and M determined by various heuristics (Fuego, Pachi, Michi use this), or have (1-alpha)*winrate + alpha*bias with bias being a hypothetical winrate determined by the heuristics and alpha: 1 - 0 as #simulations: 0 - infty (e.g. alpha=sqrt(c/n) or some other random formula like that). I know about no good survey papers personally. On Tue, Apr 07, 2015 at 07:20:37PM +0900, Hideki Kato wrote: For prior values in the tree, almost(?) all strong programs use Remi's method these days. http://remi.coulom.free.fr/Amsterdam2007/MMGoPatterns.pdf Do you mean all the strong programs do progressive widening? -- 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@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
