Re: [computer-go] Grid Cosmos
Hi Yoshii I have some questions about your program. 1. Is this a complete go engine? I have renamed the gnugo.exe file in the /exe directory and the program no longer works. If it is not an engine, what is it? 2. The program has a 368 Mb file named Tree_Set in the /exe directory, the pattern library, I presume. The source code is 4 Mb resources included. I imagine that if that file has any sources, they are not included, or is that file the result of some computing? Are your patterns learned from games? 3. How strong is your program? 4. Why did you choose .net? (I don't expect an answer to this. I wouldn't understand anyway. I never understood the need of Java, much less that of an incompatible clone. I can only imagine reasons against. And sooo many!) Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Grid Cosmos
I'll host it for you here in the US. -Josh On 3/9/07, 吉井裕人 <[EMAIL PROTECTED]> wrote: sorry... I forgot to add some important information. As you wrote, the program needs .NET framework 2.0 and has a big size. The big size (over 150MB) is due to a big pattern dictionary size. 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. So I couldn't think about this inconvenience. Now I'm going to put the program in the free software download site (http://www.vector.co.jp). But it will take a few weeks and the site is Japanese. If you know a good international download site, please inform me! Again, I'm sorry the download trouble. 07/03/10 に igo<[EMAIL PROTECTED]> さんは書きました: > Maybe you should inform us that it is a big file (161MB!) > and needs .Net Framework(v2.0.50727) to execute. > > I spent several times to download it, and find nothing I can do, > and get an unpleasant feeling, and write this mail. > > igo > > > --- > "吉井裕人" <[EMAIL PROTECTED]> wrote: > > > Hello, > > > > I'm Hiroto Yoshii. > > > > I developed a new Go program "Grid Cosmos". > > The program uses pattern recognition and SlugGo like routine. > > (Now I'm submitting a paper to AAAI-07, so I can't describe > > the algorithm in detail. But it is open source software.) > > > > Please download and try it! > > (http://www.grid-cosmos.com) > > > > If you have Quad Core processor, try parameter > > > > or > > The program becomes considerably strong. > > ___ > > 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/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: A nearest-neighbor heuristic
Hmmm -- p. 735 of Russell & Norvig's AI text contains a strong argument that "nearest-neighbor methods cannot be trusted for high- dimensional data". Peter Drake http://www.lclark.edu/~drake/ On Mar 7, 2007, at 9:38 PM, Peter Drake wrote: First, a general hypothesis on heuristics: one should apply heuristics to the first few moves beyond the fringe of the UCT tree, and not later. It's important that these early moves be good, but not worth the time to make later moves good. Thoughts? Is anyone already using this idea? Now, a specific heuristic I'd like to try. If anyone can point out anything horribly wrong with it before I go to the trouble to implement it, that'd be nice. :-) Maintain a set of if-then rules, perhaps 1000 of them. Each rule consists of a board configuration and a suggested move. (Originally, they're all identically [ => E5] for 9x9.) As the game progresses, this population of rules will change. When it's time to heuristically choose a move, compare the current board configuration against the "if" part of each rule. Play the move from the closest match (nearest neighbor). There's room for creativity in the definition of nearness, but something like Hamming distance might suffice. The population of rules is updated during the game. We might do this, for example, whenever a move becomes the best move from its UCT node. (Note that I'm using "best" here to mean "most likely to win" and not "highest UCT value".) When this happens, ask the population what it would do given this board configuration. If the answer is the move in question, do nothing. Otherwise, overwrite the oldest rule with a new rule suggesting this move for this configuration. My hope is that this heuristic will suggest the move that has been most effective on similar boards. Peter Drake http://www.lclark.edu/~drake/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
