Re: [Computer-go] Welcome to Download the "computer go dataset" (160K 9D vs 9D SGFs)
How did you get these files? I'm sure that at least Tygem guys think the game records are their own property. On 2017/04/18 0:19, Yu Yuan wrote: > 2015.11.02 - 2016.12.31 > TYGEM "9D vs 9D" dataset (1,516,031 games). > > 2003.09.25 - 2011.12.28 > TOM "9D vs 9D" dataset (50,956 games). > > https://github.com/yenw/computer-go-dataset <https://github.com/yenw> > > > ___ > Computer-go mailing list > Computer-go@computer-go.org > http://computer-go.org/mailman/listinfo/computer-go > Yamato ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] it's alphago
Hello, On 2017/01/06 3:34, Xavier Combelle wrote: >> Honestly I got a little frustrated that many people didn't think that >> was AlphaGo. It was almost clear to me because I know the difficulty of >> developing AlphaGo-like bots. > thanks for this insight, if I understand well developing a bot > competitive with alphago is nearly an impossible task? It depends on which version of AlphaGo. v13: possible v18: very hard but not impossible v19 or later: nearly impossible in one year, I think. One reason of this is that DeepMind has not published improvements since the Nature version. Yamato ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] it's alphago
Yes, it is AlphaGo. I am relieved that DeepMind clarified this. Honestly I got a little frustrated that many people didn't think that was AlphaGo. It was almost clear to me because I know the difficulty of developing AlphaGo-like bots. I hope Aja can comment here, also about GodMoves :) Yamato ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Are the AlphaGols coming?
Hello, On 2017/01/02 21:47, Lukas van de Wiel wrote: > From the thread we already read Aja's enlightenment: > > /u/emdio pointed out: > From a previous time in which a bot was suspicious to be AlphaGo: > "I can confirm it's not AlphaGo or a weaker version of AlphaGo. We > haven't decided to play AlphaGo online yet, but when the decision is > made we will use AlphaGo(P) on tygem and AlphaGoBot on KGS. > Aja" This comment was about GoBeta last April. If "Master" (or something) is AlphaGo, he should have a strong reason not to use the name AlphaGo. So probably Aja cannot answer this, because he does not lie. By the way, I found this tweet interesting :) https://twitter.com/ScienceNews/status/814559161312808965 Yamato ___ 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
Congratulations Aja. Do you have a plan to run AlphaGo on KGS? It must be a 9d! Yamato ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [computer-go] Strong programs on cgos 19x19?
Jean-loup Gailly wrote: >> The strong pachi is really strong! What hardware is it running on? >> Can you say how it differs from the vanilla pachi? > >It's exactly the same software. The only difference is that is >running on 23 cores. I am amazed at how well MCTS scales on 19x19. >Looking forward to desktop machines with thousands of cores >in a few years... What is your 23 core hardware? How much is it? -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Rank on servers at 9x9
Darren Cook wrote: >Hiroshi Yamashita wrote: >> I think we can guess something from CGOS rating. >> I made a table about CGOS and KGS bot rating. >> At least in 19x19, CGOS and KGS rank is similar. > >That is a very interesting table. It is curious that Zen is only 2 ranks >higher on 9x9. However Aya is 4 ranks higher and Fuego [1] is about 2kyu >on KGS, so (if KGS and CGOS 19x19 correspond for it too, then) also 4 >ranks higher. Zen's algorithm is getting heavier and heavier. It works well on 19x19 but does not so on 9x9. Another problem is 7.5 komi. I guess it gives very big advantage to white for high-dan level players. 7.0 komi would give better results. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] about commercial Zen
xiefan wrote: > could anyone help give me a link in English to buy the commercial version >of Zen? Now I could only find some websites in Japanese, however, I could >not read Japanese The commercial version of Zen is not yet available for overseas people. Thanks for your patience. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Progressive widening vs unpruning
David Fotland wrote: >What's your general approach? My understanding from your previous posts is >that it's something like: Your understanding is right. >I don't know if you bias the initial rave values, or bias the initial win >rate, or add a third heuristic term to the UCT formula. I don't bias the rave values. I suppose that the optimized UCT formula might include a function of Progressive widening in itself. >I don't know how you accumulate the rave value. Perhaps the same as what you do. >You apply UCT to every legal move. Yes I do, with few exceptions. >How many playouts per second do you do per CPU on 19x19? It is about 1000 playouts per second with 1 core. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Progressive widening vs unpruning
David Fotland wrote: >Well I have no idea how much I gained from this. It might be weaker than >what everyone else is doing, since it seems I didn't implement this as it's >been described recently. My progressive widening only uses Rave values. >It's very simple. Others seem to have much more complex schemes. But I >don't think I implement Rave like others do either. Your implementation must be very different from mine. Actually I don't use Progressive widening (or unpruning) at all. It's a mystery to me why others say it does work. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Progressive widening vs unpruning
David Fotland wrote: >> To be sure that I understand, MF orders the moves using static analysis, >> and >> then the ordering is further modified by RAVE observations? >> >> So when Many Faces accumulates Schedule(N) trials, it will restrict its >> attention to the N highest ranked moves according to the combined Static + >> UCT/RAVE? Or does MF restrict the choice to the highest N by Static eval, >> and then order the top N by UCT/RAVE? > >No, neither. Now I'm thinking that maybe I'm doing something different from >what I thought was described in the papers. I didn't look at them >carefully. I just took the name "Progressive widening", and invented >something that seems to work well. It is an interesting answer. You don't use the combined values, also static evaluations, for Progressive widening. So what do you use? It sounds like a ManyFaces' secret. Could you tell us how much Elo rating you gained by this invention? -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Generalizing RAVE
Stefan Kaitschick wrote: >Here's a suggestion to extend RAVE to better handle it: >There are 20 points within keima distance of any point not close to the >edge.(5*5 without the corners) >When RAVE values are backed up, they are put into the category defined by >the previous opponents move. >(21 categories, 20 + other. All added up yield the normal RAVE value) >This amounts to accumulating a killer heuristic for local points. >It can used in 2 ways: >1. prefer the best local response >2. if there is a good local response for the opponent, penalize a candidate >move I don't understand what it is useful for. I think that the near points from the previous move are already preferred by proximity heuristics. Could you give us an example? -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Generalizing RAVE
Stefan Kaitschick wrote: >About the move order problem: I'm skeptical about finding an efficient full >board algorithm that detects the consequences of move order. In this context, "the order of moves" does not mean a long sequence. It means something like "If I already played A, B is preferable for me. otherwise it is not." -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Generalizing RAVE
Peter Drake wrote: >The more I study this and try different variants, the more impressed I >am by RAVE. "Boards after the current board" is a very clever way of >defining similarity. Also, recorded RAVE playouts, being stored in >each node, expire in an elegant way. It still seems that RAVE fails to >exploit some "sibling" information. For example, if I start a playout >with black A, white B, and white wins, I should (weakly) consider B as >a response to any black first move. It is exactly the same as my thought. I also have tried CRAVE, but the results were worse than normal RAVE. While RAVE is a very efficient algorithm, it strongly limits scalability of the program. It typically makes a fatal mistake in the position that the order of moves are important. We definitely need to improve RAVE, but it is a very tough job. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] is Zen gone commercial?
Darren Cook wrote: >> They are advertising it as 2-dan (i.e. Japanese 2-dan). > >Sorry, I skimmed it too quickly. It actually says: "KGS 2-dan, which is >equivalent to Japanese Nihon Kiin 3-4 dan". Actually it is a little misleading. They didn't say that the commercial version is KGS 2d :-) Its 2-dan is equivalent to ZenLv6, weak KGS 1d. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] is Zen gone commercial?
Willemien wrote: >not so long ago (after its win in the computer olympiad) it was >announced (or was it just a rumour) that Zen would come publicly >available or available as commercial package. It is already shipped in Japan, as Tencho no Igo. The product's name in English is Zenith Go. (Tencho = Zenith) It will be available on the Internet in the near future. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] string criticality?
Stefan Kaitschick wrote: >something like this(a little Bayes): > >P(C|X) = P(X|C) * P(C) / P(X) > >P(C|X): chance that the string will be captured if x is played by any side >P(C): string_captured_count / N >P(X): x_not_empty_count / N >P(X|C): x_not_empty_when_string_captured / string_captured_count > >value 0: perfect defense >value 1: perfect offense Well, it should work theoretically but seems very expensive for the processor. When we have this information, do we have to update every node value for every string every time? -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] string criticality?
Stefan Kaitschick wrote: >There would be 2 levels of criticality: >1. How important is the string for winning the game? >2. How important are points in the vicinity for attacking/defending this >string? > (possibly with ordering information) Few months ago I tested it without success. String criticality seems a nice idea, but how should it be implemented? Just giving high priority to the liberties does not work, because that cannot be distinguished from the simple dame-filling. Can you suggest a concrete formula? -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] two won semiais = lost game?
Stefan Kaitschick wrote: >I have a general question: how good are the current information gathering >mechanisms in the mc tree to insure that advantagous semiais are actually >won? Random playouts will surely give the side with more libs the advantage, >but to what degree? Lets say the leading side wins the semiai in 2/3 of all >playouts. This seems comfortable. But except for turnarounds through ko, the >leading side should allways win the semiai. What if one side has 2 winning >semiais on the board, with winning both needed to win the game? If both have >a 2/3 chance of winning in playouts they combine to 4/9 - a losing >evaluation for a won game. It is obvious that the current mechanism is bad. And another problem on the wrong evaluation is the amplification of the error. When there are unresolved life/death or semeais on the board, typical MC programs become weak because of the instability of the simulations. I think that we need a new algorithm to combine the UCT information into the playout policy. I have already done a lot of experiments in this area, but not yet succeed. However I believe this idea will be the next breakthrough. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Dynamic komi at high handicaps
steve uurtamo wrote: >zen wins many more of its "even" games with no handicap than it does >with even, say, an even 2 stone handicap as either black or white. i >haven't compiled numbers for it (i'm not zen's maintainer), but i >watched it happen over the course of about 50 games one day. it was >pretty consistently worse with any kind of handicap on the board, the >more handicap the worse. fix the handicap problem and it would likely >rise a stone in strength. I have done some experiments in dynamic komi on Zen, and it didn't work. My experiments might not be enough, but I feel this kind of idea is not a solution for the handicap problem. Did anyone succeed with it? -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] O-Meien vs Zen
Isaac Deutsch wrote: >Did you think the bot would not benefit much from additional time usage? I'm not sure. The fast time setting was the wish of the sponsor. The games were played on the real board and they didn't want to take a much time. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] O-Meien vs Zen
Thank you all for watching the games against O Meien 9p. He was very strong. I am sorry that Zen did not play very good. Ingo Althöfer wrote: >Why did Zen play so quickly in the 19x19 game? >Only very seldomly it used more than 2 seconds to reply. I don't think it was so quick. The setting was 15 seconds per move. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: O Meien 9p vs Zen
Ingo Althöfer wrote: >Yamato San wrote: >> The match of O Meien 9p vs Zen will be held on next Monday via KGS. >> >> Schedule (JST) >> Date: August 10 >> Time: 14:10 >> >> Handicap >> 9x9: Zen is black, with 0.5 or 3.5 komi (?) >> 19x19: Zen is black, with 7 handicap stones. > >Thanks for the information. > >* How many games will be played, >two on 9x9 and one on 19x19? At least two on 9x9, possibly more. And one on 19x19. >* What will be the thinking times? The time system on KGS will be "none". Zen will use 15sec/move on 19x19, and 20sec/move on 9x9. > >Other question: Is it true what I read in KGS chat >that Zen wil be commercially availabe in Japan >on September 28, for about 9,500 Yen? Please wait for the official announcement. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] O Meien 9p vs Zen
The match of O Meien 9p vs Zen will be held on next Monday via KGS. Schedule (JST) Date: August 10 Time: 14:10 Handicap 9x9: Zen is black, with 0.5 or 3.5 komi (?) 19x19: Zen is black, with 7 handicap stones. Zen will use the accounts Zen9 and Zen19. The opponent's account name is oumeien. Have fun. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Mirror Go against Zen
Don Dailey wrote: >It could be a matter of style as you say, not a matter of strength.My >main questions is whether it's been established as true that Zen really >plays poorly and Many Faces is brilliant against mirror go.Or does it >just seem that way based on casual observation? > >The only reason I make an issue out of this is that it has happened to me >many times, where I think I see a trend or a pattern based on a few games >but it turns out to be just my imagination or low sample size. Humans >have wonderful pattern recognition, but it's well know that we easily find >patterns where they don't exist too. I have done some experiments. Zen won 30/100 games against a mechanical mirror-go program without any anti-mirror code. The 2 continuous losses were not unlikely, but I think there is no proof that Zen was far weaker against mirror-go than other programs. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Two questions to Yamato-san
Yanis Batura wrote: >Zen has almost got to 2d level on KGS, >http://www.gokgs.com/graphPage.jsp?user=zen19. Unfortunately, it doesn't >play since May, 8. > >1. Is there any hope that Zen19 will play again on KGS? I'm looking forward >to it getting to higher dan levels. When I find a new improvement, Zen will be back to test it. Zen19 might have got 2d then. >2. It's been mentioned earlier that Zen is planned to be released >commercially. If yes, when will it be, and what will be the price? Having a >dan-level Go advisor running on my home PC at my disposal is a dream of many >years! Sorry to keep you waiting. Unfortunately the project is still in the planning stage. I cannot say when or how much it will be. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Help, I hope
Michael Alford wrote: >The game of Go has four stages, joban, chuban, o-yose, and yose. I >expect computer programs to be very good at yose (not counting some of >the throw-in stuff on first line), pretty good at o-yose, good at >chuban, and utterly worthless in joban. Now, in joban you play fuseki >patterns, said patterns have a definite purpose, kobayashi, high >chinese, low chinese, ni ren sei, san ren sei, mini-chinese, etc, and >yet I read posts here debunking the value of opening books. I think this >is a very serious flaw in your approach. re Yamoto, all programs do yomi >very well, none of them play with kankaku, so I think that the next step >in your developing algorithms for this game *has* to include opening >books, otherwise I see no way for the programs to play with "kankaku". Actually I think that the word "kankaku" has multiple meanings. You are right in the meaning that you say, but I just meant judging which is ahead without reading, by "feeling". In this meaning, we can say every programs already have feeling, even if they are different from human's kankaku and strange in the fuseki stage. Zen already has the opening book and some joseki patterns. However, the problem is, a good position for a human is not always good for a program, because of their feeling. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Cross-Question on Pamplona
Jim O'Flaherty wrote: >That said, it means that one "MC" program might be using it's power much >more effectively (require substantially less CPU cycles to produce a >similarly skilled result) than another, even though both assert they are >"MC". > >Perhaps it would be better said that a Go program has an MC >characteristic rather than saying it is an MC program; association >versus identity. Human players use reading (yomi) and feeling (kankaku) to play Go. In MC programs, I think the reading is equivalent to UCT, and the feeling is equivalent to playouts. The reading is scalable, the feeling is not. If 2 programs have the playout algorithms of same level, The one which used more CPU power should win. But what happens if their level of the playout algorithm were different? Maybe this is the main reason why Zen could beat Fuego. (The game against MoGo was lucky, not good example.) -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Cross-Question on Pamplona
Ingo Althöfer wrote: >Congratulations to Zen author also from me! Thanks for your all wishes. >As far as I know, Yamato is only a nickname and not the true name >of Zen's author. If this is the case, when will the identity of >Zen's author be revealed? Did (or do) the organizers of the Pamplona >Olympiad know his or her true identity? Yes, some people (including Rémi) know my real name. I am he. :) These days it became about normal to join Internet communities anonymously, especially in Japan. So I'll intend to continue my activities as Yamato. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Monte-Carlo Simulation Balancing
David Silver wrote: >Yes, in our experiments they were just constant numbers M=N=100. If M and N are the same, is there any reason to run M simulations and N simulations separately? What happens if you combine them and calculate V and g in the single loop? >Okay, let's continue the example above. Let's say that in position s, >using the current theta, moves a, b and c will be selected with >probability 0.5, 0.3 and 0.2 respectively. Let's say that move a was >actually selected. Now consider pattern 1, this is matched after a. >But the probability of matching was (0.5*1 +0.3*1 +0.2*0) = 0.8. So >psi_1(s,a)=1-0.8 = 0.2. For pattern 2, psi_2(s,a)=1- >(0.5*1+0.3*0+0.2*1)=0.3, etc.. So in this example the vector psi(s,a) >= [0.2,0.3,-0.3,-0.2]. > >In other words, psi tells us whether each pattern was actually matched >more or less than we could have expected. I understood what psi was. I am not sure how it works, but anyway I can see your algorithm now. Thanks. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Monte-Carlo Simulation Balancing
David Silver wrote: >A: Estimate value V* of every position in a training set, using deep >rollouts. > >B: Repeat, for each position in the training set > 1. Run M simulations, estimate value of position (call this V) > 2. Run another N simulations, average the value of psi(s,a) over all >positions and moves in games that black won (call this g) > 3. Adjust parameters by alpha * (V* - V) * g Thanks for the detailed explanation. M, N and alpha are constant numbers, right? What did you set them to? >The feature vector is the set of patterns you use, with value 1 if a >pattern is matched and 0 otherwise. The simulation policy selects >actions in proportion to the exponentiated, weighted sum of all >matching patterns. For example let's say move a matches patterns 1 and >2, move b matches patterns 1 and 3, and move c matches patterns 2 and >4. Then move a would be selected with probability e^(theta1 + >theta2) / (e^(theta1 + theta2) + e^(theta1 + theta3) + e^(theta2 + >theta4)). The theta values are the weights on the patterns which we >would like to learn. They are the log of the Elo ratings in Remi >Coulom's approach. OK, I guess it is the formula 5 in the paper. >The only tricky part is computing the vector psi(s,a). Each component >of psi(s,a) corresponds to a particular pattern, and is the difference >between the observed feature (i.e. whether the pattern actually >occurred after move a in position s) and the expected feature (the >average value of the pattern, weighted by the probability of selecting >each action). I still don't understand this. Is it the formula 6? Could you please give me an example like the above? -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Monte-Carlo Simulation Balancing
David Silver wrote: >> because the previous approaches were not optimized for such a small >> boards. > >I'm not sure what you mean here? The supervised learning and >reinforcement learning approaches that we compared against are both >trained on the small boards, i.e. the pattern weights are specifically >optimised for that size of board. Ah, sorry. I missed it. >I agree that the handcrafted policy from Fuego was not optimised for >small boards, which is why it performed poorly. But perhaps this is >also interesting, i.e. it suggests that a handcrafted policy for 9x9 >Go may be significantly suboptimal when used in 19x19 Go. So >automatically learning a simulation policy may ultimately prove to be >very beneficial. It is surprising Fuego was far worse than uniform random on 5x5 and 6x6. These results show the particularity of the very small boards. I suppose 5x5 is very different from 9x9 but 19x19 is not so from 9x9. >> I'm looking forward to your results on larger boards. > >Me too :-) >Coming soon, will let you know how it goes. >But I hope that others will try these ideas too, it's always much >better to compare multiple implementations of the same algorithm. Could you give us the source code which you used? Your algorithm is too complicated, so it would be very helpful if possible. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Monte-Carlo Simulation Balancing
David Silver wrote: >Please find attached my ICML paper with Gerry Tesauro on automatically >learning a simulation policy for Monte-Carlo Go. Our preliminary >results show a 200+ Elo improvement over previous approaches, although >our experiments were restricted to simple Monte-Carlo search with no >tree on small boards. I like you idea, but why do you use only 5x5 and 6x6 Go? I don't think the 200+ Elo improvement is so impressive because the previous approaches were not optimized for such a small boards. I'm looking forward to your results on larger boards. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] April 2009 KGS tournament
Ingo Althöfer wrote: >Other question: Might it be possible to find a >volunteer for operating Zen19 in Pamplona? I forgot to say it here - Mr. Kato came forward as an operator of Zen. It will play via KGS. Have a good game, all. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The Zen Program
>Are your playouts simple enough so you could publish the exact algorithm in >(pseudo) source code? >I'm sure many will be interested if you are willing to share it. I need to keep details secret for a while, to retain its commercial value. But I can say that Remi's work was more important than mine. If you don't use minorization-maximization yet, I recommend studying it. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The Zen Program
>Thank you for your friendly offer. I think many people on this list >will be curious to hear more about what makes Zen such a strong >program. Is it similar to Mogo or CrazyStone? Do you use any extra Go >knowledge? Which other improvements have you found? Zen is similar to partly MoGo, partly Crazy Stone. It has shape patterns that are generated by minorization-maximization algorithm like Crazy Stone. But they are directly combined with UCT - I don't use progressive widening. Probably the most original part of Zen is in the playout. I don't think MC simulations must be always fast, so it has a lot of hard-coded Go knowledge. >I am also interested in hearing your future plans. Will this be a >commercial product? Will you participate in the Olympiad and in the >next KGS tournament? Will you have a massively parallel version as well? I hope it will be a commercial product but currently I have no specific plans. I don't have plans about a massively parallel version either. Unfortunately I cannot participate in the Olympiad. For KGS, I can. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The Zen program
Andy wrote: >It looks like Zen19 doesn't implement handicap stone komi compensation >the same way kgs does for Chinese rules. It's the only reason I can >think that it lost this game: > >http://files.gokgs.com/games/2009/3/27/TaPaHka-Zen19.sgf Thanks for reporting it. You are right, I was not aware of the KGS rule. I think I have fixed the problem now. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The Zen program
Rémi Coulom wrote: >Martin Mueller wrote: >> Zen has been getting very impressive results on CGOS. Yamato-san, >> could you tell us a little bit about yourself and your program? >> >> Thanks >> >> Martin > >Yes, very strong results. Congratulations to Yamato-san for beating >Crazy Stone. > >I am curious about hardware. On CGOS, Crazy Stone is running on core2 >duo (2 threads). > >Rémi Hi Martin & Rémi, thanks for having interest in my program. Zen runs on Quad-Core AMD Opteron. I suppose it has nearly the same strength as Crazy Stone. It is running on KGS now and you can see its games from here. http://www.gokgs.com/gameArchives.jsp?user=zen19 I am an individual programmer in Japan. Any questions are welcome. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MC and Japanese rules
Mark Boon wrote: >> Look at the attached file. This position is win for black in Japanese >> rules, but the only correct move is pass. If black plays anywhere other >> than pass, he loses. This time white's correct move is pass, otherwise >> he loses. Such a condition breaks winning rate values in the tree. >> >> How should I handle this? > >It seems pretty straightforward to me. The UCT exploration needs to >choose pass for Black and he'll win. Yes, but it seems hard becuase every nodes have around 50% winning rate and big variance. Do your program choose pass correctly? >You say "white's correct move is pass, otherwise he loses". That's not >entirely correct. White loses no matter what he does, whether it's a >pass or anything else. I meant that for when Black plays wrong move. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MC and Japanese rules
Sorry for responding to the old topic. Mark Boon wrote: >Other than that, I'd take a different approach: > >- play out as usual. Instead of counting stones + eyes on the board, >you count eyes + prisoners + nr-opponent's passes during playout. >- don't count passes outside of playout. > >I think this avoids having to take a security margin or require >passing as soon as the opponent does (although in practice that may >happen almost all the time). The seki-matter is the same. I think this scheme works for the playout itself, but I have a problem with UCT tree. Look at the attached file. This position is win for black in Japanese rules, but the only correct move is pass. If black plays anywhere other than pass, he loses. This time white's correct move is pass, otherwise he loses. Such a condition breaks winning rate values in the tree. How should I handle this? -- Yamato jpn.sgf Description: Binary data ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fuego performance
>Oops, good point. I used just: > > ../gogui-1.1.4/bin/gogui-twogtp -black './mogo' -white './fuego' >-auto -size 19 -komi 7.5 -alternate -games 100 -sgffile "mogo-vs-fuego" >-verbose -time 20 > >But apparently MoGo doesn't honor the time settings completely this way. >I will rerun it with --totalTime 1200. I suppose that --totalTime also doesn't work if you use twogtp. --time will work. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fuego performance
> I ran 86 19x19 games with both on the same hardware (single core of >A64 X2 6000+, 2G RAM) with 20 minutes S.D. each, the rate is MoGo win >83.3% (+-4.1). How did you set the time to 20 minutes S.D.? MoGo doesn't update the clock if you don't send time_left, and Fuego does. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 9x9 go Principle Variation with perfect play
David Fotland wrote: >At this point I think everyone would agree that E5 is the optimal first move >for black on 9x9. > >Now that I have deeper and more accurate search, my engine favors E7 in >response to E5 by a large margin. Do the other strong programs also find >that E7 is best response? I have the statistics of the CGOS games. After E5, white response is: D7: 25904/53339 (48% win) E6: 5351/19651 (27% win) E7: 7354/17054 (43% win) C6: 5432/16994 (31% win) C7: 4316/11409 (37% win) So, Zen plays D7 now. But of course this is just statistics. The bias by MoGo always playing D7 would be huge. >After E5 E7, there are several moves I've seen from strong engines. My >opinion as a go player is that best next move is either E3 or D6. My >program chooses different moves here depending on the search settings. E5, E7, next black move is: D6: 3781/ 5817 (64% win) D7: 2195/ 3378 (64% win) E3: 918/ 1742 (52% win) C6: 863/ 1707 (50% win) C5: 779/ 1418 (54% win) It seems the best move is D6 or D7. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Bug in the Reivax
Magnus Persson wrote: >The program reivax on 9x9 CGOS seems to be strong but suffer from a >bug leading it to pass too early, and thus it often loses games >against weaker programs that do not resign. Who is the author of Reivax? It's like a CGOS deflator. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Test position set for MC programs
John Fan wrote: >On Problem 125, sounds like B2 is also a right move. B:B2, W:B1, B:C1, W:A2, B:A1, W:C2, B:A3, W:D1. Black seems to cannot win this ko. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Test position set for MC programs
David Fotland wrote: >I didnt see this: > >>>148: D1 also wins? >> You are right. Thanks for correction. > >Many Faces played D1, so change it to 38 correct. Did you use the fixed version? I corrected #148 as follows. Is it still wrong? loadsgf sgf/mc148.sgf 148 reg_genmove black #? [B1|D1] -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Test position set for MC programs
Thanks Gian-Carlo, Gunnar. Current list of results. GNU Go 3.7.12 level 0 : 24/50 GNU Go 3.7.12 level 10 : 34/50 GNU Go 3.7.12 level 15 : 37/50 GNU Go 3.7.12 mc, 1k : 30/50 GNU Go 3.7.12 mc, 10k : 31/50 GNU Go 3.7.12 mc, 100k : 38/50 GNU Go 3.7.12 mc, light, 1k: 33/50 GNU Go 3.7.12 mc, light, 10k : 30/50 GNU Go 3.7.12 mc, light, 100k : 25/50 GNU Go 3.7.12 mc, mogo, 1k : 34/50 GNU Go 3.7.12 mc, mogo, 10k: 33/50 GNU Go 3.7.12 mc, mogo, 100k : 35/50 Leela 0.3.14, 1k : 19/50 Leela 0.3.14, 10k : 28/50 Leela 0.3.14, 100k : 36/50 Zen 1.5, 1k: 19/50 Zen 1.5, 10k : 22/50 Zen 1.5, 100k : 24/50 Leela seems to have good scalability. 36/50 passes is fine. The results of GNU Go are a bit irregular because of its hybrid strategy. If GNU Go could run on the MC only mode, it might be more interesting, I guess. Gunnar Farnebäck wrote: >One more correction. The fixed version added B1 as a correct move in >113, but that point is occupied. My mistake. There will be no effect on the results, anyway. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Test position set for MC programs
Gunnar Farnebäck wrote: >108: If I'm not mistaken A3 and G1 both give B+3.5 whereas A2 gives >B+1.5 so komi could be 9.5 but there would still be two solutions. > >113: Black can also start with E8 and still have sufficient ko >threats. > >125: B1 also kills. > >128: D2 kills, not C2. > >131: It looks like B4 wins by 3.5 and D1 by 1.5 so komi should be 9.5 >to give a unique winning move. > >148: D1 also wins? You are right. Thanks for correction. >130: D2 becomes more complicated but looks good enough to win with >komi 7.5. I don't see why D2 works. After E2, can black live? >139: C2 and B1 also live. Yes, but will not win with komi 7.5. >143: I don't see how A3 could win the semeai. A2 and C4 look more >effective. Typo, it was A2. C4 cannot work. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Test position set for MC programs
Don Dailey wrote: >Go problems don't work for MC programs unless you can arrange them so >that finding the right move wins, and anything else loses. I found you >can modify some problems by manipulating the komi to make this true. I intend to have adjusted all of them like that (only 1 move = win). Do you mean you found some problems are wrong? -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New UCT-RAVE formula (was Re: computer-go Digest, Vol 43, Issue 8)
David Silver wrote: >There are two differences between your suggestion and the original >formula, so I'll try and address both: > >1. Your formula gives the variance of a single simulation, with >probability value_u. But the more simulations you see, the more you >reduce the uncertainty, so you must divide by n. > >In general, the variance of a single coin-flip (with probability p of >heads) is p(1-p). >The variance of the sum of n coin-flips is np(1-p). >The variance of the average of n coin-flips is p(1-p)/n. This is what >we want! > >2. The variance of the estimate is actually given by: variance_u = >true_value_u * (1 - true_value_u) / n, where true_value_u is the real >probability of winning a simulation (for the current policy), if we >had access to an oracle. Unfortunately, we don't - so we use the best >available estimate. If we have seen a large number of simulations, >then you are right that value_u is the best estimate. But if we have >only seen a few simulations, then value_r gives a better estimate >(this is the point of RAVE!) The whole point of this approach is to >form the best possible estimate of true_value_u, by combining these >two estimates together. In a way this is somewhat circular: we use the >best estimate so far to compute the best new estimate. But I don't >think that is unreasonable in this case. Thanks for the detailed explanation. The formula became clear to me. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New UCT-RAVE formula (was Re: computer-go Digest, Vol 43, Issue 8)
I am very confused about the new UCT-RAVE formula. The equation 9 seems to mean: variance_u = value_ur * (1 - value_ur) / n. Is it wrong? If correct, why is it the variance? I think that the variance of the UCT should be: variance_u = value_u * (1 - value_u). Why cannot we use that? Anyway, can anyone write the pseudo-code of this algorithm? -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New UCT-RAVE formula (was Re: computer-go Digest, Vol 43, Issue 8)
David Silver wrote: >BTW if anyone just wants the formula, and doesn't care about the >derivation - then just use equations 11-14. Yes, I just want to use the formula. But I don't know what the "bias" is... How can I get the value of br? By the way I currently use this formula. beta = 1 - log(m) / 20 I think it is a little better than the one on the ICML paper. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] CGOS Deflation or Self-Play delusion?
Don Dailey wrote: >But FatMan is still 1800!I wonder if FatMan improved causing the >deflation? :-) Don, why don't you use MoGo as the second anchor? -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] CGOS Deflation or Self-Play delusion?
Gian-Carlo Pascutto wrote: >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 I think it is CGOS deflation. The evidence is: ControlBoy 1546 8/8 100.00 <- Zen-0.9 ControlBoy 1460 5/5 100.00 <- Zen-1.0 -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to design the stronger playout policy?
Don Dailey wrote: >Lazarus uses a system very simlar to the original MoGo policy as >documented in the paper. However I did find one significant >improvement.I used Rémi's ELO system to rate patterns and I simply >throw out moves which match the weakest patterns in the play-outs.In >the tree, I also throw out these moves but this is progressive. >Those moves still get explored but not near leaf nodes. It is interesting that many people say the similar thing. I'll try to use ELO rating of patterns again. >Programs that play games tend to be highly idiosyncratic. What may >work today may not work tomorrow or may work for me and not you.It >depends on what is already in your program, what isn't, how you >implemented it, etc.Some improvements work well with others and some >do not cooperate with other changes. The whole process is a bit of a >black art, not just the play-outs. I fully agree. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to design the stronger playout policy?
Gian-Carlo Pascutto wrote: >What improvements did you try? The obvious one I know are prioritizing >saving and capturing moves by the size of the string. > >Zen appears quite strong on CGOS. Leela using the above system was >certainly weaker. I use the static ladder search in playouts. For example, if a move that matched a 3x3 pattern is capturable in ladder, that is not interesting. Of course such a rule makes a program slower, but I believe it is an improvement. >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 >exceptional result. There could be some other magic combination that is >even better, or maybe not. I also have implemented Remi's Minorization-Maximization algorithm. But I could not find how to use the result of it to improve the strength. Would you explain the details of the playout policy? Do you use only 3x3 patterns? >What is so frustrating is that the playouts are essentially black magic. > I know of no way to automatically determine what is good and not >besides playing about 500 games between 2 strategies. The results are >very often completely counterintuitive. There is no systematic way to >improve. Yes. In addition, the big problem is that testing policies is very time consuming. I think at least 1000 games that use 3000 or more playouts per move are needed to judge whether a change is good or bad. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] How to design the stronger playout policy?
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, plays one randomly. (3) If there are the moves capturing stones, plays one randomly. (4) Plays one random move on the board. I (and maybe many others) use it with some improvements, however it will be not enough to catch up the top programs. Crazy Stone uses a probability distribution of patterns from the Bradeley-Terry Model. greenpeep uses similar patterns extracted from the offline self-play. Then I have tested a lot of change of probability distributions, but it was very hard to improve the strength. Any comments? -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] greenpeep
Christopher Rosin wrote: >greenpeep's patterns include the local 3x3 neighborhood. In addition, >for each of the four nearest neighbors, it includes liberty count info if >that neighbor is occupied, or otherwise info about 2-away point just >beyond that neighbor if the neighbor itself is empty. Liberty information in patterns is a good idea. That might contribute to improve the quality of playouts. >1) basic UCT with self-play patterns in the MC playouts. This had no other >MC >biases for locality, captures, etc., and did not use patterns to bias UCT >choices, >and did not use all-moves-as-first: 24% >2) like (1), but replacing self-play patterns by an implementation of MoGo's >full scheme for MC playouts (as described in the MoGo report RR-6062); >this doesn't use the self-play patterns at all: 47% >3) like (2), but using the self-play patterns to bias the MoGo MC scheme's >final fallback to random global moves: 54% >4) to (3), add self-play pattern bias in UCT tree, and all-moves-as-first: >77% >5) Like (4), but replacing MoGo's local-move patterns by locally restricted >self-play patterns (so this is no longer using MoGo's hand-coded patterns, >but still uses the explicit preference for captures/saves and local moves): >84% Thanks for interesting results. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] greenpeep
-From "Re: So many MoGo run on cgos 9x9": >greenpeep also uses patterns derived from 2 UCT self-play games. >These are simple local patterns with scores that (roughly) indicate >the probability that the move at the center of the pattern was >selected by UCT during these games. These patterns are then used both >to bias moves at UCT nodes which have few visits, and also to bias the >playouts. What I've seen is: >- Biasing playouts by patterns is much better than unbiased playouts >- Playouts using self-play patterns together with MoGo-style move > preferences (favor defensive moves and captures, as well as local > moves biased by the self-play patterns, before resorting to a global > move biased by patterns) yield much better results than just using > the patterns by themselves globally. I am interested in this improvemnt. Do you have any data to compare the performance of biased playouts with MoGo-style one? (the winning rate against GNU Go, etc) Also, how large and how many are your patterns? -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] RAVE in MoGo paper
>I'm wondering whether the formula to determine the balance between RAVE and >UCT, >beta = sqrt(c / 3 * parentVisits + c), >has any mathematical background - or is it just a best guess for something >that starts at 1 and is 1/2 after a certain number of visits? I guess it is simply a kind of parameter tuning. At least the constant number 3 is meaningless in the formula - we can use the following formula with c2 = c/3. beta = sqrt(c2 / (parentVisits + c2)) >Another question is about the prior integration. Apparently the prior, RAVE >and UCT values are three different estimators for the winning probability. So >why not use the above formula for prior vs. RAVE balancing, too, instead of >initializing RAVE with it? Because the prior values do not change during simulations like RAVE and UCT values. Of course there might be a more effective integration method, however we need very long time to find it. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Update of MoGo binary release, and windows version available!
>Yes you can: >--nbTotalSimulations 3000 > >Once you set this option it ignores all other time settings. Thanks! It works perfectly. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Update of MoGo binary release, and windows version available!
Sylvain, Can I set the number of the simulations per move instead of the thinking time? (like "--simulations 3000") If possible, it is very useful for the benchmark. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Binary release of MoGo
>> Have you tried Visual C++? >> http://msdn2.microsoft.com/en-us/express/aa975050.aspx > >The thing is that VC++ does not have the pthread library. This library might be help. http://sources.redhat.com/pthreads-win32/ # I have not used it, though -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Binary release of MoGo
It is a good news for all of us. I have no time to develop my Go program now, but I will use it as a local opponent when I come back again. >Unfortunately, only the linux version is available (for the moment?). >I wanted to wait for the windows version to be available at the same >time, but it is 2 times slower than the linux version(!!), so I >decided not to distribute it for the moment. I use cygwin for that, >and maybe the reason is that cygwin has only gcc 3.4.2, and which >produce a much slower binary. If anyone has a solution, I would be >pleased to put the windows version as soon as possible. Have you tried Visual C++? http://msdn2.microsoft.com/en-us/express/aa975050.aspx -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Explanation to MoGo paper wanted.
>In Go things are insofar worse as there is only one standard sparring >partner, Gnu-Go. This creates severe inbreeding effects. In chess there was >a similar problem. There were more strong opponents around, but over the >years they become very similar. Suddenly there was a new programm, Rybka, >which plays different and all the inbreedings have a lot of difficulties. > >I think there is no better way. One can do some pre-filtering with test >positions. If a version is especially bad in these tests, one can ignore it. >But being good in test positions and in games are different things. When MonteGNU is published, it will be an alternative of GNU Go. Of course MC vs MC may have some problems, but at least it is stronger than GNU Go on 9x9. And, if the way to combine UCT and the local tactical search is discovered, the regression test like GNU Go will be also useful. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Explanation to MoGo paper wanted.
>There is one other issue I have seen that is similar. Sometimes >Lazarus will play a move that doesn't hurt nor help it's position. >It's not a wasted move because the opponent must respond or else lose. >An example is a simple self-atari which itself is a direct threat. The >opponent is forced to respond, so there is no reason not to try for the >cheap shot in his territory, but in the grand scheme of things this move >is a distraction and if you could remove them from the tree it would >help the program focus on what is really important.However, it >sometimes pays to try moves like these. When I "fixed" this problem in >Lazarus, it started winning less against weaker programs simply because >they sometimes fail to defend. And is that version stronger against higher-level programs? Losing against weaker programs might be the cost that we should pay temporarily. I think one of the problems is in testing. Currently we have almost no way to judge whether a improvement is good or bad, other than playing a lot of games against GNU Go. It takes very long time and seems inefficient. Moreover, even it may not be a very good method. GNU Go often cannot respond to an obvious bad move correctly, so pruning such moves decrease the winning rate. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Explanation to MoGo paper wanted.
>In other words UCT works well when evaluation/playouts is/are strong. I >believe >there are still improvements possible to the UCT algorithm as shown by the >recent papers by Mogo and Crazystone authors, but what really will make a >difference is in the quality in the playouts. Sylvain said that good moves in the playouts do not always improve the performance of UCT. What do you think about this claim? -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Explanation to MoGo paper wanted.
>> The most important thing in the paper is how to combine RAVE(AMAF) >> information with normal UCT. Like this: >> >> uct_value = child->GetUctValue(); >> rave_value = child->GetRaveValue(); >> beta = sqrt(K / (3 * node->visits + K)); >> uct_rave = beta * rave_value + (1 - beta) * uct_value; >> >Thanks for the translation. The only point I am still missing: What is >RAVE(AMAF)? RAVE is another name of AMAF(all moves as first) heuristic. The details of AMAF are explained in this paper. http://www.ai.univ-paris8.fr/~bh/articles/acg10-mcgo.pdf -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Explanation to MoGo paper wanted.
>I have the feeling that the paper is important, but it is completly >obfuscated by the strange reinforcement learning notation and jargon. Can >anyone explain it in Go-programming words? The most important thing in the paper is how to combine RAVE(AMAF) information with normal UCT. Like this: uct_value = child->GetUctValue(); rave_value = child->GetRaveValue(); beta = sqrt(K / (3 * node->visits + K)); uct_rave = beta * rave_value + (1 - beta) * uct_value; You do not always have to understand RLGO - they don't use it in the online version of MoGo. >It was pointed out by Donald Knuth in his paper on Alpha-Beta, that the - >simple - algorithm was not understood for a long time, because of the >inappropriate mathematical notation. For recursive functions, (pseudo-)code >is much better suited than the mathematical notation. Actually its >pseudo-mathematic notation. >Why is this inappropriate notation still used? I agree that the pseudo-code is easy to understand. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo paper at ICML
>> Sorry, what is AMAF? > >Sorry: All Moves As First :) OK, I see. >Q_RLGO is not used in MoGo's versions which play online. >Q_MoGo(s,a) is: >- if (self atari(s,a)): 0 >- if one pattern, among the patterns used in MoGo's simulation policy, >matches for move "a" in position "s", then 1 >- else 0.5 Thanks for that. These values were more extreme than my expectation. I thought you use values like 0.4 or 0.6. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo paper at ICML
>> >Using prior knowledge on "normal" uct, and this was the use of prior >> >knowledge brought about the same improvement. >> >> You mean, there is more improvement when using both? > >I mean that there is no need to have AMAF to get improvement by using prior >knowledge. Sorry, what is AMAF? And I have another question; Don't you use Q_RLGO anymore? If so, would you explain the detail of the Q_MoGo heuristic? -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo paper at ICML
>Using prior knowledge on "normal" uct, and this was the use of prior >knowledge brought about the same improvement. You mean, there is more improvement when using both? >It was gnugo default level, and we thought "default" was 8, but default is >actually 10. I don't see why it is so surprising, I guess it does not change >really the level of gnugo. Because I have tested my program against GNU Go level 8 to compare the winning rate with MoGo. Now I see surely there is almost no change. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo paper at ICML
>The cumulative result is only given using the prior knowledge on top >of RAVE, but it could have been done the other way round and give the >same type of results. Each particular improvement is somehow >independent of the others. I think I don't understand that. What do you mean for "the other way round?" >All experiments (except the default policy) were played against GnuGo >level 10, not level 8. That's surprising news to me... -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Amsterdam 2007 paper
Rémi, May I ask you some more questions? (1) You define Dj as Dj=Mij*ci+Bij. Is it not Aij but Bij? What does this mean? (2) You have relatively few shape patterns. How large is each pattern? 5x5, 7x7, or more? (3) You say "the nth move is added when 40*1.4^(n-2) simulations have been run." How did you determine these numbers? Thanks -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Amsterdam 2007 paper
Thanks for the nice paper. > I will run cleaner tests for the final version of the paper. I will also > try to test what each feature brings. I hope that you do 70k simulations like MoGo, since "90s/game 1CPU" depends on the simulation speed and the time distribution. And I have a question. In section 4.1, you wrote: > Contiguity to the previous move is a very strong feature (gamma = 23) Where has the number 23 come from? -- Yamato -- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Grid Cosmos
>A week ago, I announced the release of Grid Cosmos in the Japanese >Computer Go mailing list, and Japanese researchers could download and play it >and no body reported download trouble. Could you tell me where the Japanese mailing list is? >If you know a good international download site, please inform me! If you want, I recommend Download.com. But I would rather you put it on CGOS or KGS. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Discounted UCB
Thank you Sylvain, your explanation is enough for me. -- Yamato >Hi Yamato, > >> However I cannot find any explanation for it. >> Does anyone know what Discounted UCB is? > >"Discounted" means you forget somehow the past. More precisely, if "w" >is your count of wins, and "t" your total playouts, and "r" the >results of the current simulation, instead of doing: > >w <- w+r >t <- t+1 > >you do, with gamma <1: > >w<- gamma *w + r >t <- gamma*t + 1 > >So it is as if you kept a memory of the order of 1/(1-gamma) > >> Is it useful for MC Go? >The idea is appealing for UCT, as the distribution of the arms is not >stationary, and discounting is the simplest idea to deal with >non-stationarity. >However, all my trials in this direction had been unsuccessful. Maybe >some succeed I don't know. > >I hope that makes things clearer, >Sylvain >___ >computer-go mailing list >computer-go@computer-go.org >http://www.computer-go.org/mailman/listinfo/computer-go/ -- Start Yahoo! Auction now! Check out the cool campaign http://pr.mail.yahoo.co.jp/auction/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Discounted UCB
Hello All, I have found this slide on Google. http://www.lri.fr/~sebag/Slides/Venice/Kocsis.pdf However I cannot find any explanation for it. Does anyone know what Discounted UCB is? Is it useful for MC Go? -- Yamato -- Start Yahoo! Auction now! Check out the cool campaign http://pr.mail.yahoo.co.jp/auction/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
