RE: [computer-go] Testing Process
You have inspired me to put Many Faces back on cgos, both 9x9 and 19x19, using just one core on each, so it doesn't take much of my computing resources. Testing against gnugo says going from 1 core to 4 cores is about 150 ELO for Many Faces. I should be able to keep Many Faces on CGOS indefinitely, but I won't watch it much, so please let me know if a restart or crash drops it off so I can restart it. I'd suggest you put Pebbles on 19x19 also. My 19x19 engine is much stronger than it was a year ago, while my 9x9 is about the same, so there is a lot of progress to be made in playing go that can't be discovered on 9x9. I test against gnugo for a fast opponent to give quick regressions after every change, since I like to play 1000 games or more. I use kgs to give a variety of stronger opponents to find tactical flaws. David -Original Message- From: computer-go-boun...@computer-go.org [mailto:computer-go- boun...@computer-go.org] On Behalf Of Brian Sheppard Sent: Monday, September 28, 2009 3:10 PM To: computer-go@computer-go.org Subject: [computer-go] Testing Process By now, I should probably find better reference opponent than gnugo... I wonder if to pick fuego or mogo... ;-) Strength is probably not _as_ important as the variety of techniques used in order to avoid selective blindness (that's why I don't like tuning by self-play), does anyone have a tip? Or do higher gnugo levels make much strength difference? Pebbles doesn't follow the norms, but I am very happy with my solution: just play constantly on CGOS. CGOS provides a range of opponents of different styles, including non-MCTS opponents that use neural networks or alpha-beta. You can play 140 games per day, which is plenty. You are right about selective blindness. Some programs, like GnuGo, regularly donate rating points to Pebbles. Others, like Valkyria, take those away. You need a range of opponents. Overall, CGOS gives a realistic measure of where you stand. I have some suggestions for effective use of CGOS for testing purposes. First, I don't aim to have the highest-rated program, because I am not caught up in the hardware race. Instead, I use a modest CPU and try to write good software. Some programs run on an 8-core processor, play exactly 100 games (to get a non-provisional rating), lose only 10, and then disappear. The programmers must have good reasons for this, but running on elite hardware obscures flaws in the software, so it isn't for me. Even when Pebbles has better hardware, I will continue to run a version on CGOS using low hardware. I learn more from losses! Second, I run two identical copies of Pebbles. The other is called PebblesToo. Both copies run on the same dual-core machine, so they have the same performance over the long run. PebblesToo serves three purposes. One, it doubles the pace of data collection. This is far better use of the second core than playing twice as fast, IMO. Two, when Pebbles is matched up against Valkyria, PebblesToo is necessarily playing a weaker opponent, which provides a more balanced view. Three, Pebbles will get some self-play games, which are a necessary part of an overall testing strategy. Third, I run a version of Fuego that is a little below Pebbles. It is called fuego-0.4-slow. This program serves two purposes. One, it sucks up games against very low rated players (because CGOS favors pairings of equal opponents). Two, it provides a nearby program that is always available, so if Aya and Lingo are offline there is still an opponent of about the right level. Fourth, Pebbles plays a lot of 9x9 games. Such games give your program an intense tactical workout at 10 minutes per game. I assure you that no current program has adequate tactics. Most strong programs have opening libraries and run on much more powerful computers. When Pebbles defeats such an opponent, it is invariably because they overlook a tactical shot. IMO, programmers that disdain 9x9 are learning about flaws more slowly than necessary. Fifth, Pebbles saves two positions from every loss: the last position in which it thought it was winning (eval of the selected move = 50%), and the position in which it thought it had the greatest advantage. Pebbles regularly (~1 or 2 games per day) loses games where it thinks it will win 90% of the time. I always learn something by analyzing those games. Sixth and finally, CGOS is a community resource that is more valuable when it used more by more people. So use it! Run your program as often as possible. Pebbles has played ~16000 games. I rarely have new software, but Pebbles plays anyway. Following this process raised Pebbles by ~1200 rating points over a 6- month period, all on the same hardware. Pebbles now beats GnuGo by ~94% with no specific tuning towards that goal. If I targeted GnuGo, the percentage would run well over 100%. :-) But there are larger and higher goals.
Re: [computer-go] Generalizing RAVE
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) One more thought. I think the proximity heuristic should actually make this more effective, not less. Because many moves are close to the last one, the uninformative other category gets less hits. And an ordering of the close points in order of previous effectiveness should help guide the search more effectively. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] October KGS bot tournament: 19x19 boards, slow
The October 2009 KGS computer Go tournament will be this Sunday, October 4th, in the Asian evening, European morning and afternoon, and American night, starting at 08:00 UTC/GMT (09:00 BST) and ending at 16:00 UTC/GMT (17:00 BST). I have now accepted unofficial entries from Fuego using the name 'FuegoAl', operated by Aloril GNU Go using the name 'GnuGoAl', operated by Aloril and hope to receive one from MoGousing the name 'CzechBot', operated by Petr Baudiš. I welcome these, as I want to see these strong players take part, and so, I believe, do the other entrants. However they are all willing to step down to make way for official entries from these same players, particularly if the official entries are able to use more processor power - Aloril's Fuego will be running on two cores and his GNU Go on one. I would even welcome unofficial entries for GNU Go and Fuego if these would be able to use more processor power than Aloril can, and so would he. Nick There will only be one division. It will be an 8-round Swiss with 19x19 boards and 29 minutes each of main time. It will use Chinese rules with 7.5 points komi, and a fast Canadian Overtime, of 25 moves in 30 seconds. There are details at http://www.gokgs.com/tour nInfo.jsp?id=481. Registration is now open. To enter, please read and follow the instructions at http://www.weddslist.com/kgs/how/index.html. The rules are given at http://www.weddslist.com/kgs/rules.html. Your bot need not be strong to enter, indeed weak and new bots are particularly welcome. Please send your registration email (with the words KGS Tournament Registration in the title) to me at maproom at gmail dot com (converted to a valid address in the obvious way). Nick -- Nick Weddn...@maproom.co.uk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] public test suite
Every now and then somebody submits an interesting 9*9 problem, usually rendered in X and O. Wouldn't it be great to have a public suite, lets say a directory with black to play and win sgf problems. For quick testing there should be only one correct first move. There could also be subdirectories for problem types. Maybe CGOS could be expanded to send bots through the test batch. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] public test suite
On Tue, Sep 29, 2009 at 12:12:07PM +0200, Stefan Kaitschick wrote: Every now and then somebody submits an interesting 9*9 problem, usually rendered in X and O. Wouldn't it be great to have a public suite, lets say a directory with black to play and win sgf problems. For quick testing there should be only one correct first move. There could also be subdirectories for problem types. Maybe CGOS could be expanded to send bots through the test batch. Fuego has a regression suite, which you can use together with gogui-regress tool. I have been meaning to run my bot through it for some time... :-) Petr Pasky Baudis ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Testing Process
Hi! On Mon, Sep 28, 2009 at 04:09:31PM -0600, Brian Sheppard wrote: By now, I should probably find better reference opponent than gnugo... I wonder if to pick fuego or mogo... ;-) Strength is probably not _as_ important as the variety of techniques used in order to avoid selective blindness (that's why I don't like tuning by self-play), does anyone have a tip? Or do higher gnugo levels make much strength difference? Pebbles doesn't follow the norms, but I am very happy with my solution: just play constantly on CGOS. CGOS provides a range of opponents of different styles, including non-MCTS opponents that use neural networks or alpha-beta. You can play 140 games per day, which is plenty. I agree CGOS is great, and you prompted me to run my bot there again ;-) - I wonder how much ELO it will get. But CGOS is for a different purpose I think - finding out where your bot stands in the long term; what I'm using my gnugo testing for is quickly assessing value of various minor changes and many variants. Getting pretty reliable estimate (400 games) takes just about 3-5 hours; getting that on CGOS would take few days, which is a lot less convenient. I don't even almost ever look at the test games with gnugo, just the overall percentage is all I care about. Fifth, Pebbles saves two positions from every loss: the last position in which it thought it was winning (eval of the selected move = 50%), and the position in which it thought it had the greatest advantage. Pebbles regularly (~1 or 2 games per day) loses games where it thinks it will win 90% of the time. I always learn something by analyzing those games. This is pretty interesting idea! -- Petr Pasky Baudis A lot of people have my books on their bookshelves. That's the problem, they need to read them. -- Don Knuth ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] cgosview?
Hi , I remeber a version where the call was just ./cgosview-linux-x86_32 cgos.boardspace.net 6819 Hi! How do I use cgosview-linux-x86_32? By default it connects to the 19x19 server and that works (displays empty game list window), but I can't find out how to tell it to connect to 9x9; the moment I try to pass it any parameter, I get: pa...@pixie:~/src ./cgosview-linux-x86_32 -server cgos.boardspace.net -port 6819 could not execute pa...@pixie:~/src ./cgosview-linux-x86_32 -port 6819 could not execute -- Petr Pasky Baudis A lot of people have my books on their bookshelves. That's the problem, they need to read them. -- Don Knuth ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ __ GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] cgosview?
Hi! On Tue, Sep 29, 2009 at 01:45:40PM +0200, Lars Schäfers wrote: I remeber a version where the call was just ./cgosview-linux-x86_32 cgos.boardspace.net 6819 Ahh, thanks, that works. I think the website should be fixed then. :-) Petr Pasky Baudis ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] cgosview?
*sigh* I made a wiki for CGOS as part of the sourceforge project. I should just take it down since it never became the official home page. I don't even think it has a link to it from the official home page! Even things like download links are duplicated... Sent from my iPhone On Sep 29, 2009, at 8:09 AM, Petr Baudis pa...@ucw.cz wrote: Hi! On Tue, Sep 29, 2009 at 01:45:40PM +0200, Lars Schäfers wrote: I remeber a version where the call was just ./cgosview-linux-x86_32 cgos.boardspace.net 6819 Ahh, thanks, that works. I think the website should be fixed then. :-) Petr Pasky Baudis ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ 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
I start with one move, and slowly add moves to the pool of moves to be considered, peaking at considering 30 moves. My current schedule looks like: visits 0 2 5 9 15 24 38 59 90 100 ... 2142 moves 1 2 3 4 5 6 7 8 9 10 ...20 I didn't find that strength is very sensitive to the schedule. Many Faces is a pretty good heuristic for selecting good moves, so if you are just using RAVE to do move ordering you might need to widen faster. David -Original Message- From: computer-go-boun...@computer-go.org [mailto:computer-go- boun...@computer-go.org] On Behalf Of Petr Baudis Sent: Tuesday, September 29, 2009 7:07 AM To: computer-go@computer-go.org Subject: [computer-go] Progressive widening vs unpruning Hi! I'm a little unclear on this, so I'd like to make sure I'm not missing any important technique - is progressive widening and progressive unpruning synonymous? I have looked both into the pMCTS and the CrazyStone papers and it seems that widening differs from unpruning in that certain number of simulations is first made before limiting the number of searches. Which of the variants is commonly used? What speed of widening works for you best? Thanks, -- Petr Pasky Baudis A lot of people have my books on their bookshelves. That's the problem, they need to read them. -- Don Knuth ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Testing Process
You have inspired me to put Many Faces back on cgos, both 9x9 and 19x19, using just one core on each, so it doesn't take much of my computing resources. It will be wonderful to have an omnipresent omniscient opponent again. :-) I'd suggest you put Pebbles on 19x19 also. Pebbles and Many Faces are in different phases of life. Pebbles is immature, but its behavior is appropriate for its age. :-) I have to upgrade many of the underlying data structures. Playing on 19x19 seems pointless at present. Considering that I spent more time reading this forum than I spend writing code, it will probably take a while. :-( My 19x19 engine is much stronger than it was a year ago, while my 9x9 is about the same, so there is a lot of progress to be made in playing go that can't be discovered on 9x9. The improvement in 19x19 Many Faces is quite noticeable. No doubt it is the result of focusing on that aspect. I test against gnugo for a fast opponent to give quick regressions after every change, since I like to play 1000 games or more. This is a common pattern. I should probably do that, at least occasionally. I wonder: is the value dimished when you win 94% of your games? 500 games against Fuego would take the same amount of time and perhaps yield better insight. ___ 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
I'm not sure whether they meant different things when they were first coined, but maybe that doesn't matter, and there are two different approaches that should be distinguished somehow. When a node has been visited the required number of times: 1) Use patterns, heuristics, ownership maps from the earlier playouts through it, etc. to calculate a score for each move. Then rank them from prettier to uglier. At this node, only allow moves within the top N prettiest moves, where N grows slowly with the number of subsequent playouts through the node. 2) Calculate the score, as in 1). Initialize the win/loss record for each move *as if* many more prior playouts had already gone through this node. Prettier moves are initialized as if they had a higher proportion of prior?wins. Typically, it is the win/loss record for RAVE moves that gets this prior adjustment. They can be combined too. If the calculations involved?are expensive, then it is important to hold off until several playouts have gone through the node. Most nodes don't get visited more than once or twice.?If they use something like ownership maps, then, naturally, one has to wait until some data has been gathered. - Dave Hillis -Original Message- From: computer-go-boun...@computer-go.org [mailto:computer-go- boun...@computer-go.org] On Behalf Of Petr Baudis Sent: Tuesday, September 29, 2009 7:07 AM To: computer-go@computer-go.org Subject: [computer-go] Progressive widening vs unpruning Hi! I'm a little unclear on this, so I'd like to make sure I'm not missing any important technique - is progressive widening and progressive unpruning synonymous? I have looked both into the pMCTS and the CrazyStone papers and it seems that widening differs from unpruning in that certain number of simulations is first made before limiting the number of searches. Which of the variants is commonly used? What speed of widening works for you best? Thanks, -- Petr Pasky Baudis A lot of people have my books on their bookshelves. That's the problem, they need to read them. -- Don Knuth ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [SPAM] [computer-go] Progressive widening vs unpruning
hi; I don't know to which extent my terminology is commonly used, but it seems to be close to the distinction by Dave (but not exactly equal). For me I use progressive widening when we add moves, progressively, to the pool of moves which are to be considered; whereas I use progressive unpruning when a score is computed for all moves, with a weight depending on the number of simulations; typically, I consider the Rave formula in GellySilver as a progressive unpruning (with, for prior value, the Rave value). Progressive unpruning is better in MoGo, in spite of the fact that: * with progressive widening, if you apply pure UCB values, you are definitely consistent and explore (asymptotically) all the tree; * with progressive unpruning, if your prior is bad, you might have situations in which the score of the only good move is 0, whereas all bad moves have values going to 0 but 0 and therefore the good move is never simulated (this can, however, easily be patched by a lower bound on the value given by the prior) Progressive unpruning, if you use the same terminology as me, has the advantage that the number of moves to be considered is adapted depending on the score; if you have three reasonnable moves and 300 bad moves, with progressive unpruning you'll visit all moves, whereas progressive unpruning will stay on the three reasonnable moves as long as they provide a better score than the prior score for the 300 bad moves. (The difference with Dave's terminology is that I do not necessarily use a sum of a prior number of simulations and a number of real simulations; I use a weighted sum with weight depending on the number of simulations in a complicated manner - I think this was not the case in the first paper by Chaslot et al about progressive un pruning (well, I believe this is the first paper about progressive unpruning)) Best regards, Oliveir ___ 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
dhillism...@netscape.net wrote: I'm not sure whether they meant different things when they were first coined, but maybe that doesn't matter, and there are two different approaches that should be distinguished somehow. When a node has been visited the required number of times: 1) Use patterns, heuristics, ownership maps from the earlier playouts through it, etc. to calculate a score for each move. Then rank them from prettier to uglier. At this node, only allow moves within the top N prettiest moves, where N grows slowly with the number of subsequent playouts through the node. This is called progressive unpruning or widening. Guillaume and I published the idea independently, and gave it two different names. 2) Calculate the score, as in 1). Initialize the win/loss record for each move *as if* many more prior playouts had already gone through this node. Prettier moves are initialized as if they had a higher proportion of prior?wins. Typically, it is the win/loss record for RAVE moves that gets this prior adjustment. This was first proposed by Guillaume, and called progressive bias. Rémi ___ 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
I guess I'm not really appreciating the difference between node value prior and progressive bias - adding a fixed small number of wins or diminishing heuristic value seems very similar to me in practice. Is the difference noticeable? On Tue, Sep 29, 2009 at 08:25:56AM -0700, David Fotland wrote: I start with one move, and slowly add moves to the pool of moves to be considered, peaking at considering 30 moves. My current schedule looks like: visits0 2 5 9 15 24 38 59 90100 ... 2142 moves 1 2 3 4 5 6 7 8 9 10 ...20 Thanks! On Tue, Sep 29, 2009 at 08:49:22PM +0200, Olivier Teytaud wrote: I don't know to which extent my terminology is commonly used, but it seems to be close to the distinction by Dave (but not exactly equal). For me I use progressive widening when we add moves, progressively, to the pool of moves which are to be considered; whereas I use progressive unpruning when a score is computed for all moves, with a weight depending on the number of simulations; typically, I consider the Rave formula in GellySilver as a progressive unpruning (with, for prior value, the Rave value). Ah, I see; so progressive widening is what David described, modifying the process of choosing node with highest urgency, while what you describe as progressive unpruning is actually just what RAVE and priors are, adding extra terms to the urgency calculation, with diminishing value as the simulation count raises. * with progressive unpruning, if your prior is bad, you might have situations in which the score of the only good move is 0, whereas all bad moves have values going to 0 but 0 and therefore the good move is never simulated (this can, however, easily be patched by a lower bound on the value given by the prior) I found the even game prior (3/6) effective for this problem. Progressive unpruning, if you use the same terminology as me, has the advantage that the number of moves to be considered is adapted depending on the score; if you have three reasonnable moves and 300 bad moves, with progressive unpruning you'll visit all moves, whereas progressive unpruning * progressive widening you'll? will stay on the three reasonnable moves as long as they provide a better score than the prior score for the 300 bad moves. -- Petr Pasky Baudis A lot of people have my books on their bookshelves. That's the problem, they need to read them. -- Don Knuth ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [SPAM] Re: [computer-go] Progressive widening vs unpruning
I guess I'm not really appreciating the difference between node value prior and progressive bias - adding a fixed small number of wins or diminishing heuristic value seems very similar to me in practice. Is the difference noticeable? It just means that the weight of the prior does not necessarily decrease linearly. For example, for Rave, you might prefer to have a weight which depends on both the number of Rave simulations and on the number of real simulations. The formula designed by Sylvain for Rave, for example, can't be recovered without this generalization. For the current mogo, as we have several terms (one for the empirical success rate, one for Rave, one for patterns, one for expert rules...), some of them with used at different places in the code (there is a prior expressed in terms of rave simulations, and a prior expressed as real simulations), it would be complicated to come back to something much simpler ... but perhaps it's possible. Such a clarification might be useful, I have no clear idea of the impact of Rave values now in mogo, in particular for long time settings, and it's not so easy to clarify this point - too many dependencies between the many terms we have. I think someone pointed out a long time ago on this mailing list that initializing the prior in terms of Rave simulations was far less efficient than initializing the prior in terms of real simulations, at least if you have classical rave formulas - at least, we had an improvement when adding a prior in the real simulations, but we had also an improvement when adding one more term, which is not linear. Sorry for forgetting who :-( Olivier ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Progressive widening vs unpruning
I think someone pointed out a long time ago on this mailing list that initializing the prior in terms of Rave simulations was far less efficient than initializing the prior in terms of real simulations. You might be recalling an exchange that I had with Sylvain. I asked how initial bias was implemented in Mogo, and Sylvain replied that either one will work. And that is true, but biasing the UCT values is much more forceful. There are three differences. First, assigning a win (or loss) to a UCT term is more significant than assigning to a RAVE term because RAVE observations are vastly more plentiful. Second, assigning to UCT causes the upper confidence bounds to start at a less optimistic level, which wastes fewer trials on pointless exploration. Third, engines (should) have a policy for flowing UCT scores up the tree along transpositions. Assigning to RAVE does not exploit that capability. That being said, there is a caveat: assignments to UCT should be unbiased estimates of winning percentage. RAVE terms can express other priorities. For example, Pebbles bias in favor of exploring atari can be as large as 24 wins in 24 trials. The bias varies, depending on the situation, but it is never smaller than 9 wins in 9 trials. It is clear that the 24/24 bias (which is given whether winning or not) is not a sensible estimate of winning chances. Nevertheless, the bias works because it favorably changes search behavior. Obviously, you must search atari moves if you don't want to lose. Pebbles' automated parameter tuning system has pushed that parameter up because higher values helped it to win games. I highly recommend reading the Fuego implementation. I believe that it is largely because of well-judged UCT priors that Fuego plays so efficiently with small trials. E.g. Fuego-400nodes rated at 1518 on 9x9 CGOS. That's only 5 trials per empty point! BTW, Pebbles does not do a good job on this issue. Pebbles uses only RAVE biases, though I have known since my exchange with Sylvain that it was a worse choice. Unfortunately, I started on the other implementation, and now all of the priors are unrelated to winning chances. I need to create a new system that evaluates move quality, and I haven't gotten around to it yet. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [SPAM] Re: [computer-go] Progressive widening vs unpruning
Are you sure you are not over-tuning to some opponent, or to self-play? I have a very simple formula, win rate plus rave (with the simpler beta formula), plus the simple upper bound term. I bias the rave simulations only. It seems to work pretty well. Your description sounds pretty complex. David From: computer-go-boun...@computer-go.org [mailto:computer-go-boun...@computer-go.org] On Behalf Of Olivier Teytaud Sent: Tuesday, September 29, 2009 1:26 PM To: computer-go Subject: Re: [SPAM] Re: [computer-go] Progressive widening vs unpruning I guess I'm not really appreciating the difference between node value prior and progressive bias - adding a fixed small number of wins or diminishing heuristic value seems very similar to me in practice. Is the difference noticeable? It just means that the weight of the prior does not necessarily decrease linearly. For example, for Rave, you might prefer to have a weight which depends on both the number of Rave simulations and on the number of real simulations. The formula designed by Sylvain for Rave, for example, can't be recovered without this generalization. For the current mogo, as we have several terms (one for the empirical success rate, one for Rave, one for patterns, one for expert rules...), some of them with used at different places in the code (there is a prior expressed in terms of rave simulations, and a prior expressed as real simulations), it would be complicated to come back to something much simpler ... but perhaps it's possible. Such a clarification might be useful, I have no clear idea of the impact of Rave values now in mogo, in particular for long time settings, and it's not so easy to clarify this point - too many dependencies between the many terms we have. I think someone pointed out a long time ago on this mailing list that initializing the prior in terms of Rave simulations was far less efficient than initializing the prior in terms of real simulations, at least if you have classical rave formulas - at least, we had an improvement when adding a prior in the real simulations, but we had also an improvement when adding one more term, which is not linear. Sorry for forgetting who :-( Olivier ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Testing Process
I haven't tested this, but my feeling is that it's better to test against gnugo because it doesn't use uct/mc, so it has a very different style. But mainly, I'm all set up with automated gnugo testing and it would take some number of hours to convert to fuego. There is always something to code and try that I would rather work on. My gnugo regression in on 19x19, so I'm only winning about 85% (with 10K playouts per move). David I test against gnugo for a fast opponent to give quick regressions after every change, since I like to play 1000 games or more. This is a common pattern. I should probably do that, at least occasionally. I wonder: is the value dimished when you win 94% of your games? 500 games against Fuego would take the same amount of time and perhaps yield better insight. ___ 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
This sounds like progressive widening, but it could still be progressive unpruning, depending on implementation choices. I do both. I have a small pool of moves that are active and I also bias the initial rave values. My current schedule looks like: 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. if you are just using RAVE to do move ordering you might need to widen faster. I recall that you credited the use of Many Faces rules with a massive improvement against GnuGo, so the technique is certainly empirically justified. But I am wondering how it achieves its results. That is, what do you think the difference is, compared to standard unpruning? There is a rule that I live by, which is GG SS. This rule (really a universal law, when you get right down to it) states that a Good Guess is much better than a Short Search. Agreed. That's why I always prefer to add knowledge rather than tinker with search parameters. So is the benefit that MF avoids wasting trials on moves that were just lucky in early trials, but probably will not stand up? I think it's more that Many Faces values moves that have good long-term consequences that the search can't find, so among moves with similar win rates, it will choose the ones Many Faces prefers. Or sometimes I think that UCT/MC is filling in the holes where Many Faces' knowledge is incorrect or brittle. I am also wondering whether you could achieve the same effect by using pure progressive unpruning, but with a heavier weight (e.g., 100 trials) for Many Faces opinion. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
