Re: [computer-go] New engine? From a Chess programmer perspective.

> On Sun, 2 Dec 2007, Russell Wallace wrote: >> I haven't seen Leela before, but the claim of high dan-level >> performance on 9x9 is certainly interesting. > > I don't think 2200 ELO on the 9x9 CGOS is equivalent to 'high dan-level' > play. I was under the impression that MoGo (approx 2350 CGOS)

Re: [computer-go] New engine? From a Chess programmer perspective.

> Mogo is around 2500 on CGOS: > http://cgos.boardspace.net/9x9/cross/MoGo_psg7.html > This implies you believe the ratings didn't shift over time. http://computer-go.org/pipermail/computer-go/2007-October/011405.html http://cgos.boardspace.net/9x9/cross/MoGo_monothreadC.html http://cgos.boardsp

Re: [computer-go] How does MC do with ladders?

Jason House wrote: > MoGo uses TD to predict win rates. Really? Where did you get that information? -- GCP ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] How does MC do with ladders?

Jason House wrote: > The paper introduces RAVE and > near the end talks about using heuristics for initial parameter > estimation. The heuristic they used was based TD. Ah, you're talking about RLGO. RLGO was trained with TD, but MoGo itself doesn't use TD (directly). There are posts from Sylva

Re: [computer-go] CGOS 19 is stuck

Chris Fant wrote: CGOS 19 is has been stuck for a while now. At the bottom of the page, it says Many Faces is in a game, but does not show it as currently playing at the top of the page. Perhaps the problem is related to a bot leaving near the time a round is ending/beginning. I guess Oliver i

Re: [computer-go] low-hanging fruit - yose

Rémi Coulom wrote: In Crazy Stone (maybe that is the case of MoGo, too), nakade is such a big problem because the program avoids playing self-atari in playouts. Crazy Stone will play the self-ataris anyway, but with a low probability, so they are played at the end of the playout only. In case

Re: [computer-go] Please have your bot resign, for your own good

steve uurtamo wrote: It was my understanding that the netlag to the Philippines was about 380 ms; accounting for an additiaonal 15% packet loss and we end up at about 440 ms. i think that it works out to roughly double that because of the protocol, right? Yes, the server sends out the move an

Re: [computer-go] How to design the stronger playout policy?

Yamato wrote: I guess the current top programs have much better playout policy than the classical MoGo-style one. The original policy of MoGo was, (1) If the last move is an Atari, plays one saving move randomly. (2) If there are "interesting" moves in the 8 positions around the last move,

Re: [computer-go] How to design the stronger playout policy?

Yamato wrote: I finally improved my playouts by using Remi's ELO system to learn a set of "interesting" patterns, and just randomly fiddling with the probabilities (compressing/expanding) until something improved my program in self-play with about +25%. Not a very satisfying method or an exce

Re: [computer-go] handicap for mogo against pro ?

Don Dailey wrote: It's not very clear to me how strong Mogo is at 19x19. I have no idea. Can't we estimate from KGS games? You'd need to know exactly how fast the hardware is, of course. -- GCP ___ computer-go mailing list computer-go@computer-go

Re: [computer-go] handicap for mogo against pro ?

Olivier Teytaud wrote: Also, there are probably other people interested in combining UCT and mpi; I don't know if some people have a more precise idea of the level of the MPI+UCT combination than us. Someone ? MPI is just a parallel programming model/library, right? So the only thing to know

Re: [computer-go] handicap for mogo against pro ?

Michael Williams wrote: Gian-Carlo Pascutto wrote: Olivier Teytaud wrote: Also, there are probably other people interested in combining UCT and mpi; I don't know if some people have a more precise idea of the level of the MPI+UCT combination than us. Someone ? MPI is just a par

Re: [computer-go] handicap for mogo against pro ?

Don Dailey wrote: But with the type of scoring that MC does (where we optimize for winning percentage over score) it's more difficult to construct go problems. You have to construct them so that you LOSE the game if you don't play the "right" move, but if you do play it you win the game.

Re: [computer-go] handicap for mogo against pro ?

Hideki Kato wrote: No. Remember UCT is a sequential algorithm. Parallelizing UCT make playouts ineffective. Increasing the number of threads and/or communicating delay decreases the effectiveness of the playouts. With my experiments on a symmetrical threads implementation on a four core S

Re: [computer-go] handicap for mogo against pro ?

Hideki Kato wrote: What is "correct" move? It has sense only for some artificial problems or very limited positions, and so, it cannot evaluate total performance of a program. This is true, but we are interested in search performance. So, it makes sense to evaluate on those positions wher

Re: [computer-go] On average how many board updates/sec can top Go programs do these days?

> No wonder it plays so well at 9x9, because the max length of playout is > only > 81, it can 'see' what the board look like when the game ends. The *average* length of a 9x9 playout is roughly 100 moves. The max length is much larger. On a 2.2Ghz Athlon64, I get about 10 000 playouts/second, at

Re: [computer-go] On average how many board updates/sec can top Go programs do these days?

>> Playing randomly like that shouldn't work, but when you play Mogo et al, >> you see that intelligent behaviour emerges. >> > > Although interesting, I would hardly call that 'intelligence' :-) Ah, the traditional flamewar topic: the definition of intelligence shifts whenever a computer achieve

Re: [computer-go] On average how many board updates/sec can top Go programs do these days?

Harri Salakoski wrote: The *average* length of a 9x9 playout is roughly 100 moves. The max length is much larger. The *average* length of a 9x9 playout is roughly 100 moves. The max length is much larger. Hmm, sorry if this is old subject but does it effect much for playout quality if I cut pla

Re: [computer-go] On average how many board updates/sec can top Go programs do these days?

Rémi Coulom wrote: Gian-Carlo Pascutto wrote: > Multi-stone suicide is allowed, single stone not. Strange. The reverse would make more sense to me. I do not track liberties, so the speed penalty for doing it that way is too much. I wrote my program to track psuedoliberties because t

Re: [computer-go] On average how many board updates/sec can top Go programs do these days?

[EMAIL PROTECTED] wrote: > Um, by easier I mean faster. Also, I think single point suicide is more likely to lead to infinite loops, depending on your eye-filling rule. - Dave Hillis Yes. Particularly near the end of the game there are zillions of bad single stone suicides, but not often mul

Re: [computer-go] On average how many board updates/sec can top Go programs do these days?

Christoph Birk wrote: On Jan 15, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote: Um, by easier I mean faster. Also, I think single point suicide is more likely to lead to infinite loops, depending on your eye-filling rule. - Dave Hillis I don't understand why anyone would allow suicide in play

Re: [computer-go] Suicide question

> Gian-Carlo Pascutto wrote: > > > Multi-stone suicide is allowed, single stone not. > > I hadn't even considered suicide.(It would be a major change for me, > as neither my Gui nor my board system allow such moves.) > > The question is Why do you do it? > >

Re: [computer-go] Suicide question

terry mcintyre wrote: That key play might even have been discouraged by some pattern. MoGo probably does not allow self-ataris. If you do not allow self-atari you cannot see such a shape is dead. -- GCP ___ computer-go mailing list computer-go@com

Re: [computer-go] Suicide question

> I learned many things, thank you very much. > > I want to know one more thing. > If the GO rules standardized on one ruleset that forbid suicide, > At that time, do you still disscuss suicide and use it in game evaluation > ? Yes. What the rules allow has nothing to do with what you can do to ev

Re: [computer-go] Some thoughts about Monte Carlo

> So I wouldn't be surprised at all if at some point you'll see a > marriage of the best ideas of traditional Go programs and Monte- > Carlo / UCT. In fact, this is most likely already happening as these > Monte-Carlo programs use algorithms / ideas from the traditional > programs for tactics, pat

Re: [computer-go] Suicide question

John Fan wrote: If we are talking about real suicide, I do not see any point to allow the real suicide in the play out. What would be the gain if we allow the real suicide in the play out. The answer to this question has been given at least 3 times: Speed. It can take time to disallow a ce

Re: [computer-go] Some thoughts about Monte Carlo

Mark Boon wrote: On 18-jan-08, at 12:01, Gian-Carlo Pascutto wrote: But the speed of the random playout becoms less and less important with heavy playouts. This I don't understand at all. The improvement curve for being faster isn't different with heavy than with light playouts.

Re: [computer-go] Is MC-UCT really scalable against humans?

David Fotland wrote: This is an odd idea. When computers started beating people in chess, humans did not abandon the game and change to some other similar game. Why do you think go players would stop playing go when computers get strong? At some point human players playing computers started d

Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS study

Don Dailey wrote: If a nakade fixed version of mogo (that is truly scalable) was in the study, how much higher would it be in your estimation? You do realize that you are asking how much perfect life and death knowledge is worth? -- GCP ___ c

Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS study

Don Dailey wrote: I must not understand the problem. My program has no trouble with nakade unless you are talking about some special case position.My program immediately places the stone on the magic square to protect it's 2 eyes. Can your program identify sekis? Nice examples in att

Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS study

Don Dailey wrote: So I think this is nakade. Yes. Leela 0.2.x would get it wrong [1]. [1] Not eternally, but it would still take unreasonably long. -- GCP ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/l

Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS study

Gian-Carlo Pascutto wrote: Don Dailey wrote: So I think this is nakade. Yes. Leela 0.2.x would get it wrong [1]. [1] Not eternally, but it would still take unreasonably long. I was thinking of the 3 point version, not the 4 point version Don posted, of course. Oops! -- GCP

Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS study

Don Dailey wrote: Yes, the tree generates pass moves and with 2 passes the game is scored without play-outs. How do you detect dead groups after 2 passes? Static analysis? All is alive/CGOS? I can't believe mogo doesn't do this, it would be very weak if it didn't. That's just an assump

Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS study

Don Dailey wrote: I am concerned that the current study is, as Jacques has so ably described, a study of a restricted game where nakade and certain other moves are considered to be illegal; this restricted game approaches the game of Go, but the programs have certain blind spots which humans can

Re: [computer-go] Go rating math information

Don Dailey wrote: I don't know how David figures 1000 ELO, but I would expect the difference to be much larger than that for 19x19 go. I don't believe they are yet very close to 1 Dan. http://www.gokgs.com/graphPage.jsp?user=CrazyStone You're right. They're closer to 2 Dan. :) -- GCP

Re: [computer-go] Go knowledge and UCT

David Fotland wrote: So, can the strong 19x19 programs please tell us your playout rates? I expect the higher the rank, the fewer playouts per second. I'm not interested in 9x9 data, since I think much less go knowledge is needed to play 9x9. With your playout rate, please include the machine

Re: [computer-go] Go rating math information

Andy wrote: CrazyStone hasn't played since the initial spike to 1k in December. The movement of the chart afterwards is "rating drift". Ok. For me this is actually GOOD news :) -- GCP ___ computer-go mailing list computer-go@computer-go.org http:/

Re: [computer-go] Hybrid theory

Michael Williams wrote: So do I. I just stated a simpler version here because I previously suggested a more integrated approach and got zero replies. I'll state it again: Start with a UCT+MC engine. When a tree node reaches X number of playouts (1000?, 1?), do a tactical analysis. Wh

Re: [computer-go] Selecting tree child objects, was Hydra theory (was Hybrid theory)

Harri Salakoski wrote: Hi such question that do you typically traverse all child objects or is there faster way to select explored node child object. I have concluded that it is not at least easy as multiple nodes uct values change each simulation so trying to keep biggest uct value in first in

[computer-go] CGOS Deflation or Self-Play delusion?

I'm not sure what to think about the following: Leela 0.3.0 vs Leela 0.3.7, 455 game match 177 vs 278 => +78 ELO points for Leela 0.3.7 CGOS rating Leela_0.3.0_1CPU 2335 Leela_0.3.7_2CPU 2333 Hmm..but also Zen-0.9 2386 Zen-1.0 2385 or more: Uct-200801122348 Uct-200801132334

Re: [computer-go] More UCT / Monte-Carlo questions

Olivier Teytaud wrote: Basically, the formula in MoGo combines the success ratio and the RAVE-success ratio, with more focus on the success ratio when the number of simulations is large. You have no bias which favors exploration at all? -- GCP ___ c

RE: [computer-go] More UCT / Monte-Carlo questions (Effect of rave)

> I also implemented RAVE in Mango. There was a few points of improvements > (around 60 Elo points with gnugo as reference), but as much as in the > paper of Gelly and Silver :( (around 250 Elo points if I remember well) > > It might be that the effect of RAVE depends a lot on the simulation > stra

Re: [computer-go] More UCT / Monte-Carlo questions (Effect of rave)

Hideki Kato wrote: 4) Before back-propagating the value of each playout, I setup a color table for all intersections of the board for speed-up, in fact (initialized with EMPTY). That is, fill the board (table[move] = color) by tracing the moves and the colors returned by the playout forward (

Re: [computer-go] Fuego parameter question

Ben Lambrechts wrote: > If you really want to test MFOG against Fuego, it is better to run Fuego > on a strong Linux-machine. > The Cygwin-version is significantly slower than the full-build I have on > the same machine with Fedora. Isn't that just a matter of using a cygwin version with the same

[computer-go] kgsGtp problems

Hi all, I'm trying to connect Leela to KGS after a period of absence, but I'm running into the following error with kgsGtp 3.4.1: 8-feb-2010 22:30:41 org.igoweb.kgs.client.gtp.GtpClient d SEVERE: Unexpected disconnect: Error "No buffer space available (maximum connections reached?): connect" whil

Re: [Computer-go] How about a 39x39 tournament?

On 27-04-15 09:03, "Ingo Althöfer" wrote: > Some years ago, Gian-Carlo Pascutto had provided a large-board version of > Leela. For that he had introduced a "natural" extension of the sgf > board-coordinates. I just followed the official specification, which allow

Re: [Computer-go] Game Over

On 27/01/2016 18:58, Darren Cook wrote: > P.S. Curiously the BBC ran an article today on how Facebook is getting > close to top pro level too: http://www.bbc.co.uk/news/technology-35419141 http://googleresearch.blogspot.be/2016/01/alphago-mastering-ancient-game-of-go.html "The match was played be

Re: [Computer-go] Go Bot for the Browser?

On 16-03-16 22:17, Clark B. Wierda wrote: > I'm not familiar with emscripten, but there is a process that will > produce Javascript from Golang code that seems to be pretty robust. emscripten is extremely robust and will produce much faster (and hence stronger) results than a golang->JS transpil

Re: [Computer-go] Machine for Deep Neural Net training

On 27-04-16 17:45, David Fotland wrote: > I’d rather just buy another drive than spend time coding and > debugging another Caffe input layer to further compress the inputs. Caffe supports LevelDB as database layer, as an alternative to LMDB. It has built-in compression, enabled by default. -- G

Re: [Computer-go] Congratulations to Zen!

On 09-05-16 16:04, "Ingo Althöfer" wrote: > Another point for discussion: > Although there were only six participants they split in > at least 4 classes, seperated by large gaps in strength: > Zen >> abakus, HiraBot >> LeelaBot >> Imrsel, matilda > Perhaps it makes really sense to think about a tou

Re: [Computer-go] Congratulations to Zen!

On 9/05/2016 23:16, Erik van der Werf wrote: > Why not McMahon? (possibly with reduced handicap). It works fine in > human Go tournaments. http://senseis.xmp.net/?McMahon How does this work? That page doesn't mention handicaps. Indeed, the idea seems to be to eliminate large strength disparities

Re: [Computer-go] Congratulations to Zen!

On 10/05/2016 0:01, Erik van der Werf wrote: > Well then why not make that a criterion for entering the tournament? For > any half-decent bot it shouldn't be hard to get a rating. FWIW I requested ranked status for LeelaBot 3 weeks ago and this was not granted. Technically I'm not sure if this is

Re: [Computer-go] Rated Bot status on KGS

On 10-05-16 14:39, Adrian Petrescu wrote: > If KGS is indeed still doing that thing where your rating change is > anchored to your opponents' ratings changes long after your game has > finished, then it seems to me the right solution is for wms to simply > disable that anchoring for accounts that a

Re: [Computer-go] KGS bot tournaments: structure

On 10-05-16 11:23, Hideki Kato wrote: > CGOS is better place for those lower programs, isn't it? Not really, the pool of opponents is smaller and contains no humans. It sort of depends on what the goal of the author is. Even if she's only interested in measuring vs other computer opponents, a K

Re: [Computer-go] Congratulations to Zen!

On 10-05-16 00:14, Erik van der Werf wrote: > Oh that's silly! IIRC if your bot is not ranked than users can do all > kind of cheating in the scoring phase (e.g., mark all your living stones > dead). I've not observed this behavior so far. Perhaps because in an unranked game there's no rating to l

Re: [Computer-go] Congratulations to Zen!

On 10-05-16 16:20, Detlef Schmicker wrote: > OK, this thread is quite long, and I am not sure I saw all posts > :) > > My suggestion, rate the bots on CGOS before the tournament and > take this rating for McMahon or for handicaps. This doesn't work for the reason stated in the exact post you're r

Re: [Computer-go] Hajin Lee will play a live commented game against CrazyStone

On 22/05/2016 23:07, Álvaro Begué wrote: > Disclaimer: I haven't actually implemented MCTS with NNs, but I have > played around with both techniques. > > Would it make sense to artificially scale down the values before the > SoftMax is applied, so the probability distribution is not as > concentra

Re: [Computer-go] Selfplay Phenomena

On 23-05-16 13:57, "Ingo Althöfer" wrote: > Hi Gian-Carlo, > >> Unsurprisingly, self-play favors extreme selectivity, but this does not >> hold against other opponents. > > is this just your personal experience, or are there systematic experiments on > this? > Is it true "only" for MCTS (and vai

Re: [Computer-go] Commercial Go software and high-end users

On 29/05/2016 13:48, "Ingo Althöfer" wrote: > In particular, I use game playing software for the purpose of > analysis. It seems that the special (positive) role of the > "ChessBase" company in the Chess world is responsible for my opinion. > ChessBase was founded in 1985 by two guys: the program

Re: [Computer-go] Commercial Go software and high-end users

On 31/05/2016 20:45, David Ongaro wrote: > I suspect Aja is right and Remi should go the path of integrating the > GPU even if it's just to get more "oomph" for CS. That he tried to > learn GPU programming from scratch is a noble attempt but I guess > it's just to ambitious to accomplish in a reaso

Re: [Computer-go] Commercial Go software and high-end users

On 31-05-16 22:56, David Ongaro wrote: > Isn't e.g. TensorFlow Apache 2.0 license and would allow its > inclusion in commercial products? TensorFlow relies on CuDNN for good GPU performance. Almost all libraries do, because CuDNN is hand optimized by NVIDIA, and hence rather hard to beat. (Except

Re: [Computer-go] Commercial Go software and high-end users

On 2/06/2016 0:21, David Ongaro wrote: >> Note that the cuDNN license allows you to install and use as many >> copies of the software as you need, for both individual and >> corporate use. This intentionally permissive license is designed >> to allow cuDNN to be useful in conjunction with open-so

[Computer-go] Leela 0.6.2, OpenCL support, including GTP engines

Hi all, I've done a major update of Leela, including integration of DCNN, and optional usage of OpenCL to speed things up via the GPU. https://sjeng.org/leela.html I put a GTP commandline executable on the page. I hope the other people developing engines find this useful - I found the dearth of

Re: [Computer-go] Leela 0.6.2, OpenCL support, including GTP engines

On 5/06/2016 5:36, "Ingo Althöfer" wrote: > For all who do not know: LeelaBot is active on KGS, > with a very stable 3-dan rating: > http://www.gokgs.com/gameArchives.jsp?user=leelabot For what it's worth, the 3d was established by an older version that played the KGS tournament last month. The ne

Re: [Computer-go] DarkForest is open-source now.

On 10/06/2016 19:57, Darren Cook wrote: > 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 pla

Re: [Computer-go] Congratulations to Zen!

On 17/07/2016 17:03, Xavier Combelle wrote: > It seems that on my firefox 47.0.1 some html entities are rendered for > example komi 7&freac12; but with the 9times;9 tournament still running, Renders correctly here and also with a clean Firefox profile, so the problem is likely either your addons/

Re: [Computer-go] Converging to 57%

On 23-08-16 08:57, Detlef Schmicker wrote: > So, if somebody is sure, it is measured against GoGod, I think a > number of other go programmers have to think again. I heard them > reaching 51% (e. g. posts by Hiroshi in this list) I trained a 128 x 14 network for Leela 0.7.0 and this gets 51.1%

Re: [Computer-go] Converging to 57%

On 23/08/2016 11:26, Brian Sheppard wrote: > The learning rate seems much too high. My experience (which is from > backgammon rather than Go, among other caveats) is that you need tiny > learning rates. Tiny, as in 1/TrainingSetSize. I think that's overkill, as in you effectively end up doing batc

Re: [Computer-go] Congratulations to AyaMC!

On 7/09/2016 21:21, Nick Wedd wrote: > Congratulations to AyaMC, undefeated winner of the September slow KGS > bot tournament, which ended earlier today! > > My report is at http://www.weddslist.com/kgs/past/S16.2/index.html > As usual, I will welcome your comments and corrections. Given that Lee

Re: [Computer-go] DarkForest policy network training code is open-source now.

On 04-10-16 23:47, Yuandong Tian wrote: > Hi all, > > DarkForest training code is open source now. Hopefully it will help the > community. > > https://github.com/facebookresearch/darkforestGo > > > With 4 GPUs, the training procedure gives 56.1

Re: [Computer-go] Time policy

On 04-11-16 04:45, Billy White wrote: > Hi, > > Our team is working on a computer go system mainly followed alphago. > We try to add time policy to our system but cannot find something > useful. > > I am wondering whether there are some useful material? Take a large games database, and construct

Re: [Computer-go] Aya reaches pro level on GoQuest 9x9 and 13x13

On 17/11/2016 22:38, Hiroshi Yamashita wrote: > Features are 49 channels. > http://computer-go.org/pipermail/computer-go/2016-February/008606.html ... > Value Net is 32 Filters, 14 Layers. > 32 5x5 x1, 32 3x3 x11, 32 1x1 x1, fully connect 256, fully connect tanh 1 > Features are 50 channels. > http

Re: [Computer-go] Aya reaches pro level on GoQuest 9x9 and 13x13

On 20-11-16 11:16, Detlef Schmicker wrote: > Hi Hiroshi, > >> Now I'm making 13x13 selfplay games like AlphaGo paper. 1. make a >> position by Policy(SL) probability from initial position. 2. play a >> move uniformly at random from available moves. 3. play left moves >> by Policy(RL) to the end. (

Re: [Computer-go] Aya reaches pro level on GoQuest 9x9 and 13x13

On 17-11-16 22:38, Hiroshi Yamashita wrote: > Value Net is 32 Filters, 14 Layers. > 32 5x5 x1, 32 3x3 x11, 32 1x1 x1, fully connect 256, fully connect tanh 1 I think this should be: 32 5x5 x1, 32 3x3 x11, 1 1x1 x1, fully connect 256, fully connect tanh 1 Else one has a 361 * 32 * 256 layer with 3

Re: [Computer-go] GTX 1080 benchmark

On 15/12/2016 12:35, Hiroshi Yamashita wrote: > F32F128F256MNIST > GTX 1080 0.48ms 1.45ms 2.38ms 17sec, CUDA 8.0, cuDNN v5.0, Core i7 > 980X 3.3GHz 6core > GTX 1080 0.87ms 1.79ms 2.65ms 19sec, CUDA 8.0, cuDNN v5.1, Core i7 > 980X 3.3GHz 6core > GTX 980 0.60ms 1.51

Re: [Computer-go] Golois5 is KGS 4d

On 10-01-17 15:05, Hiroshi Yamashita wrote: > Hi, > > Golois5 is KGS 4d. > I think it is a first bot that gets 4d by using DCNN without search. I found this paper: https://openreview.net/pdf?id=Bk67W4Yxl They are using residual layers in the DCNN. -- GCP __

Re: [Computer-go] Training the value network (a possibly more efficient approach)

On 11-01-17 14:33, Kensuke Matsuzaki wrote: > Hi, > > I couldn't get positive experiment results on Ray. > > Rn's network structure of V and W are similar and share parameters, > but only final convolutional layer are different. > I trained Rn's network to minimize MSE of V(s) + W(s). > It uses

Re: [Computer-go] Training the value network (a possibly more efficient approach)

On 10-01-17 23:25, Bo Peng wrote: > Hi everyone. It occurs to me there might be a more efficient method to > train the value network directly (without using the policy network). > > You are welcome to check my > method: http://withablink.com/GoValueFunction.pdf > For Method 1 you state: "Howeve

Re: [Computer-go] Computer-go - Simultaneous policy and value functions reinforcement learning by MCTS-TD-Lambda ?

Patrick, for what it's worth, I think almost no-one will have seen your email because laposte.net claims it's forged. Either your or laposte.net's email server is mis-configured. > Refering to Silver's paper terminology and results, greedy policy > using RL Policy Network beated greedy policy usi

Re: [Computer-go] Training the value network (a possibly more efficient approach)

On 11-01-17 18:09, Xavier Combelle wrote: > Of course it means distribute at least the binary so, or the source, > so proprietary software could be reluctant to share it. But for free > software there should not any problem. If someone is interested by my > proposition, I would be pleased to realiz

Re: [Computer-go] Messages classified as spam.

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. It's been a while since I looked at this in depth, but the problem seems to be t

Re: [Computer-go] AlphaGo rollout nakade patterns?

On 23-01-17 20:10, Brian Sheppard via Computer-go wrote: > only captures of up to 9 stones can be nakade. I don't really understand this. http://senseis.xmp.net/?StraightThree Both constructing this shape and playing the vital point are not captures. How can you detect the nakade (and play at a

Re: [Computer-go] AlphaGo rollout nakade patterns?

On 31-01-17 16:32, Roel van Engelen wrote: > @Brain Sheppard > Thanks that is a really useful explanation! > the way you state: "and therefore a 8192-sized pattern set will identify > all potential nakade." seems to indicate this is a known pattern set? > could i find some more information on it s

Re: [Computer-go] Playout policy optimization

On 12/02/2017 5:44, Álvaro Begué wrote: > I thought about this for about an hour this morning, and this is what I > came up with. You could make a database of positions with a label > indicating the result (perhaps from real games, perhaps similarly to how > AlphaGo trained their value network). L

Re: [Computer-go] Leela Superstar!

On 19-02-17 17:00, "Ingo Althöfer" wrote: > Hi, > the rank graph of LeelaX on KGS looks impressive: > > http://www.dgob.de/yabbse/index.php?action=dlattach;topic=6048.0;attach=5658;image > > Of course, its shape will be more "gnubbled" after a few days. Thank you for the kind words, it is apprec

Re: [Computer-go] Leela Superstar!

On 21-02-17 16:27, Aja Huang via Computer-go wrote: > Congrats for Leela's significant improvements. :) Thank you. When I said I was "in good company" by not having registered for the UEC Cup, I was actually referring to you (AlphaGo), BTW. I feel that maybe Ingo may have misunderstood me there

Re: [Computer-go] UEC wild cards?

On 21/02/2017 16:11, "Ingo Althöfer" wrote: > Dear UEC organizers, > > GCP wrote (on behalf of Leela): >> I did not register for the UEC Cup. I seem to be in good company there, >> sadly. > > do you have a few wild cards for strong late entries? Posting on behalf of the UEC organizers: Yes, and

Re: [Computer-go] New AMD processors

On 03-03-17 21:29, "Ingo Althöfer" wrote: > Hi, > > AMD has published a new (fast and cool) processor, the Ryzen. > Did some go programmers already collect experiences with it? > Do they combine well with GPUs? I'm not getting one until there are mainboard reviews out, because there seem to be ea

[Computer-go] AMD Ryzen benchmarks for Go

Linux 4.10.1 (has SMT scheduler fix) GCC 5.4 - so no Ryzen optimizations pachi-git-13115394 Intel Haswell t=8 13325 g/s t=1 1665 g/s @3.6GHz t=49352 g/s t=1 2338 g/s @3.6GHz t=12542 g/s@3.8GHz AMD Ryzen t=16 26589 g/s t=1 1661 g/s @3.7GHz t=8 15464 g/s t=1 1933

Re: [Computer-go] Zen lost to Mi Yu Ting

On 21/03/2017 21:08, David Ongaro wrote: >> But how would you fix it? Isn't that you'd need to retrain your value >> network from the scratch? > > I would think so as well. But I some months ago I already made a > proposal in this list to mitigate that problem: instead of training a > different va

Re: [Computer-go] Zen lost to Mi Yu Ting

On 22-03-17 00:36, cazen...@ai.univ-paris8.fr wrote: > > Why can't you reuse the same self played games but score them If you have self-play games that are played to the final position so scoring is fool-proof, then it could work. But I think things get really interesting when timing of a pass ma

Re: [Computer-go] Zen lost to Mi Yu Ting

On 22-03-17 09:41, Darren Cook wrote: >> The issue with Japanese rules is easily solved by refusing to play >> under ridiculous rules. Yes, I do have strong opinions. :) > > And the problem with driver-less cars is easily "solved" by banning > all road users that are not also driver-less cars (inc

Re: [Computer-go] Zen lost to Mi Yu Ting

On 22-03-17 16:27, Darren Cook wrote: > (Japanese rules are not *that* hard. IIRC, Many Faces, and all other > programs, including my own, scored in them There is a huge difference between doing some variation of territory scoring and implementing Japanese rules. Understanding this difference will

Re: [Computer-go] Patterns and bad shape

On 17-04-17 15:04, David Wu wrote: > If you want an example of this actually mattering, here's example where > Leela makes a big mistake in a game that I think is due to this kind of > issue. Ladders have specific treatment in the engine (which also has both known limitations and actual bugs in 0

Re: [Computer-go] mini-max with Policy and Value network

On 20/05/2017 22:26, Brian Sheppard via Computer-go wrote: > Could use late-move reductions to eliminate the hard pruning. Given > the accuracy rate of the policy network, I would guess that even move > 2 should be reduced. > The question I always ask is: what's the real difference between MCTS w

Re: [Computer-go] mini-max with Policy and Value network

On 22-05-17 11:27, Erik van der Werf wrote: > On Mon, May 22, 2017 at 10:08 AM, Gian-Carlo Pascutto <mailto:g...@sjeng.org>> wrote: > > ... This heavy pruning > by the policy network OTOH seems to be an issue for me. My program has > big tactical holes. &g

Re: [Computer-go] mini-max with Policy and Value network

On 22-05-17 14:48, Brian Sheppard via Computer-go wrote: > My reaction was "well, if you are using alpha-beta, then at least use > LMR rather than hard pruning." Your reaction is "don't use > alpha-beta", and you would know better than anyone! There's 2 aspects to my answer: 1) Unless you've mad

Re: [Computer-go] mini-max with Policy and Value network

On 22-05-17 15:46, Erik van der Werf wrote: > Oh, haha, after reading Brian's post I guess I misunderstood :-) > > Anyway, LMR seems like a good idea, but last time I tried it (in Migos) > it did not help. In Magog I had some good results with fractional depth > reductions (like in Realization Pro

Re: [Computer-go] mini-max with Policy and Value network

On 22-05-17 17:47, Erik van der Werf wrote: > On Mon, May 22, 2017 at 3:56 PM, Gian-Carlo Pascutto <mailto:g...@sjeng.org>> wrote: > > Well, I think that's fundamental; you can't be wide and deep at the same > time, but at least you can chose an algorithm t

Re: [Computer-go] mini-max with Policy and Value network

On 23-05-17 03:39, David Wu wrote: > Leela playouts are definitely extremely bad compared to competitors like > Crazystone. The deep-learning version of Crazystone has no value net as > far as I know, only a policy net, which means it's going on MC playouts > alone to produce its evaluations. Nonet

<    1   2   3   >