Re: [computer-go] scalability analysis with pachi
Oh, ok. I was a bit surprised. Last time I checked my program scaled quite nicely against GnuGo, at least for low numbers of simulations up to about 97% winning rate. I suppose there could be some kind of plateau when nearing 100% due to some missing knowledge/skills that only GnuGo has. Erik 2010/1/16 dhillism...@netscape.net: Well, I thought there seems to be a picture emerging was sufficiently hedged that it would be construed as a conjecture, not a conclusion. :) I am thinking, in particular, of the scalability studies with Zen that Hideki reported to this list in Oct. 2009. BTW, recently I've measured the strength (win rate) vs time for a move curves with Zen vs GNU Go and Zen vs Zen (self-play) on 19 x 19 board. Without opening book, it saturates between +400 and +500 Elo against GNU but doesn't upto +800 Elo in self-play. That's somewhat interesting (detail will be open soon at GPW-2009). Hideki There was a bit more information provided in a sequence of posts to this list during that month. I wonder if the paper is out now. - Dave Hillis -Original Message- From: Erik van der Werf erikvanderw...@gmail.com To: computer-go computer-go@computer-go.org Sent: Sat, Jan 16, 2010 12:55 pm Subject: Re: [computer-go] scalability analysis with pachi 2010/1/15 dhillism...@netscape.net Thank you for posting these interesting results There seems to be a picture emerging that MCTS engines scale very well in self play, and apparently against other MCTS engines, but not so well against the non-MCTS version of Gnugo. - Dave Hillis Do you have any data to back that conclusion? Erik ___ 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] Re: [SPAM] [computer-go] Paper about Mogo's Opening Strategy
I'm sure many people are curious - MoGo(TW?) doesn't participate much in computer tournaments nowadays, are you working on some new exciting things or is the project mostly asleep right now? :-) Competitions are very boring and time consuming. Other people from the mogo-team can participate in tournaments if they want to, but for me I prefer to work on improvements, and in particular I prefer to try big changes (which fail 97% of the time) than small changes which provide negligible improvements. When there are computations every 2 months, the small improvements often take all the place. There are works in progress around MoGo: - We'd like to have an almost solving of 9x9 Go, by working in particular on a huge opening book. Nonetheless, there's still a lot of work on that. For example, MoGoTW can play very stupid move if the opponent makes a stupid opening move, and removing this would be great. - As many people, we would really like to have learning from one branch of the tree to another. We have some things which provide a few percents improvements, but we are a bit tired of this kind of small improvements, and I'd like a big change. - Also, we have many applications in progress in other fields, from classical artificial intelligence tasks (like expensive optimization or active learning) or for completely industrial tasks (like my favorite application, namely power management) - We also try to automatize the building and validation of patterns or UCT formula - something which is important far beyond Go. However, for Go, this is clearly not very important - mogo and all strong programs are by far too optimized for improving a lot by empirical tuning. For partially observable games, things are very different I think - as pointed out in some nice papers tuning becomes the main thing in very difficult frameworks like partially observable games, making them quite interesting as a benchmark. I guess some of these goals are shared by many people in this mailing list, so I'm sorry for this long email with probably nothing very original in it :-) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [SPAM] Re: [computer-go] Paper about Mogo's Opening Strategy
Apparently an opening book cannot be used with a stronger or weaker Go player as-is, but I wonder how useful it would be as a seed? If we follows the fictitious play algorithm, maybe we should accept a modification of the opening book only after comparison with *all* previous versions of the OB. However it is quite time consuming... may be there's nothing faster than that... ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [SPAM] Re: [SPAM] [computer-go] Paper about Mogo's Opening Strategy
Hi! On Sun, Jan 17, 2010 at 04:02:38PM +0100, Olivier Teytaud wrote: I'm sure many people are curious - MoGo(TW?) doesn't participate much in computer tournaments nowadays, are you working on some new exciting things or is the project mostly asleep right now? :-) Competitions are very boring and time consuming. Other people from the mogo-team can participate in tournaments if they want to, but for me I prefer to work on improvements, and in particular I prefer to try big changes (which fail 97% of the time) than small changes which provide negligible improvements. When there are computations every 2 months, the small improvements often take all the place. I understand this sentiment a bit. :) I've found that when working on big new things, the required infrastructure changes bring improvements even to the original engine, but that's probably only true in very modular designs and for young programs like mine, not very evolved ones like Mogo. But looking backwards, I also wish I'd spend less time fine-tuning playout strategies etc. and focus on more fundamental changes. - As many people, we would really like to have learning from one branch of the tree to another. We have some things which provide a few percents improvements, but we are a bit tired of this kind of small improvements, and I'd like a big change. Yes, I'm personally convinced that solving this really well will lead to the next big advance in Computer Go. I'm working hard on this problem as well. ;-) - Also, we have many applications in progress in other fields, from classical artificial intelligence tasks (like expensive optimization or active learning) or for completely industrial tasks (like my favorite application, namely power management) This is very interesting, do you have pointers to any papers or presentations concerning MCTS applications like this in any detail? If not yet, I'm sure many people on this list will be interested to hear about any publications in this area too when you finish some of the applications. Thanks, Petr Pasky Baudis ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [SPAM] Re: [SPAM] Re: [SPAM] [computer-go] Paper about Mogo's Opening Strategy
This is very interesting, do you have pointers to any papers or presentations concerning MCTS applications like this in any detail? If not yet, I'm sure many people on this list will be interested to hear about any publications in this area too when you finish some of the applications. 1) Application to fundamental AI tasks: Application to noisy non-linear optimization (Algorithmica 2009): http://hal.inria.fr/inria-00369788 (personnally, this work convinced me that UCT was really a great algorithm - for noisy applications, UCT really brings an improvement over many forms of MCTS, and as I've spent a long time trying to solve the same thing with other tools without success, I've been very surprised of succeeding at the first trial with UCT) Application to non-linear optimization: http://hal.inria.fr/inria-00374910/fr/ Application to active learning (ECML 2009) http://hal.inria.fr/inria-00433866 2) Benchmarks on problems not too far from industry: - Guillaume Chaslot et al published something around stock management - Martin Müller et al published something around planning 3) Directly real-world or industrial applications Application to library tuning (ICML 2009) http://hal.inria.fr/inria-00379523/ The application to energy management is a big concern to me - it's in progress. These problems have a huge ecological and economical importance, it would really be great if computer-Go had an impact on this, and the specificities of the problem are perfect - withing the partially observable nature of the problem :-) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Request for reading material
Hi, I have been reading this mailing list for some time as the subject interests me. I have a request - can anyone provide a reading list of books or web pages which would introduce me to the science of artificial intelligence such as would be employed in writing a computer go program? Alan Cameron ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] benchmark tests for static evaluation functions
Last year I was working on a static evaluation function. Does anyone know references about published benchmark tests for static evaluation functions, for example, in predicting moves in professional games or best moves in life and death problems or predicting the status of semeai problems? The published benchmarks need not be for a static evaluation function in the traditional sense, they could be for an opening book or a MCTS program with very short times available. Thanks, Thomas Wolf ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] benchmark tests for static evaluation functions
I think you can only evaluate static evaluation in the context of a search and a tournament between programs. You could start with a simple 1-ply search and play against gnugo. Strength in life and death or predicting pro moves doesn't correlate with the ability to win games. David -Original Message- From: computer-go-boun...@computer-go.org [mailto:computer-go-boun...@computer-go.org] On Behalf Of Thomas Wolf Sent: Sunday, January 17, 2010 9:03 AM To: computer-go@computer-go.org Subject: [computer-go] benchmark tests for static evaluation functions Last year I was working on a static evaluation function. Does anyone know references about published benchmark tests for static evaluation functions, for example, in predicting moves in professional games or best moves in life and death problems or predicting the status of semeai problems? The published benchmarks need not be for a static evaluation function in the traditional sense, they could be for an opening book or a MCTS program with very short times available. Thanks, Thomas Wolf ___ 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] Request for reading material
Alan Cameron wrote: introduce me to the science of artificial intelligence such as would be employed in writing a computer go program? I am not sure if it is what you are asking for but maybe it is: Search for the following topics: - computational complexity - algorithm Once you are familiar with these as well as basic programming paradigms (as dull as divide and conquer), you might wish to look for topics specific to artificial intelligence like, e.g., expert system. -- robert jasiek ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] scalability analysis with pachi
Yes. And while worrying about what happens after a win rate of 97% sounds like splitting hairs, I think we're talking about an awkward way of measuring something that's of practical interest. Suppose Hideki's experiment were repeated, giving GNU GO a four stone handicap. If Zen plateau'd out at the same time-per-move, that would suggest a real limit in strength improvement against dissimilar opponents. If Zen plateau'd out at the same ELO point, that might suggest that a few percent of the games involved tactical situations that GNU GO could understand but Zen couldn't, even with much more time. The second possibility could be tested more efficiently by Zen taking the handicap. - Dave Hillis -Original Message- From: Erik van der Werf erikvanderw...@gmail.com To: computer-go computer-go@computer-go.org Sent: Sun, Jan 17, 2010 8:06 am Subject: Re: [computer-go] scalability analysis with pachi Oh, ok. I was a bit surprised. Last time I checked my program scaled uite nicely against GnuGo, at least for low numbers of simulations up o about 97% winning rate. I suppose there could be some kind of lateau when nearing 100% due to some missing knowledge/skills that nly GnuGo has. Erik 010/1/16 dhillism...@netscape.net: Well, I thought there seems to be a picture emerging was sufficiently hedged that it would be construed as a conjecture, not a conclusion. :) I am thinking, in particular, of the scalability studies with Zen that Hideki reported to this list in Oct. 2009. BTW, recently I've measured the strength (win rate) vs time for a move curves with Zen vs GNU Go and Zen vs Zen (self-play) on 19 x 19 board. Without opening book, it saturates between +400 and +500 Elo against GNU but doesn't upto +800 Elo in self-play. That's somewhat interesting (detail will be open soon at GPW-2009). Hideki There was a bit more information provided in a sequence of posts to this list during that month. I wonder if the paper is out now. - Dave Hillis -Original Message- From: Erik van der Werf erikvanderw...@gmail.com To: computer-go computer-go@computer-go.org Sent: Sat, Jan 16, 2010 12:55 pm Subject: Re: [computer-go] scalability analysis with pachi 2010/1/15 dhillism...@netscape.net Thank you for posting these interesting results There seems to be a picture emerging that MCTS engines scale very well in self play, and apparently against other MCTS engines, but not so well against the non-MCTS version of Gnugo. - Dave Hillis Do you have any data to back that conclusion? Erik ___ 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/ __ omputer-go mailing list omputer...@computer-go.org ttp://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] scalability analysis with pachi
Yes. And while worrying about what happens after a win rate of 97% sounds like splitting hairs, I think we're talking about an awkward way of measuring something that's of practical interest. Yes. How can a program be strong enough to win 97% and not win 100%. Over on the fuego list Martin Mueller discovered some interesting test positions (e.g. only winning move is playing inside your own benson-safe region, IIRC) by looking at games where fuego lost against weaker opponents. An addition to CGOS that shows Biggest Upsets Of The Month, excluding losses on time, would be an interesting way to build up a test suite. I don't know if that is a trivial SQL query for Don, or something harder though. Darren ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Pachi/fuego GnuGo hybrid
Has anyone tried doing pachi/Fuego + GnuGo hybrid slightly in way Many FAces is done? If I understood correctly Manyfaces is mostly a plausible move generator. And serac is widened via the RAVE. So simplest hybrid could rather simple words that often used before huge effort taking for ever. When a new node is initialized: Contact GnuGo using GTP and load situation, send genmove, send topmoves and you have a starting point for simulations. Obviously this is not what GG was designed for and will do loads of overhead but could be interesting. I would have tried I but I could not get Pachi to compile under Cygwin and currently I do not a linux machine. Also Fuego had some problems building under cygwin -and has steeper learning curve. Also it would slow under cygwin. At least Pachi multicore due to threading. Petri ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
