Re: [computer-go] JFFoS + Criticality Heuristic + Parameter Optimization
Hi Remi, Thanks for the reply. There are so many parameters to tune and heuristics to try, and having two types of search (playouts and the MCTS) doubles the number of knobs! (More than doubles, as there is the interaction to consider too.) I did not try your position. But understanding seki is mostly a matter of playout policy. I do not use criticality in playouts. Crazy Stone already understands seki in playouts. Was there a reason in not using criticality as a guide in playouts too? Or just lack of time to experiment with it? Darren ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to properly implement RAVE?
On Feb 2, 2009, at 6:57 AM, Isaac Deutsch i...@gmx.ch wrote: Hi Issac, You should be more in the range of +200-300 ELO, at least with pattern based playouts. Sylvain Isaac. They are not pattern based playouts, but as I said uniformly random. I reckon the effect of RAVE is less with these? How many playouts per second do you get with each version? Actually, to make comparable tests with both versions, the version without RAVE just sets the coefficient of RAVE in the UCT-RAVE value calculation to zero. I get about 41k games/s on 9x9 (using 2 cores, about 20k/s/ core). The playouts are fairly optimized but the tree search isn't at all yet, so there is still some potential. My first (braindead) multi-threaded UCT played weaker with two cores than one core. How do you combine search trees/results? How do you pick a move to play? Single-threaded RAVE with no parameter tuning, an ancient RAVE formula, and 10k light playouts per second got me into the 1600's on CGOS. I used Don Dailey's AMAF methodology for RAVE (first color to play on a point, keep 7/8 of move list). Also, I noticed your rank measurements were based on CGOS results after relatively few games. It can retain significant bias for quite a while. -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T45 69a ___ 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] How to properly implement RAVE?
On Feb 2, 2009, at 9:40 AM, Jason House jason.james.ho...@gmail.com wrote: On Feb 2, 2009, at 6:57 AM, Isaac Deutsch i...@gmx.ch wrote: Hi Issac, You should be more in the range of +200-300 ELO, at least with pattern based playouts. Sylvain Isaac. They are not pattern based playouts, but as I said uniformly random. I reckon the effect of RAVE is less with these? How many playouts per second do you get with each version? Actually, to make comparable tests with both versions, the version without RAVE just sets the coefficient of RAVE in the UCT-RAVE value calculation to zero. I get about 41k games/s on 9x9 (using 2 cores, about 20k/s/ core). The playouts are fairly optimized but the tree search isn't at all yet, so there is still some potential. My first (braindead) multi-threaded UCT played weaker with two cores than one core. How do you combine search trees/results? How do you pick a move to play? Single-threaded RAVE with no parameter tuning, an ancient RAVE formula, and 10k light playouts per second got me into the 1600's on CGOS. I used Don Dailey's AMAF methodology for RAVE (first color to play on a point, keep 7/8 of move list). Actually, that rating was probably using my own home-grown RAVE formula. Sorry for the misinformation. Also, I noticed your rank measurements were based on CGOS results after relatively few games. It can retain significant bias for quite a while. -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569 a ___ 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] MC and Japanese rules
I think I've seen people post about playing with Japanese rules in relation to MC programs. Correct me if I'm wrong, but I think I saw people do some adjustment in that case. Does that mean they actually use Chinese scoring internally? Mark ___ 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: I think I've seen people post about playing with Japanese rules in relation to MC programs. Correct me if I'm wrong, but I think I saw people do some adjustment in that case. Does that mean they actually use Chinese scoring internally? Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ Yes. The recipe is: - play as usual with Chinese rules, - take a one-point security margin with respect to komi, - pass as soon as the opponent passes. You also have to be careful to score seki the Japanese way in the playouts. This is the most difficult part. If your playouts don't understand seki, then you can just ignore seki, or take more than one point of security margin if you wish to be safe. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Rules for remote play at the Computer Olympiad
Nick Wedd wrote: I would like to se the time measurement done in the client. I find it odd that cheat-proof client-side time is now standard for chess servers, but too difficult for any Go server to implement. In case of big network lag, client-side time may make the game too long. The best solution is to connect to a local server. It would have no time lag. The UEC Cup uses NNGS: http://jsb.cs.uec.ac.jp/~igo/2008/eng/network.html I suppose they have an adapter for gtp programs. The advantage of playing on KGS is that it provides live relay of the tournament on the net, which may attract spectators. But having to rely on KGS for the tournament is much too dangerous, especially because of network lag, and the risk of network failure. From my point of view, the ideal solution would be a local official server, with a live relay of the games on the web. Live relay may be done automatically, with a little work to program relay bots. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to properly implement RAVE?
Wow, thanks for all the answers! You're being really helpful. Do you use UCT with a too large exploration term? That's a good idea. I actually use a rather big value for c=0.5. I might try lowering it. Thanks! (Precisely, the formula is c*sqrt(log(p)/c).) My first (braindead) multi-threaded UCT played weaker with two cores than one core. How do you combine search trees/results? How do you pick a move to play? I have the threads write to a global array (of course one after another that stores the values and the numbers of games played (each thread adds to these values) of the first ply. I then pick the move with the most games played through that node. The value of this best move (sum/numplayed) determines if the bot should resign. Yes, and you should go by the bayeselo page which is a better picture of what is going on. The ELOs posted here refer to these values. I don't think many people realize that you have to play hundreds of games just to be within 40 or 50 ELO with much certainty. If you play less than 100 games you could easily be off by over 100 ELO. Maybe I'm a bit (a lot :) impatient, but I try to make a rough guess after about 150-200 games, which is about 1-2 days of letting the program run on the server. I think it's possible to say after 150 games that RAVE did not give me a 300 ELO boost. Thanks again, Greetings, Isaac -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to properly implement RAVE?
On Mon, 2009-02-02 at 18:09 +0100, Isaac Deutsch wrote: I don't think many people realize that you have to play hundreds of games just to be within 40 or 50 ELO with much certainty. If you play less than 100 games you could easily be off by over 100 ELO. Maybe I'm a bit (a lot :) impatient, but I try to make a rough guess after about 150-200 games, which is about 1-2 days of letting the program run on the server. I think it's possible to say after 150 games that RAVE did not give me a 300 ELO boost. You already reported 75 ELO improvement. Gelly said you should get 200-300. So you are only about 125 off of Gelly's lower bound (which sounded like a rough guess to me.) So you have a lot of uncertainty here and only 150 games. Of course this is plenty enough to suspect a problem and investigate, but it's not enough to conclude that you surely did something wrong. How much did you test the version that doesn't have this change? You have 3 sources of slop here: 1. Gelly's rough estimate of how much you should get. 2. The rating uncertainty of the unmodified program. 3. The rating uncertainty of the modified program. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Rules for remote play at the Computer Olympiad
About the thinking process log. Enabling debugging options can result in serious performance loss. In my system only the admin thread can do such things as tree dumps and that makes all other pawn threads idle. I don't think such preventive measures are justified. In case of doubt, it should be enough if the author can show that the program can repeat any suspectful move (even if it does not always play the same move, the played move should at least be among the best). If the program is local that should be enough. Remote programs cannot be controlled anyway. I think adding constraints to local programs makes the unfairness vs remote programs even worse. In case something has to be implemented it must be announced in advance. Questions: 1. What are the time settings for 19x19? 2. What are the days for 19x19? 3. Is hardware available from the organizers? At least, monitors and keyboards to avoid flying with non-critical and voluminous equipment. Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] JFFoS + Criticality Heuristic + Parameter Optimization
Darren Cook wrote: Was there a reason in not using criticality as a guide in playouts too? Or just lack of time to experiment with it? No particular reason, except maybe that it would be difficult to do, and I do not really know how to implement it. I am convinced that the idea of criticality has much more potential than what I did. It is certainly possible to use it better. Rémi // ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to properly implement RAVE?
I have about 200-300k games/move, so maybe the effect is even less. But, maybe I still have a grave bug somewhere. I will check again. Cheers, ibd On Feb 2, 2009, at 9:57 AM, Isaac Deutsch wrote: They are not pattern based playouts, but as I said uniformly random. I reckon the effect of RAVE is less with these? My MCTS implementation sees a gain of 200-400 ELO from RAVE using uniformly random moves. 400 gain (90% win-rate) for 2K playouts, becoming slowly less for larger numbers of playouts. Mark -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] stone-age and patterns
I haven't gotten very far yet in incorporating many of the suggestions
published on this mailing-list into the MCTS ref-bot. As such I feel I
still have a lot of catching up to do when it comes to MC programs,
mostly due to lack of time.
But I had an idea I wanted to share as I haven't seen anything like it
described here. It comes forth from an observation I had when looking
at playouts and what effects some of the patterns had on it. So far
it's my opinion that guiding playouts is mostly useful in order to
maintain certain features of the original position and prevent the
random walk from stumbling into an unreasonable result. As an example
I'm going to use the simple case of a stone in atari that cannot
escape. When random play tries an escaping move, I make the program
automatically play the capturing move to maintain the status of the
stone(s) (now more than one) in atari. When implementing something
like that in the playouts however, more often than not this 'pattern'
arises not based on the original position but purely from the random
play. I figured it doesn't help the program at all trying to maintain
the captured status of a stone or stones that weren't even on the
board at the start of the playout.
So I tried a simple experiment: whenever a single stone is placed on
the board I record the time (move-number really) it was created in an
array I call stoneAge. When more stones are connected to the original
they get the same age. When two chains merge I pick an arbitrary age
of the two (I could have picked the smallest number, but it doesn't
really matter). So for each chain of stones the array marks the
earliest time of creation. Next, when a playout starts, I mark the
starting time in a variable I call 'playoutStart' and there's a simple
function:
boolean isPrehistoric(int chain)
{
return stoneAge[chain]=playoutStart;
}
During playout, I only apply the tactical reader to chains for which
the isPrehistoric() function returns true. Tests show that using this
method doesn't affect the strength of the program at all. But the
amount of time spent in the tactical reader is cut in less than half.
I'm suspecting the same holds true to a large degree for other
patterns, but I haven't had the time yet to test that. Other cases may
not provide as much gain because they are cheaper to compute. But I
think in general it's better to let the random play run its course as
much as possible and restrict moves guided by patterns as much as
possible to situations relevant to the original position. The stone-
age information is very cheap to maintain so it's hardly a burden to
use.
Hope this helps anyone, especially those with slow tactical readers :)
If anyone manages to use this successfully in other situations than
tactical readers I'd be interested to hear it, as so far it's only a
hunch that this has wider applicability than just tactics. I was going
to wait until posting this until I had time to try it out for myself
but lately I didn't have the time.
Mark
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Rules for remote play at the Computer Olympiad
In message 262b2f900902010529r2ddec4afq31705bd9ccfda...@mail.gmail.com, Erik van der Werf erikvanderw...@gmail.com writes snip Something else for the discussion. I would like to have a rule about mandatory displaying the thinking process of the program so that both operators have an idea of what is happening. Especially for remote play I think this is needed because now it is just too trivial to cheat. I understand the need to try to avoid cheating. But I am sceptical about the effectiveness of this method. 1.) A neural net cannot explain its thinking process because it does not have any. 2.) It would still be too easy to cheat. The cheater could run a program which looks at the position and generates a plausible display of its thinking process, while a professional player thinks and then tells it where to play. Then the program generates more display of thinking process tending to support the recommended move, before playing it. snip Nick -- Nick Weddn...@maproom.co.uk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Rules for remote play at the Computer Olympiad
In message 4985a9b2.7090...@univ-lille3.fr, Rémi Coulom remi.cou...@univ-lille3.fr writes Erik van der Werf wrote: Hi Remi, There is a simpler solution: do not allow remote play at all. I would be in favor of this solution. But this has no chance to make unanimity. Even with a strong majority in favor of that rule, Jaap would probably not accept it, anyways. As for stricter time controls; in principle I'm in favor. However, if you really want to enforce it we should have a real clock on the table like they have in the WCCC games. This would of course constitute a significant change from the usual relaxed (sloppy?) playing conditions... I believe we can still trust participants to count time correctly. Having to use a real clock is too annoying. I don't believe it. I have come across a program that got this seriously wrong. When it received its opponent's move, it then (1) updated its board state, (2) started its clock running, (3) thought about where to play. For the first 30 moves or so of a game, step (1) was imperceptible. By move 200, step (1) was taking it over a minute per move. This was not cheating, it was just incompetent programming. I would like to se the time measurement done in the client. I find it odd that cheat-proof client-side time is now standard for chess servers, but too difficult for any Go server to implement. Nick The best solution regarding time control is probably what is done in the UEC Cup and EGC: connect programs to a server and let the server do time control. For a 3-round playoff I would propose that the third game uses komi bidding (one operator is given the right to choose the komi, and the other then chooses whether to play Black or White). An alternative is to play 4 rounds and use board-points as a tie-breaker. I am strongly against board-points as a tie-breaker. Most MC programs only optimize probability of winning. In any case, I think the 9x9-komi should go back to 6.5. I think it was moved to 7.5 to allow automated play on KGS. I believe allowing automated play on KGS with a strange komi is better than having no KGS play and a normal komi. Rémi -- Nick Weddn...@maproom.co.uk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to properly implement RAVE?
On Mon, 2009-02-02 at 09:40 -0500, Jason House wrote: Also, I noticed your rank measurements were based on CGOS results after relatively few games. It can retain significant bias for quite a while. Yes, and you should go by the bayeselo page which is a better picture of what is going on. I don't think many people realize that you have to play hundreds of games just to be within 40 or 50 ELO with much certainty. If you play less than 100 games you could easily be off by over 100 ELO. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to properly implement RAVE?
On Feb 2, 2009, at 12:09 PM, Isaac Deutsch i...@gmx.ch wrote: Wow, thanks for all the answers! You're being really helpful. Do you use UCT with a too large exploration term? That's a good idea. I actually use a rather big value for c=0.5. I might try lowering it. Thanks! (Precisely, the formula is c*sqrt(log(p)/c).) That formula is wrong. Did you mean to have a denominator of c? My first (braindead) multi-threaded UCT played weaker with two cores than one core. How do you combine search trees/results? How do you pick a move to play? I have the threads write to a global array (of course one after another that stores the values and the numbers of games played (each thread adds to these values) of the first ply. I then pick the move with the most games played through that node. The value of this best move (sum/numplayed) determines if the bot should resign. That sounds a lot like what I did (two independent searches that are combined when genmove is called). I believe that strategy had a 100+ ELO loss in strength for me. I'm not sure why that was the case (but have some theories). You may want to experiment with one search thread to see if it hurts your performance too. Yes, and you should go by the bayeselo page which is a better picture of what is going on. The ELOs posted here refer to these values. I don't think many people realize that you have to play hundreds of games just to be within 40 or 50 ELO with much certainty. If you play less than 100 games you could easily be off by over 100 ELO. Maybe I'm a bit (a lot :) impatient, but I try to make a rough guess after about 150-200 games, which is about 1-2 days of letting the program run on the server. I think it's possible to say after 150 games that RAVE did not give me a 300 ELO boost. Ofline testing should be faster... Thanks again, Greetings, Isaac -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T45 69a ___ 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] How to properly implement RAVE?
On Feb 2, 2009, at 9:57 AM, Isaac Deutsch wrote: They are not pattern based playouts, but as I said uniformly random. I reckon the effect of RAVE is less with these? My MCTS implementation sees a gain of 200-400 ELO from RAVE using uniformly random moves. 400 gain (90% win-rate) for 2K playouts, becoming slowly less for larger numbers of playouts. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to properly implement RAVE?
Hi Issac, You should be more in the range of +200-300 ELO, at least with pattern based playouts. Sylvain Isaac. They are not pattern based playouts, but as I said uniformly random. I reckon the effect of RAVE is less with these? How many playouts per second do you get with each version? Actually, to make comparable tests with both versions, the version without RAVE just sets the coefficient of RAVE in the UCT-RAVE value calculation to zero. I get about 41k games/s on 9x9 (using 2 cores, about 20k/s/core). The playouts are fairly optimized but the tree search isn't at all yet, so there is still some potential. -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Rules for remote play at the Computer Olympiad
On Mon, Feb 2, 2009 at 11:25 AM, Nick Wedd n...@maproom.co.uk wrote: 1.) A neural net cannot explain its thinking process because it does not have any. I have used artificial neural nets a lot in my go programs; it is trivial to display predictions, but understanding them is of course not always easy. Still I probably would not have a hard time to explain the Tournament Director how it arrives at those predictions. I do not agree with your statement that a neural net has no thinking process. 2.) It would still be too easy to cheat. The cheater could run a program which looks at the position and generates a plausible display of its thinking process, while a professional player thinks and then tells it where to play. Then the program generates more display of thinking process tending to support the recommended move, before playing it. True, but at least it requires some programming effort. I don't believe we can rule out all possible forms of cheating (this can even be done when playing locally using a simple wireless link) but we can at least try to make it a bit of a challenge. BTW, when there is a clear suspicion the author can already be forced to show his code to the TD or some trusted independent party. Erik ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to properly implement RAVE?
My first (braindead) multi-threaded UCT played weaker with two cores than one core. How do you combine search trees/results? How do you pick a move to play? There were a couple of papers [2] at CG2008 on this subject. The consensus seemed to be that root parallelization [1] was best. In fact Guillaume Chaslot's version got a strength speedup of 3.0 using 2 threads, and 6.5 using 4 threads (dropping to 14.9 with 16 threads). This is of course impossible, and implies the parallel version is somehow doing MCTS better than the single thread algorithm! Darren [1]: Build multiple MCTS trees in parallel, one per thread. No communication. At end add the trees together and use grand total to select move. [2]: http://www.cs.unimaas.nl/g.chaslot/papers/parallelMCTS.pdf and A Parallel Monte-Carlo Tree Search Algorithm by Tristan Cazenave (I couldn't seem to find a PDF link.) -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
