Re: [computer-go] Re: Open source real time Go server
On Fri, Jan 22, 2010 at 1:46 AM, Stefan Kaitschick wrote: >> 2010/1/19 terry mcintyre : >> ( I recall a pro making >>> >>> such an observation; I was willing to accept his expertise on the matter. >>> ) >> >> Any pro making such a comment at move 10 is just grand-standing. I >> have experienced pros making such comments too. You can let such a >> remark pass out of politeness of course, but accepting it because of >> his presumed expertise is extremely naive IMO. I would even be >> suspicious of pros making such comments at move 150. >> >> Mark > > If a pro predicts a half-point win early in the game, that is obviously bs. > But maybe we are just taking his words too literally. > I think it's actually a bigger problem at move 150. > Because at that point he is making a (very shaky) claim to truth. > I just hate the Go-World commentaries where the narrative has one side > making 3 catastrophic mistakes > and the other side coasting to an unshakable 1.5 point win. I always interpreted such statements differently. I'm aware that in some contexts betting on the outcomes of go and other games is very common. I had assumed that such statements were an indication that the speaker would be making a bet along those lines, it the option were available. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fwd: [gnugo-devel] (GNU) Open source real time Go server
On Mon, Jan 18, 2010 at 11:14 PM, Petr Baudis wrote: > (i) IGS is derivation of NNGS, which is free software (GPLv2)! It has > even seen some slight development in past few years. > ... As tempting as it is, I find it unlikely that incremental improvements on the current crop of servers / server protocols is likely to attract a critical mass of developers. Far more interesting (from my point of view) would be to throw out the current protocol approach and build a new protocol based on Jabber / XMPP / Google Wave (which are essentially the same thing). The beauty of this approach is that it outsources several issues that the current approach struggles with (i18n, security, timing, authentication, account maintenance, etc) to groups who appear to know what they're doing. Of course, developing for such a platform would be significantly more complex, but with such a protocol you can even imagine disaggregating the server into constituent parts based roles in a traditional tournament: game-organiser / match-maker; time keeper; adjudicator; record-keeper; etc. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Open source real time Go server
On Mon, Jan 18, 2010 at 9:21 PM, Dave Dyer wrote: > > Back up a bit - what's your primary interest ? I can readily believe that > not many "near blind" play Go on the internet now, but what makes you believe > a properly supportive server would bring them out of the woods, or that FSF > would be interested in supporting it? And if so, why must it be open source? I think a fully-fleshed-out vision would need to be developed before going any further. There's lots of things that the current crop of servers don't offer, but finding an ordered set to rally people around is non-trivial. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Selling a computer go program
(a) Much software downloadable from the internet is legal (think gGo, GnuGo, linux, etc), therefore downloading it from the internet is not necessarily piracy. (b) Most of the sums of money I've seen for competitions are trivial (except the Ing Prize). This might easily change if/when computer go programs reach high dan level. (c) There is a large market for Go equipment. I've been told that go sets are Nintendo's #1 selling product line. I've never bought go equipment in asia, but the market seems huge. (d) If I woke up tomorrow with a winning go program, I'd be tempted to market it as a service. There certainly seems to be a large market for go services in asia. If you have what you think is a winning computer-go program, I suggest you invest in a business plan (http://en.wikipedia.org/wiki/Business_plan) sooner rather than later. cheers On Fri, Nov 21, 2008 at 8:53 PM, Michael Gherrity <[EMAIL PROTECTED]> wrote: > Hi, > > I have read that the amount of money that a winning computer go program > would make in a go tournament is insignificant compared to the amount of > money that such a program would earn selling to the general public. I have > also read that the biggest pirates of computer software come from Germany, > the UK, and the US. The foreign exchange student we are hosting from Beijing > China said that most people in China do not buy software, but download it > for free off the net. > > So what is true? > > mike > ___ > 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] Help from some Linux users please
Mark, Do you want to try playing with the "-target" option during compilation of your next version, and we can see whether we can get rid of the UnsupportedClassVersionErrors ? While the code may run fractionally slower when compiled for a previous version of class file, the UnsupportedClassVersionError may be hiding another error. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Help from some Linux users please
I have a variety of java implementations installed, and here are are results for all of them. My archiecture is: more /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=8.04 DISTRIB_CODENAME=hardy DISTRIB_DESCRIPTION="Ubuntu 8.04.1" All java versions below are the complete output of "java -version" I've not differentiated between jre/jdk/toolchain, since I don't think that compilation is an issue here (it's a hassle, I can if anyone needs me to). cheers stuart - works: java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) - works: java version "1.5.0_16" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b02) Java HotSpot(TM) Server VM (build 1.5.0_16-b02, mixed mode) - fails: SableVM version 1.13 - compile date and time: 2006-11-09 06:17:01 UTC - gcc version: 4.1.2 20061103 (prerelease) (Ubuntu 4.1.1-18ubuntu2) - 'real life brokenness' features enabled - copying garbage collection - bidirectional object layout - direct-threaded interpreter [EMAIL PROTECTED]:~/tmp/CGOS$ java -jar GTPTester.jar "java -jar GoEngineGTP.jar" java.lang.UnsupportedClassVersionError at java.lang.VMClassLoader.nativeDefineClass (VMClassLoader.java) at java.lang.VMClassLoader.defineClass (VMClassLoader.java:130) at java.lang.ClassLoader.defineClass (ClassLoader.java:679) at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:108) at java.net.URLClassLoader.findClass (URLClassLoader.java:955) at java.lang.ClassLoader.loadClass (ClassLoader.java:359) at java.lang.ClassLoader$1.loadClass (ClassLoader.java:1333) at java.lang.ClassLoader.loadClass (ClassLoader.java:310) at java.lang.VirtualMachine.main (VirtualMachine.java:99) -- fails: java version "1.5.0" gij (GNU libgcj) version 4.2.4 (Ubuntu 4.2.4-1ubuntu3) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Sending GTP command: name java.io.IOException: The engine didn't respond. Possible reason: at tesuji.games.gtp.GTPUtil.readGTPResponse(GTPUtil.java:94) at tesuji.games.go.main.GTPTesterMain.main(GTPTesterMain.java:57) -- works: java version "1.6.0_07" Java(TM) SE Runtime Environment (build 1.6.0_07-b06) Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode) -- On Sat, Nov 8, 2008 at 12:27 PM, Mark Boon <[EMAIL PROTECTED]> wrote: > I have now tested my basic setup with Mac OSX, Windows and Ubuntu Linux. > Although it all works fine for me, Don still reported problems that we don't > understand. > > So I would be very obliged if there are some other Linux users who would > like to give it a try. All you need to do is download a zip-file from this > location here: > https://plug-and-go.dev.java.net/files/documents/9557/115949/CGOS.zip > > Unzip it, go to the CGOS directory that got extracted from the archive in a > terminal window and type: > >java -jar GTPTester.jar "java -jar GoEngineGTP.jar" > > literally, with the double-quotes. Better copy-paste the whole line. If > everything goes as planned, you'll see lots of move-coordinates whiz by and > in the end it should print "Your Go engine checked out OK!". I'd like to > know if there are Linux users who see something different. > > Note: this assumes you have Java 1.5 or higher installed. This can be easily > checked by typing: java -version in the terminal. > >Mark > > ___ > 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] java reference bot
Seems like we need a short introduction too: "Go is a board game played on a rectangular grid, usually 19x19. Pieces (or stones) are placed alternately by the black and white players. Pieces are played onto empty vertexes with the aim of surrounding and capturing the opponents pieces. The game continues until both players pass. Go is scored on territory---essentially whoever has the most territory wins. See http://senseis.xmp.net/?BasicRulesOfGo for a more complete but informal introduction. This task aims to solve the game of go using Monte Carlo simulation, playing many random games to determine the best next move. For an introduction to Monte Carlo simulation See http://senseis.xmp.net/?MonteCarloTreeSearch or http://en.wikipedia.org/wiki/Monte_Carlo_method This task uses a simple simulation and somewhat simplified interpretation of the rules for the sake of ease of implementation." You also need to explain the following terms you use without explanation: komi, play-outs, gtp, genmove, ko, superko. explanation by reference to a good beginner page on http://senseis.xmp.net/ or http://en.wikipedia.org/wiki/ should do cheers stuart On Tue, Oct 14, 2008 at 12:14 PM, Don Dailey <[EMAIL PROTECTED]> wrote: > I made a reference bot and I want someone(s) to help me check it out > with equivalent data from their own program. There are no guarantees > that I have this correct of course. > > Doing 1 million play-outs from the opening position I get the following > numbers for various komi: > > playouts:1,000,000 > komi:5.5 > moves: 111,030,705 > score: 0.445677 > > playouts:1,000,000 > komi:6.0 > moves: 111,066,273 > score: 0.446729 > > playouts:1,000,000 > komi:6.5 > moves: 111,040,546 > score: 0.447138 > > playouts:1,000,000 > komi:7.0 > moves: 111,029,204 > score: 0.4333795 > > playouts:1,000,000 > komi:7.5 > moves: 111,047,843 > score: 0.421281 > > (I also get a score of 0.524478 for 0.0 komi) > > Score is from blacks point of view. Score is not the score of the > best move of course but the combined average score of all 1 million > play-outs using the stated komi and ranges from zero to one. > > I am going to build a test harness to compare multiple bots side by > side using gtp commands. I made up two private gtp commands to > facilitate this: > > ref-nodes -> return total moves executed in play-outs > (including both pass moves at end of each > play-out.) > > ref-score -> return total win fraction for black. > > NOTE: both commands report stats from last given genmove search. > > > > I hope to get peoples opinion on the following implementation > specification. I'm definitely not a writer, so I need to know if this > very informal spec is enough at least for experienced MC bot authors > or where there are still some ambiguous points. > > > I'm using the following implementation specification: > > [ bot implementation specification ] > > This is an informal implementation specification document for > writing a simple Monte Carlo Bot program. The idea is to build a bot > like this in ANY language and test it for performance (and > conformity.) Can be used as a general language benchmark but is as much > about the implementation as the language.This specification assumes > some knowledge of go and Monte Carlo go programs. (If you don't like > it, please write a better one for me!) > > > > 1. Must be able to play complete games for comprehensive conformity > testing. > > 2. In the play-out phase, the moves must be chosen in a "uniformly > random" way between legal moves that do not fill 1 point eyes and > obey the simple-ko restriction. > > When a move in the play-out is not possible, a pass is given. > > 3. Play-outs stop after 2 consecutive pass moves, OR when N*N*3 > moves have been completed, except that at least 1 move gets tried > where N is the size of the board. So if the board is 9x9 then > the game is stopped after 9*9*3 = 81*3 = 243 move assuming at > least one move has been tried in the play-outs. > > 4. A 1 point eye is an empty point surrounded by friendly stones > for the side to move. Additionally, we have 2 cases. If the > stone is NOT on any edge (where the corner is an edge) there > must be no more than one diagonal enemy stone. If the point in > question is on the edge, there must be NO diagonal enemy stones. > > 5. Scoring is Chinese scoring. When a play-out completes, the > score is taken accounting for komi and statistics are kept. > > 6. Scoring for game play uses AMAF - all moves as first. In the > play-outs, statistics are taken on moves played during the > play-outs. Statistics are taken only on moves that are played by > the side to move, and only if the move in question is being > played for the first time in th
Re: [computer-go] programming languages
On Sat, Oct 11, 2008 at 10:05 AM, terry mcintyre <[EMAIL PROTECTED]> wrote: > I like the idea of a contest to determine the best ways to implement a > particular problem ( generating light playouts ) in various languages. > > The Language Shootout is probably not the best forum, since they require the > same algorithm, which defeats the purpose of comparing languages which tend > to do different things well by design; a good programmer/advocate would play > to the strengths of each language. The Language shootout has a class of "contests" which do not require the same algorithm, i.e. http://shootout.alioth.debian.org/u32q/benchmark.php?test=meteor&lang=all cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
The topic of which programming language to use has been raised innumerable times in the >5 years I've been on this list and I've been backward about coming forward with an opinion because the conversation seems to generate great deals of heat without much light. The http://shootout.alioth.debian.org/ site, however, has lead me to an interesting idea. The site itself is a set of fully described algorithms, implementations of the algorithms and a test and reporting harness. If we, as a community, could come up with a sufficiently detailed description of light playouts algorithm (see the current "Light simulation : Characteristic values" thread), there is no reason that this algorithm couldn't join them. I suspect that detailing the algorithm sufficiently for non-go players to implement may be surprising challenging. cheers stuart On Thu, Oct 9, 2008 at 12:12 PM, Darren Cook <[EMAIL PROTECTED]> wrote: >> ATS does the binary-trees test 6.2 times quicker than C++ but 2.7 times >> slower on k-nucleotide (which seems to be about making hash tables): > > Prompted by Isaac, I found the single-core benchmarks (change the "u64q" > to "u32" in the URLs I posted before to get them, or start at > http://shootout.alioth.debian.org/u32/ ), ATS does binary trees 1.9 > times quicker, and k-nucleotide 1.4 times slower. > > Darren > >> http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=ats&lang2=gpp >> http://shootout.alioth.debian.org/u64q/benchmark.php?test=knucleotide&lang=all >> http://shootout.alioth.debian.org/u64q/benchmark.php?test=knucleotide&lang=gpp&id=1 > > > -- > 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/ > ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Some thoughts on the event in Leksand
On Thu, Aug 14, 2008 at 5:05 AM, Nick Wedd <[EMAIL PROTECTED]> wrote: > > When I first came across microcomputers, in 1981, there was a chess program > that ran on them. It played so badly that even I could beat it; so I looked > for other challenges, such as to stalemate it. I was surprised by its > behaviour when stalemated, which I assume was caused by its being programmed > to make the best move it could manage, where being legal was an overriding, > but not essential, feature of "best move". When it was stalemated, it > couldn't find a legal move, so it would make the best illegal move it could > find. This was typically to pick up my queen, change its colour, and > capture my rook with it. Now there's a feature that would make a tournament interesting... cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Depth-first UCT
On Wed, Aug 13, 2008 at 1:29 PM, Hideki Kato <[EMAIL PROTECTED]> wrote: > Rémi Coulom: <[EMAIL PROTECTED]>: >>Gian-Carlo Pascutto wrote: >>> >>> The *paper* about MTD(f) is extremely interesting because it shows >>> that many best-first algorithms can be rewritten as depth-first >>> algorithms. >>> >>> It happened for SSS, it happened for proof-number search. >>> >>> Who will make it happen for UCT? >>> >> >> >>Actually, there was a paper presented at the 2007 Computer-Game Workshop >>in Japan entitled "Depth-First UCT and its Application to Go", by >>Haruhiro Yoshimoto, Akihiro Kishimoto, Tomoyuki Kaneko, and Kazuki Yoshizoe. > > Abstract in English: > The UCT algorithm is a representative best-first search algorithm that > has been popularly used in Monte Carlo Go. This paper presents the > DFUCT (Depth-First UCT) algorithm, which is an efficient depth-first > variant of UCT. Experimental results in Go show that DFUCT achieves > 3% improvement in running time, while the solving abilities of DFUCT > and UCT are comparable. > > This paper is written in Japanese. Thank you for the translation. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] the more important news from the Go congress
It is great to see computer players taking another step towards being first-class citizens of the go-playing world. cheers stuart On Mon, Aug 11, 2008 at 3:37 AM, David Doshay <[EMAIL PROTECTED]> wrote: > While the mogo game and result is in the newspaper and keeping all of us > talking, there was another piece of progress in computer Go that took place > at the US Go congress that I think says more about the state of computer go > than the 9-stone handicap win. > > The day before the mogo match there was a meeting with a number of AGA > officials that Peter Drake and I attended. After much spirited, passionate, > and strongly opinionated discussion, it has been decided that the AGA will > develop a plan to formally rate computer programs. The AGA feels that it has > the "gold standard" in rating systems, and previous to this point all games > against computer programs were explicitly not rated, and thus programs could > not get a rating. > > It is clear to me that the AGA is not going to drag its feet on this, and we > will be able to get reliable ratings before a year from now. Before folks > start rants about KGS ratings, lets make clear that while those are > interesting, the ease of making a new user name to either inflate or deflate > one's rating, and the ease of abandonment are very real issues that lead the > AGA to shrug off KGS ratings at this time. > > The exact details of the system are not yet specified, but I have been > assured by those with the power to make it happen that one year from now we > will have made the first important step towards the acceptance that programs > can play Go: they will have realistic and confirmed ratings. This is clearly > an important step towards more widespread acceptance of programs as serious > players. > > Cheers, > David > > > > ___ > 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] sgf standard
On Mon, Aug 4, 2008 at 6:00 PM, Ray Tayek <[EMAIL PROTECTED]> wrote: > At 01:58 PM 7/29/2008, you wrote: >> >> ... had a burst of activity >> related to the addition of new properties to the standard. >> >> The properties relate to the representation of common subtrees. > > i just dusted off an old sgf parser/merger in java. i can eat the example > file ok. > > where are the new properties listed? http://tech.groups.yahoo.com/group/sgf-std/message/288 Seems to be the best discussion. > are there any example? There don't appear to be many good example files yet. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Java SGF Parser
On Mon, Aug 4, 2008 at 12:55 PM, Ross Werner <[EMAIL PROTECTED]> wrote: > I'm looking for a nice Java SGF library that allows you to parse SGF files > into a simple tree, and to serialize your own tree back to SGF. I've looked > at a few of the open source Go projects currently out there, and I've > searched the computer-go archives (and even found a post from myself a few > years back on the subject), but haven't found anything that seems very > robust. > > So, my question here is twofold: > 1) Does anybody know of a good Java SGF parser out there? > 2) What would your criteria be for a good SGF parser? (e.g. it's more > important that it's fast than memory-efficient, or vice-versa, or have a > certain API, or allow for traversing the game tree without holding the > entire file in memory, etc.) > > If I can't find a good one out there, I may write one myself, probably based > on JavaCC/SableCC, which I'm somewhat familiar with. I have what I believe to be a fast JavaCC sgf grammar at: http://code.google.com/p/jgogears/source/browse/trunk/jgogears/jgogears/SGF/SGF.jj I am interested in developing it into a fully-functional java bean. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] sgf standard
Hello This is just a quick email to let you all know that the very low volume sgf-std mailing list has recently had a burst of activity related to the addition of new properties to the standard. The properties relate to the representation of common subtrees. If you externalise your search trees these may be of interest to you. If you're interested, I suggest you check out: http://tech.groups.yahoo.com/group/sgf-std/messages cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] What Do You Need Most?
Various branches of the US government (including NIST) have developed a very successful approach to funding research. Set up a measurable competition (such as we already have with CGOS) and then fund research groups through a series of rounds, with the results of each funding round being influenced by the group's success at the measurable competition in the previous rounds. This obviously works better in some fields than in others, but there's no reason it couldn't work for go. cheers stuart On Mon, Jul 28, 2008 at 8:54 PM, Darren Cook <[EMAIL PROTECTED]> wrote: >> I'm not the author of a strong program, but I'll throw another item into >> the list: more incentive. For many, computer go competes for time with >> many other hobbies and perhaps even a day job. > > The big Ing prize brought many people into computer-go, all working in > parallel, competing, to make mediocre programs. And plenty of progress > has been made in the past few years, without any big money being > offered. Could it be that the lack of financial incentive makes people > willing to share their work and knowledge, and that that is behind > recent progress? (I don't know, it could just be coincidence.) > > Darren > > -- > 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://darrendev.blogspot.com/ (blog on php, flash, i18n, linux, ...) > ___ > 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] komi for 9 by 9 will always be 7.5 right?
I'd be very surprised if anyone was in a position to make a guarantee about komi. There have been some many differing views for so long on the issue... cheers stuart On Tue, May 27, 2008 at 4:00 PM, George Dahl <[EMAIL PROTECTED]> wrote: > I just wanted to confirm that there are no plans for changing the komi > on CGOS to anything but 7.5 ever. I just started a 7400 cpu-hour > computation to generate training data for my Go bot and it is > inextricably linked to the komi, I will have to regenerate training > data (and then retrain) my bot if I want it to play properly with any > other komi (and of course boardsize). > - George > ___ > 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] Computer Go Forum
There is no forum that I know of. All recent posts are archived at http://computer-go.org/pipermail/computer-go/ They can be searched using google by restricting search to a single domain, a la http://www.google.co.nz/search?as_sitesearch=computer-go.org The other issue is that the answers sometimes change, so its best to just ask your question in the mailing list. cheers stuart On Sat, May 3, 2008 at 6:49 PM, Joshua Shriver <[EMAIL PROTECTED]> wrote: > Is there a computer go forum? This mailing list has been great, and may and > the most powerful people are here. While email is nice, it would be nice to > have a website to post questions, and an easy way to search responses. I > really like talkchess.com for chess material, just wish there as a > comparible version for Go. > > -Josh > > ___ > 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] State of the art of pattern matching
On undefined, Don Dailey <[EMAIL PROTECTED]> wrote: > > In some of my pattern learning experiments, I discovered that only a > very small subset of possible patterns occur on the real board, and yet > for a game tree searcher it would be pretty important to understand > those patterns that are "constantly avoided" in order to understand why > they are being avoided. > > That's why I believe that patterns culled from games are pretty much > useless.That probably extends to most learning based on observing > games. I agree wholeheartedly with your observation, but not with your conclusion. It is undoubtedly true that dan level players foresee, understand and avoid many patterns, but it is also true that many players develop those abilities largely through playing many games of go, as well as studying books and problems. Given that there are collections of tens of thousands of games played by kyu level players as they improve to dan level; given that there are collections of thousands of life and death problems studied by those players to the same end; I see no rational explanation why the lessons leant by humans as they improve (or equivalent lessons expressed computationally) can't be inferred. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] State of the art of pattern matching
My computer-go player is a single pattern system. It linearises patterns and stores them in a very large suffix tree. At each node in the tree counts are kept of the number of times the node has been played or not played. http://code.google.com/p/jgogears/ It's currently at the stage where it plays a game that looks like go in self play after training on only 200 games. Training is currently very slow, play very fast. Java/javacc/eclipse/junit cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Collection of games for train? (jgogears)
Hello Everyone I've been working for a while on a computer go player which takes a rather different tack[0]. Rather than using embedded programmatic domain knowledge (like GNU Go) or dynamic evaluation of board positions (UCT etc), it uses domain knowledge inferred from game records and a complex look-up during play. My approach is to define a linearisation of the board with respect to a position (or a set of linearisations, taking into account symmetry), I then use classical string processing techniques, principally a large prefix tree. Conceptually this tree is very large (one leaf for every vertex for every possible board position), but it is not fully expanded. I'm foreseeing that crafting rules relating to the expansion of the tree to be a core problem. Does anyone know of any research into similar approaches? The program will be slow and memory hungry to train, but should be fast to play. I'm anticipating it will be strong at the opening but possibly confused by random moves (i.e playing on the edge of the board). Currently I have developed a core system which is now plays games that games that look at least a little like go. What I'm after now is a good collection of games to train it on, so I can see check whether further developments are making a positive difference. What I think I need is a relatively homogeneous collection of tens or hundreds of thousands of 19x19 games of varying levels. Does anyone know of a collection such as this I can download relatively simply? cheers stuart [0] http://code.google.com/p/jgogears/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re : [computer-go] How to use CGOS ?
On Mon, Feb 25, 2008 at 11:30 AM, Raymond Wold <[EMAIL PROTECTED]> wrote: > It would be so much simpler if everyone used GTP directly on the server. > I am aware that GTP lacks authentication features, but it should be > simple enough to agree on a command and say that that's now the standard. Adding authentication to GTP is a stunning bad idea. If we really need an authenticated GTP, wrap the GTP we have in an SSH connection. Implementations already exist for most platforms (including a nice portable java one) and it was written by people who know about security. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: computer-go Digest, Vol 43, Issue 8
On Feb 12, 2008 2:10 PM, Don Dailey <[EMAIL PROTECTED]> wrote: > > > Andy wrote: > > But the program isn't stronger than pros, so how can it give better > > information about proper komi? > Pro's cannot give you statistical information on komi unless you simply > collate several thousand pro games. > > I don't think you need a particularly strong program, just good > programs.If you notice that over thousands of games 6.5 is gives > black a statistically significant edge, and 8.5 gives white a > statistically significant edge, you know (at least for programs) that > 8.5 is too high. I think you might need a strong program with either (a) no built-in knowledge about the game of go (i.e. pure UCT with no open book, no heuristics, etc) or (b) with built-in knowledge which can be shown to be of equal benefit to both black and white. I'm guessing that (a) will happen before (b). cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Difficult and strong move
I recommend "Mathematical Go: Chilling Gets the Last Point" by Elwyn Berlekamp and David Wolfe. The book contains a number of such positions, as well as an approach that allows to make as many more as you need. http://math.berkeley.edu/~berlek/cgt/gobook.html cheers stuart On 08/01/2008, Michael Williams <[EMAIL PROTECTED]> wrote: > Can anyone point me to a move in a 19x19 game that is commonly seen as > the best move but hard to find? I know of the Ear Reddening move, but I > don't know whether or not that meets my criteria (I'm not a dan player, > or even close). Thanks. > ___ > 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] random numbers with functional languages
Probably the reason that it is so slow is that it's aiming for a cryptographically random number sequence. These are usually derived ultimately from kernel timings (often via /dev/random on linux systems) and it can take a while to establish a degree of confidence in the randomness of these bits. If you want a sequence of numbers that is very unlikely to repeat but that doesn't have to be cryptographically random, standard practice is to initialise the random number generator with the current time (usually a long expressed in milliseconds). This naturally fails if you ever create more than one sequence per millisecond. cheers stuart On 19/12/2007, Berk Ozbozkurt <[EMAIL PROTECTED]> wrote: > Hi, > > I'm currently writing a UCT based go program in Clean to see if it is > feasible to write one in a functional language. This is my first attempt > at functional languages, and I'm having trouble with random numbers. > > A mersenne twister module is available for Clean. Once initialized it is > reasonably fast to extract a new random number from the generator. > However, it is about a hundred times slower to initialize it with a new > random seed. Therefore my first attempt at generating random numbers by > storing seeds at tree nodes and creating a new random list and a new > seed each time random numbers are required for mc evaluation is very > slow. The alternative seems to be passing around an index to a global > random list, which is both ugly and complicated. Is there another way? > ___ > 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] language efficiency
On 16/12/2007, terry mcintyre <[EMAIL PROTECTED]> wrote: > > Intel makes compilers for C, C++, and Fortran. As far as I can tell, they do > not make compilers for Lisp, Haskell, OCaml, or any other higher-level > languages. Intel also funds work (directly or indirectly) on the GCC suite, which compiles languages such as Java, and there are lisp implementations in Java... > Why reinvent the wheel? Reinventing the wheel is necessary if you don't want to be lumbered with the limitations of the wheel. Some of the problems with C include: * linking conventions inherited from Fortran and now 30 years behind modern ideas in software engineering * compile time rather than runtime portability * lack of dynamic modifications of the runtime There are issues such as poor support for network protocols, Unicode, threading, etc., but (as you correctly point out) these can be remedied by using a high level language which uses C as an intermediate language. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Lisp time
On 14/12/2007, Nick Apperson <[EMAIL PROTECTED]> wrote: > C++ is "faster" than C because the STL (and other generic code) allows the > programmer to spend their precious time optimizing the bottleneck and using > a very fast default for less critical places. For a sufficiently small > program however I will wager that given enough time, C will be exactly the > same speed as C++ if the programmers involved are both good. The C++ generics are also on the surface faster than (for example) the Java generics (which I use). This is because whereas C++ compiles and optimises a class for every instantiated generic, Java uses a single class and is thus unable optimise for specific cases. This makes C++ generics faster, except in the case where the bottleneck is how much can be fitted in the cache, which the fact that Java hasn't multiplied it's generic classes may give it the advantage. Yes, as you can tell, I'm bitter about this particular design decision. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
There are a bucket load of lisp and Scheme implementations for the JVM at: http://www.robert-tolksdorf.de/vmlanguages.html I work in Java, so anything that works with that good by me... I'm personally a little disappointed that the effort to implement emacs in Java hasn't really gathered steam. cheers stuart On 12/12/2007, terry mcintyre <[EMAIL PROTECTED]> wrote: > > > From: Stefan Nobis <[EMAIL PROTECTED]> > > terry mcintyre <[EMAIL PROTECTED]> writes: > > > Any of those with recent Lisp experience have any opinions about > > multicore capabilities? > > Multithreading is not available in ANSI CL, but most implementations > support multithreading in some ways. AFAIK SBCL, Corman Lisp, OpenMCL > and some more have true kernel level multithreading without internal > locks. > > Thanks for the info! > > > What I've googled so far looks a bit rudimentary - mostly based on > > unix fork semantics. I'm looking for something much lighter-weight, > > Erlang-style, which could support thousands of cheap concurrent > > Hmmm... it surely depends on your OS, but nevertheless maybe this is > interesting for you: > > http://common-lisp.net/project/erlisp/ > > That does look interesting -- but the last post to the erlisp-devel mailing > list was in 2005, > if we don't count the single spam post in 2006. It's an extremely > low-traffic list ;) > > > Looking for last minute shopping deals? Find them fast with Yahoo! Search. > ___ > 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] Lisp time
I've not used scheme recently, but I certainly recall it fondly. When I we were taught it, the language definition was famously shorter than the index to the definition of the Common LISP. cheers stuart On 12/12/2007, Peter Drake <[EMAIL PROTECTED]> wrote: > Chez Scheme is a good choice. For a book, you want Dybvig's "The Scheme > Programming Language"; it's available in dead-tree form or (free) on-line: > > > http://www.scheme.com/tspl3/ > > > Peter Drake > http://www.lclark.edu/~drake/ > > > > > On Dec 12, 2007, at 1:09 AM, Nick Apperson wrote: > > I've been (and still am) a die hard supporter of C++, but since I program in > C++ for work (we develop gamelike software) I get tired of C++ day in and > out. I'd also like to push myself to learn some new things. > > Lisp seems to me like a language I could really come to respect. I run > linux (no windows, period) and I am comfortable with command-line if I need > to be. Anyway, I'm trying to figure out what the best way would be to learn > lisp so that I can begin working on a computer go program in it. I can't > even figure out what the right dielect would be for computer go. > > Any of you out there using lisp want to maybe point me in the right > direction for how to learn this language as it applies to writing a go > program? Thanks. > > - Nick > ___ > 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: [computer-go] CGOS down? Java client - basic GTP problem
30 is not an id, command ids are at the start of lines Does "= E3" work as a response? cheers stuart On 27/11/2007, Harri Salakoski <[EMAIL PROTECTED]> wrote: > command genmove w 30 > reply=30 E3 > cgos replys gameover 2007-11-27 B+Illegal do not understand syntax > > GTP specc says : Success Responses - A successful response has one of the > syntaxes > =id response\n\n > =id\n\n > = response\n\n > =\n\n > > code is: > return "=" + id + " " + s + "\n\n"; > > stream is written using PrintWriter: > myToServer.println(line); > > Anybody used java with cgos could help or if it is otherway obivious. > > t.Harii > > > 27.11.2007 20:30:14 narugo.util.MyLog log > INFO: Server:gameover 2007-11-27 B+Illegal do not understand syntax > - Original Message - > From: "Harri Salakoski" <[EMAIL PROTECTED]> > To: "computer-go" > Sent: Tuesday, November 27, 2007 6:32 PM > Subject: [computer-go] CGOS down? Java client > > > > Hmm, I am not sure as only trying to make Java bot connect CGOS, but it > > seems to be down. > > It seems that it does not give feedback after password. Also I found cgos > > email list "cgos-developers" is it also for users or is this list ok? > > > > t. harri > > ___ > > 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: [computer-go] Re: Euler numbers
On 27/11/2007, Dave Dyer <[EMAIL PROTECTED]> wrote: > > Actually, I'm the main party responsible for propagating this technique > on the web. The scanned pages were scanned by me. I use this Euler > technique in my Lines of Action programs, where it is much more directly > applicable to detecting a won position. > > Back at my first computer job, where Steve Gray was a mentor, we had a > special purpose computer called a BIP which did this quad counting as a > basic operation. It was used in an OCR system (officially) but also > ran the worlds fastest "Life" implementation at the time. > > Quad counting is only marginally applicable to Go. You could use it > to determine if a collection of stones is closed and if it has an eye, > but there are so many shape/connectivity variations that ought to be > counted as connected or not depending on higher level analysys, I doubt > it would be very useful. > > -- but it's really easy to do, either in a one-pass scan or incremetally; > basically design a scan to count the number of occurrences of each 2x2 > neighborhood type, then do some simple arithmetic on the gross counts. > http://boardspace.net/loa/english/loa-programmer.html > Thanks for this Dave. Does anyone else find the poor scan ironic, given what this was used for? BTW: my library (the Bodleian) claims to have this, I can look it up if anyone needs clarifications on the scan. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] euler numbers
Could you give us a quick reference for exactly _which_ Euler numbers you're using? Wikipedia has three separate ones and the MathWorld site a similiar number. Maybe I'm just being stupid. cheers stuart On 26/11/2007, Don Dailey <[EMAIL PROTECTED]> wrote: > > After reading the paper on solving go on small boards, I am curious > about the use of euler numbers as a simple evaluation element. > > I implemented a little euler number test program and it works correctly > from a sample of about 50 positions of various types. I'm using the > fast version where you scan 2 lines at a time with a lookup table. > > However, it calculates holes inside of groups and this does not detect > eyes or "holes" on the edges of the board.It's not clear how to deal > with this. > > I'm experimenting with a version that wraps a border around the whole > board so that even the empty position looks like a 1 group with one big > hole.This causes a lot of silly anomalies - for instance if you > surround a big chunk of safe opponent stones it looks like a big > hole.If you own half the board and the opponent owns the other > half, his half contributes favorably to your euler number (it looks > like a big hole of yours.) > > Of course I realize that this is just a quick and dirty calculation but > I was curious about any tricks that others use to deal with it. > > - Don > > ___ > 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] Drunken sailor on payday
On 21/11/2007, Adrian Grajdeanu <[EMAIL PROTECTED]> wrote: > Nick, do you know for a fact that a C++ complier will optimize for the > base case of a virtual function? I was under the impression that it > doesn't know (as in can't determine at compile time) whether the > function was overwritten or not so it doesn't favor any of the cases. In > fact I can't even figure how it would if it wanted to optimize an > indirect function call. > I'm not trying to start a war, just to clarify my assumption. As it is I > generally write code using virtual functions that I most often do > overwrite. If what you say is true, then I am incurring the penalty most > of the time and that would be bad... A C++ compiler can make those kinds of assumptions if the object is created within the current compilation unit and can not be overwritten from outside it. There are a whole class of optimizations in Java, C and C++ which can only be applied under these circumstances, which rely on concepts of scope. Whether or not a particular compiler uses these optimizations in a particular case is another matter. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] re: completed game scoring
On 21/11/2007, Dave Dyer <[EMAIL PROTECTED]> wrote: > > Over the years I've had a dribble of requests for my collection > of scored games. The most recent request inspired me to stop > the water torture by just posting it for general use. > > The collection contains 600 professional games with > an exact score, and machine-readable annotations for > which groups are dead, and which dame should be filled. > > http://www.andromeda.com/people/ddyer/go/scoring-games.html Thank you Dave, this looks very useful. A very minor nitpick: I notice that during the processing that you appear to have removed all the RU properties[1], which are technically mandatory and potentially useful. cheers stuart [1] http://www.red-bean.com/sgf/properties.html#RU ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Language
On 21/11/2007, Stefan Nobis <[EMAIL PROTECTED]> wrote: > It's not an inherent feature of the > language that allows JIT. That's not entirely true. There are some languages (such as Perl) which have language features which absolutely precludes JIT as we know it. In Perl you can have a line of code that looks like: @result = (dothis $foo, $bar); which could be either of: @result = (dothis($foo), $bar); @result = dothis($foo, $bar); And the correct choice can vary each time the line is executed. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Language
On 20/11/2007, Colin Kern <[EMAIL PROTECTED]> wrote: > On Nov 20, 2007 1:56 PM, Nick Apperson <[EMAIL PROTECTED]> wrote: > > > On Nov 20, 2007 12:48 PM, Stefan Nobis <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > "Colin Kern" <[EMAIL PROTECTED]> writes: > > > > > > > I think the reason for Ruby being so much slower is because it is an > > > > interpreted language rather than a compiled language. > > > > > > It's not the main problem (interpreted languages are slower than those > > > compiled to native code, but than even Java and C# are interpreted and > > > don't have such big slowdowns). > > > > Java and C# are both compiled at some point if the same loop is running > > repeatedly. Java is usually compiled "just in time" which is to say as each > > function is first run. I'm not sure how C# is executed, but I think it gets > > compiled before execution. > > > > I just found this looking around for things about Java's speed. Looks > like some useful ways to boost Java's performance. > http://www.cs.cmu.edu/~jch/java/speed.html It's an interesting page, but it makes certain assumptions about how you're using Java, mainly that you're compiling to Java bytecode. Almost none of this applies, for example, if you're using gcj to generate platform specific binaries via the gcc/g++ backend. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Language [offtopic, aside]
On 20/11/2007, Vlad Dumitrescu <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Nov 20, 2007 3:03 PM, Stuart A. Yeates <[EMAIL PROTECTED]> wrote:
> > The logical (but worrying) conclusion I draw from that paragraph is
> > that you would like to see a language with an intended application of
> > go...
>
> Why would that be a worrying conclusion?
It would be worrying because in the last 20 years there has been a
trend away from application specific and domain specific programming
languages to application and platform independent languages with
application/domain specific libraries.
As near as I can tell the primary motivation for this is the resource
overhead of building, and maintaining a language and tool chain. The
economies of scale are just much better if you cover more {platforms,
domains, applications}. You can get much more bang (and many more
shiny toys) for your buck by joining an established language /
toolchain. There are exceptions to this, mainly where the field is
well understood and extremely specialised and the language has the
backing of deep-pocketed companies (i.e. PDF, VHDL, etc).
cheers
stuart
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Language [offtopic, aside]
On 15/11/2007, steve uurtamo <[EMAIL PROTECTED]> wrote: > the more i think about it, the more i love whatever language > i'm using for whatever project i'm working on. some projects > would be (or are) horrifying to try to implement in some languages > [the matlab->C example springs to mind], so, since learning > new languages isn't a gigantic burden, the only relevance is > the intended application, i suppose. which is a very cumbersome > way of repeating (reinforcing?) what other people have already said. The logical (but worrying) conclusion I draw from that paragraph is that you would like to see a language with an intended application of go... Or am I misunderstanding you? cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] KGS connection
On 11/11/2007, Alain Baeckeroot <[EMAIL PROTECTED]> wrote: > Le dimanche 11 novembre 2007, Stuart A. Yeates a écrit: > > Such a metric would actually benefit all players, by encouraging them > > to play as many different other players as possible and avoid the > > formation of player cliques. One would have to ensure that you weren't > > penalising player who always played at a certain time of day in a > > certain timezone, however. > i suspect most people plays always at a certain time of the day, in their > timezone, so currently there might be 3 "cliques": Asia, Europe, and Americas. > You're right, of course. It's merely a matter of ensuring that your mathematically definition of clique is appropriate. OTOH, I wouldn't lose any sleep over a metric that rewarded players who played occasionally played outside of their usual weekday evening slot. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] KGS connection
On 10/11/2007, Nick Wedd <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]>, > Chris Fant <[EMAIL PROTECTED]> writes > >> A beginner could easily run gnugo for a day or two, get a 7k rank for the > >> gnugo account, then replace gnugo with an account that moves randomly for a > >> few moves then resigns. Play this new robot as white with handicap 6, and > >> you will soon get a dan-level account. > > > >On the surface, that sounds like a broken system. That is only my > >opinion based on my limited knowledge of the situation you describe. > > It isn't broken, in the sense that a beginner can't do that, because he > won't be able to get the bot's account rated. > > It is broken in the sense that even as things stand, he can persuade his > big brother to open an account, win games, get a 2-dan rating, and then > throw games to him. I don't see how any system could prevent this. This can be done relatively easily using network algorithms. Essentially your throttle how much of a contribution each other player can make to a player's rank. This throttling would probably be done relative difference in the rank between players and the square of the size of the pool of players. Such a metric would actually benefit all players, by encouraging them to play as many different other players as possible and avoid the formation of player cliques. One would have to ensure that you weren't penalising player who always played at a certain time of day in a certain timezone, however. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] BOINC
On 29/10/2007, Ian Preston <[EMAIL PROTECTED]> wrote: > G'day guys, > I'm involved in the development of a very powerful and flexible grid > software, which we plan to release in January. It is all java based. > http://www-nereus.physics.ox.ac.uk/ (bear in mind you can't download > it yet and the website is out of date) > > One of the things I'd like to do on it, once it is finished, is some > kind of attack on Go. I've messed around trying to genetically > generate algorithms to play go. However this has had to go on the back > burner for the moment. The brief attempt I made had no way of storing > data between games (I ran out of time) and the best algorithm it came > up with was a purely random algorithm... :-) > > our group is also the one that is doing JPC - http://www-jpc.physics.ox.ac.uk/ > > I'd love to hear about anyone else distributed attacks on Go. It would be great to see a java port of GoTools by Thomas Wolf[1], which is probably the kind of thing that most naturally lends itself to distributed attacks. Does anyone know whether GoTools is under active development? The webpages were last updated in 2001... cheers stuart [1] http://www.qmw.ac.uk/~ugah006/gotools/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] XML alternatives to SGF
On 23/10/2007, Gunnar Farnebäck <[EMAIL PROTECTED]> wrote: > A potential problem with an XML library is the internal representation > of the game tree. For debugging purposes it's not unusual to dump > reading trees containing literally millions of moves, sometimes up to > the limit of the available RAM. If an XML tree requires more bytes per > move, the functionality would suffer. Does anybody know how big a node > would become in expat for a move tag? There are two widespread models for parsing XML, DOM and SAX, SAX does not require you to be able to store the whole XML file in memory, it's a streaming model. > Next problem is of course the file size of the game records. If they are > 5 or 10 times as large we're talking 9 MB or 18 MB for the game records. > Not a huge amount by itself but when considering the number of copies > of GNU Go being distributed it sums up. I'm not sure about C, but in Java it's normal to pipe XML through gzip (which is included in the Java standard libraries), as this has been found to increase read/write speed (i.e. the cpu hit of (de-)compression is less than the speed up of writing fewer bytes to the disk). I've not studied it deeply, but I imagine a compressed XML file would be smaller than an SGF file. > So what are the benefits? So far I haven't seen anything that is > relevant for GNU Go. The readability is not really an issue, it's almost > never possible to visualize a game record without a graphical viewer > anyway, regardless of coordinate representation, and from the examples > I've seen XML has been worse off than sgf on readability. Character sets > are a non-issue for GNU Go, information about players is simply ignored. > Version control conflicts have never happened with game records and I > don't foresee it for the future. Where I would see a win for GnuGo might be: (*) a standard notation for "move X should have been played A rather then B" which would allow clients to provide direct, machine readable, feedback to developers and a potential format for regression tests. (*) a standard notation for representing compile-time and runtime arguments. (*) a standard notation for representing runtime information such as the top N moves considered. ... > But I can provide a hint for something I would find useful. If it's > something I'm missing in today's sgf viewers it's a good way to dump and > inspect a transposition table. It's possible to expand the > transpositions into a big tree with duplicate subtrees but that makes it > very difficult to traverse it efficiently. Alternatively the tree is cut > off when the same position is reached again but then there's no easy way > to find where the position was first reached, which is needed to follow > the continuations. My program doesn't use transposition tables, so I don't understand them enough to know whether this is practical. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] XML alternatives to SGF
As I understand it, the problem with JSON is that it is not good at
encoding optional extensions, name spaces, private additions, etc.
which is something that modern XML is good at.
Is there anyone who's used a lot of JSON who could comment?
cheers
stuart
On 10/25/07, Don Dailey <[EMAIL PROTECTED]> wrote:
> I tried to manually compose a JSON example to roughly match the xml
> example Stuart Yates gave. I don't know if I did it right because I'm
> not an expert on JSON although I've used it a little bit in javascript
> programming:
>
> {
>"White": "John Doe",
>"Black": "Fred Johnson",
>"BoardSize": 19,
>"Moves": [ "D16", "E16", "H13", "D15", "E12", "C16", "G15" ]
> }
>
> The moves can be on separate lines if you want them to.
>
> JSON is designed to be read directly into a data structure in your
> program. Square brackets are for lists, strings are quoted and colons
> represent records or hashes.
>
> This would be directly read into a data structure in your programming
> language of choice.
>
> I'm guessing here because I haven't looked at JSON in C, but it might
> place this information in the following data structure:
>
> typedef struct
> {
> char *White;
> char *Black;
> int boardsize;
> char **Moves;
> };
>
>
> There would have to be some agreement on what to call the names of the
> various elements.
>
> Variations can be expressed rescursively with JSON, just as in SGF, so
> you can make trees if you want to.
>
>
> - Don
>
>
>
>
>
>
> Stuart A. Yeates wrote:
> > I've been looking further at the jago xml format, and for a very
> > simple game it looks like:
> >
> >
> >
> >
> >
> >
> >
> >
> > Jago:Version 4.7
> > 19
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > cheers
> > stuart
> > ___
> > 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: [computer-go] XML alternatives to SGF
Bob I'm sorry if you read my message as saying that I'm not in favour of an XML file format for go. I'm actually very much in favour of such a thing, which is why I spent two hours getting to understand the current contender and pointing out some of the issues that need to be fixed. cheers stuart On 10/27/07, Bob Myers <[EMAIL PROTECTED]> wrote: > Some critics of an XML-based go format seem to be involved in a paranoid > fantasy that they are going to be forced by evil goblins to use it against > their will. No, Jennifer, that's not the case. Sure, if the format becomes > popular they may end up having to deal with it, but XML-formatted game > records and SGF will be round-trippable in the blink of an eye. > > Many of those complaining about XML don't seem to really know too much about > it. Griping that it's too big is roughly equivalent to wanting to go back to > six-bit character encodings. Carping that it's not readable misses the > point. Those who wonder if their favorite platform/language might not > support XML haven't checked recently. The point is that XML offers an > incredibly rich environment of transformability and extensibility and > interoperability. > > Go programmers are mostly interested in move sequence data, and that's > natural, but we should remember that there are lots of other pieces to the > overall puzzle, including commentary, organization of problem sets, and how > diagrams are handled. > > Let's take just a few examples. Say we want to store metadata in or > alongside SGF files, and/or retrieve/search/index the metadata already in > them, such as the name of the source. If the metadata is in XML, probably in > a well-established format such as Dublin Core or an extension thereof, it > can be discovered and processed by any search engine or, in the not too > distant future, reasoning engine, to answer queries such as "find all games > played by Shuko in 1971". > > In addition, XML has a built-in mechanism for extending vocabularies > (namespaces). This allows information specific to a particular application > to be included in a document, with well-understood characteristics that > allow other applications to ignore the extra stuff. > > DocBook is an example of an XML-based document format for articles and > books, technical and otherwise, For instance, O'Reilly uses a variant of > DocBook for all its publishing. Using XML to represent go information would > make it much easier to integrate with document formats such as DocBook. > > As someone pointed out, using XML would lay to rest once and for all any > questions about character encodings. It also provides the built-in xml:lang > mechanism to represent parallel textual information in different languages, > very useful for Oriental players' names, to give just one example. > > Many people think of XML documents only as text files, but in fact they can > take any form, including being stored in databases which are optimized for > performance in executing e.g. XQuery queries. How're ya gonnna do that with > SGF? > > Many go applications are going to require additional types of information, > such as the threaded commentaries mentioned by Bill S. Certainly compared to > the option of forking SGF into a dozen proprietary formats which don't > interoperate, or stuffing random s**t into the C[] field, would it not make > sense to take the opportunity to upgrade to a single yet extensible model > What say ye, architects of the computing universe? > > The XML formats that have been proposed thus far for go, unfortunately, lack > imagination; they are little more than SGF with a thin XML veneer. In > particular, they have the problem that they hang information such as > commentary and diagrams off the game tree. What we need is a new format > defined ground-up from an XML perspective. Realistically, putting up > white-tower proposals is not going to be successful. What is needed is > real-world proposals on which real-world applications are built, so that > people can see the real-world benefit. > > Bob Myers > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Stuart A. Yeates > Sent: Thursday, October 25, 2007 1:04 AM > To: computer-go > Subject: Re: [computer-go] XML alternatives to SGF > > I sat down and read the DTD and the documentation and have some direct > feedback on it. I'm aware that the DTD is quite old, and some of the > ideas and solutions I'm going to suggest might not have been available > (or as popular) when the DTD was written. Lines starting with quotes from the DTD. > > > > > > > Referencing HTML in this way doesn
Re: [computer-go] XML alternatives to SGF
I sat down and read the DTD and the documentation and have some direct feedback on it. I'm aware that the DTD is quite old, and some of the ideas and solutions I'm going to suggest might not have been available (or as popular) when the DTD was written. Lines starting with Referencing HTML in this way doesn't allow validation. Defining the standard using schemas allow importing of concepts such as "Paragraph of HTML" directly from an appropriate HTML standard. I believe it is a mistake not to have a protocol version number here. It seems unfortunate that there is no explicit version number here and no url link to the application website. It would be great to define this in terms of a standard format (i.e. ISO date format), since more than once I've had to infer the formatting of a date an SGF file. The user tag is ambiguous, is this a person's name? a user name? a user name on what server? It would be great to use a URL here to the licence under which the file is being distributed, for example, the creative commons licences on a lot of web content these days. Using a url to a ruleset here would be great. Even better would be a machine-interpretable ruleset, but I'm not counting on that anytime soon. Using schemas allows the content of tags to be restricted. See also discussion in the docs. This introduces ambiguity into the file format, since it is unclear what the precedence is. If the XML says one thing and the embedded SGF tags say another, which has precedence. cheers stuart On 10/22/07, Jason House <[EMAIL PROTECTED]> wrote: > An XML alternative [1] to SGF has recently come to my attention. What do > others think of this alternative? Personally, the effect of a tag affecting > the previous tag seems kind of strange to me. > > PS: I found out about this from [2], a recently closed GoGui feature request > to write more sane sgf files that contain the standard algebraic notation > used in all GUIs. > > [1] > http://www.rene-grothmann.de/jago/Documentation/xml.html > [2] > https://sourceforge.net/tracker/?func=detail&atid=489967&aid=1752711&group_id=59117 > > ___ > 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] XML alternatives to SGF
I've been looking further at the jago xml format, and for a very simple game it looks like: Jago:Version 4.7 19 cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] XML alternatives to SGF
Much of the discussion in this thread has focused very narrowly on using an XML format to replace SGF, I believe that if an XML format is to take off, it should offer capabilities beyond what are possible in SGF, conversion to XML for XMLs sake is pointless. Possibilities include: * A person naming scheme for the players which allows us to say to be more expressive, both in terms of expressing the name in more than one language and in terms of expressing that this person has had several names over their lives. * A method of versioned annotation that allows me, for example, to say "version 0.1.3 of myComputerGoPlayer made a mistake by playing at k12", "version 0.1.4 of myComputerGoPlayer made a mistake k11" and so forth, so that these can be dealt with automatically. * A method for linking to websites of the players, including whether these are the players own definitive websites, and the languages they're in. * A method for presenting translated comments, i.e. the same comments in different languages, so a program can display only the appropriate ones. * A rank recording scheme to differentiate between kinds of rank, to be able to say "Black was at the time of playing 2k AGA, 1k on KGS and 2k on IGS, a month later they got their Shodan certificate from the BGA." * <> I also agree that robust and useful validation suites and conversion tools are also imperative for such a venture to succeed. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Help!The way of situation/circumstance judgement by computer
On 9/10/07, h.l.s.t <[EMAIL PROTECTED]> wrote: > As the theme says,I wanna some advise of how could I judge the > situation/circumstances?Just like ,How could I know how many crosses/mu each > player has? > > Appreciate for any answer. If I understand your question correctly, you are asking how to estimate the score of an incomplete game. The answer is: with difficulty. Unlike chess, there is no simple, cheap metric to estimate the score reasonably reliably. In the early game influence metrics can be useful, late in the game measures of surrounded territory can be useful, but know when to use which is challenging. The problem is made harder by issues such as seki and aji. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] SGF parsing
On 7/10/07, Jacques Basaldúa <[EMAIL PROTECTED]> wrote:
Joshua Shriver wrote:
>Any help is appreciated, trying to write a parse in C
There is free source code for that:
http://www.red-bean.com/sgf/sgfc/index.html
and GnuGo http://www.gnu.org/software/gnugo/
If you want to do something minimal for testing an engine,
you only have to find: board size SZ[] komi KM[] and
the moves ;B[];W[] the file should have only one starting
"(" and one final ")" i.e. no variations.
If you want to extract a variation from a file that contains
many, you can use GoKnot using "Save as" and the file type
"Smart Game Format (Current variation only)" i.o the default
"Smart Game Format (All variations)"
On this note, does anyone know of a collection of strange/unusual SGF
files to test a parser against? I have a SGF parser written in javacc
(think object oriented lex and yacc, outputting pure java) and while
it seems fast I've not really tested it much against corner cases.
cheers
stuart
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Efficiently selecting a point to play in a random playout
When writing C/C++ for multi-platform student assignments using gcc, we always used the args: -ansi -Wall -pedantic Literally "use the ANSI standard" "turn all warnings on" and "be pedantic about warnings." This, of course, won't help with libraries not being found. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Progressive unpruning in Mango 19x19
On 5/24/07, Chaslot G (MICC) <[EMAIL PROTECTED]> wrote: Question for native English speakers: do you think this technique is best described by "progressive unpruning" or "progressive widening"? Widening and pruning have different implications, at least to me (a native English speaker). Widening is suggestive of a single expanse and the operation is happening all along one side of the expanse in a uniform manner. A road, a meadow or a railway bed might all be widened. Pruning is suggestive of a branched, network or complex structure, and the operation is happening at selected points to achieve a goal. A hedge, a railway timetable or a set of laws might all be pruned. Having said that, pruning in computer science has a specific meaning (since the 1973 Scientific American article by Shannon), "To take away or remove (superfluities, deformities)," based on existing uses of the terms of languages, texts and laws[1]. This definition of pruning doesn't seem to apply, since the first expansion of the search tree is not performed by finding and removing superfluous or bad nodes, but by pure chance. If there has been no pruning, there can be no reversal of the pruning, no unpruning. So I'd go with "progressive widening". Or that's my 2p. cheers stuart [1] I don't know this by heart, but I have access to http://dictionary.oed.com/cgi/entry/50191254 because I'm Oxford-based. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Orego 5.04 released
A couple of quick observations: In java it's usually faster on modern hardware to pipe serialised objects through a gzip filter before you serialise them to disk. Compression effort is more than offset by reduced disk bandwidth, which is often bottleneck. "The Orego code should be of use to anyone familiar with Java who is just getting into computer Go." should read "The Orego code should be of use to anyone familiar with Java who is just getting into UCT and computer Go." I was surprised not to find a copy of the javadocs on your website. Other than that, it looks great. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Idea for a strategy
I have a computer-go player under development that uses some of these techniques. It's still not very far along, however. There are very significant challenges. cheers stuart On 5/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >-Original Message- >From: [EMAIL PROTECTED] >To: computer-go@computer-go.org >Sent: Wed, 16 May 2007 5:08 AM >Subject: [computer-go] Idea for a strategy > >http://www.regdeveloper.co.uk/2007/05/15/google_translation/page1.html > >This is an article on statistical approaches to machine translation. > >Has anyone attempted similar with computer go? > >-- Nick > I've done a little bit of work in both fields. I think the similarities are rather striking and have often taken code written for one domain and reused it for the other. In my experience, looking at both problems together has been somewhat helpful, but not tremendously helpful. Potentially... who knows. If you like Monte Carlo go, you'll probably like Statistical Machine Translation. Anyway, here is a link to a remarkably well written description that tells you how it works and how to do it. IIRC it made quite an impact when it first came out. http://www.isi.edu/natural-language/mt/wkbk.rtf Dave Hillis Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. ___ 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] Suppose we had a go problem server?
On a related note, does anyone know of a collection of games, boards or positions with moves annotated with their weights (a la Mathematical Go[1]) ? Or even a format for representing games which allows reliable annotation of the same? cheers stuart [1] http://math.berkeley.edu/~berlek/cgt/gobook.html On 3/28/07, Sanghyeon Seo <[EMAIL PROTECTED]> wrote: 2007/3/26, Jason House <[EMAIL PROTECTED]>: > There are some freely available regression test suites. Two come to mind: > * computer go test collection 2.0 > * The regression suite available in gnu go There's also STS-RV, a comprehensive test suite for capturing races. STS-RV stands for "Semeai Test Suite by Ricard Vilà". http://gobase.org/reading/preview/Semeai/ -- Seo Sanghyeon ___ 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] computer go documentation issues
On 3/19/07, Roland Illig <[EMAIL PROTECTED]> wrote: Peter Christopher wrote: > Taking a look at computer go documentation, I see that there are (at > least) three pages that exist in wiki format for top level "computer go" > wiki pages- > > wikipedia.org - computer go > sensei - computer go > sensei - computer go programming > > It seems obvious that these are redundant. It seems prudent to combine > them in one location. Which location? I am thinking that wikipedia > would be the main page. Wikipedia is not a discussion forum. It aims to be an encyclopedia. I would very much welcome if the computer go pages at Sensei's Library covered even more topics. Assuming that a mailing list is for discussing things, where do the results end up? For me, Sensei's Library would be a perfect place. As I understand it, if a consensus has been reached on this list, then the results can be reported on wikipedia, providing that links to messages in the archives are used to support the report. Links to specific published papers (details can be found on the computer-go bibliography, presumably) also go down very well and should be among the first things added to a page, since they add early gravitas to a page which is likely to prevent speedy deletion. Pages should NOT be added to wikipedia if unless the individual creating them intends to make a significant effort to create real content for the page. cheers stuart (a long-time wikipedia editor, but not a wikipedia admin) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A nearest-neighbor heuristic
On 3/8/07, Eduardo Sabbatella <[EMAIL PROTECTED]> wrote: Regex'like, pattern maching, a lot have been done on this direction. The most complex pattern db / engine is not good enough to beat the modest, simple MC engine. I'm aware of the challenges. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A nearest-neighbor heuristic
On 3/8/07, Eduardo Sabbatella <[EMAIL PROTECTED]> wrote: Oh! Great! Can you give us some info about it ? Are you using MC ? I'm using static analysis of game records to build patterns of what "good" moves look like. I have a compiled-regexp-like data-structure which I'm using train to recognise good moves, but it could also be represented as rules, in the manner Peter suggests. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A nearest-neighbor heuristic
On 3/8/07, Eduardo Sabbatella <[EMAIL PROTECTED]> wrote: Why do you want 1000 rules ? perhaps 200GB of rules is better. ;-) (I couldn't get time to try my idea of a big big big hash) Stranglely enough, that's pretty much how my go-player works. I'm limiting mine so it fits on a DVD, so I can distribute it when it works well enough to be distributed... It's "merely" a question of finding a suitable matching criteria and suitable datastructures to test the rules fast enough. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
From my point of view GTP has two primary virtues: (a) ease of implementation (b) widespread support and interoperability Anything that undermines these two is unwelcome. If you need to do things that GTP doesn't (currently) do, (and i agree that there are many things that it doesn't do that a go protocol would in an ideal world), then a robust bi-directional bridge, released under a liberal license, seems like the logical choice for getting traction. Personally I'd love to see functionality improvements, including: * moving from file to generic URI references * interruption of "thinking" engines * moving beyond ASCII * handicap and ruleset negotiation I'd like to see implementation improvements including: * a validating filter (i.e. a program that sits between the engine and the controller and checks for conformance of both the engine and the controller to the protocol) * test suites for both engine and controller In an ideal world I'd love to see go move to RFC 3920, but that would be quite a disruptive shift. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
On 2/23/07, Heikki Levanto <[EMAIL PROTECTED]> wrote: Sure, but not all such boards are equivalent anyway! Add a stone to the board. Add another stone to one of its liberties. Add a third stone to any (empty) liberty of the last stone. There are three possibilities. Choose the one that maximises the liberties of the string. You have now defined a straight line. Continue this line until you meet a black stone (which must be part of the original line). I guess you meet the beginning of the line, where it all started. How big portion of the board is now filled with black stones? That can vary depending on the properties of the grid. In the simple case you have drawn a circle of a fairly small size (say 19). In another simple case you have filled the whole board, and used many more stones (say 361). In some cases you have filled half the available points, or some other fraction. How big will this fraction be on a totally random grid? What, exactly, do you mean by "a totally random grid"? There is no single obvious (to me) way of distributing vertexes between nodes. I can think of several interesting ways, but no single obvious way. a) start with a conventional board, add random "wraps" at the edges (makes for convenient visualization) b) start with an empty graph with n^2 nodes and pick random pairs of nodes and add a vertex between them if neither already has 4 vertexes (hard to visualize, risks disjoint boards) c) start with a conventional board, pick a random pairs of nodes and a a random vertex in each node. Switch the end points of the two vertexes if the result is not a disjoint graph. Repeat N times. ... It could easily be argued that only (a) results in a grid at all... cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] documentation for the IGS protocol ?
On 2/22/07, Unknown <[EMAIL PROTECTED]> wrote: On Thu, 2007-02-22 at 17:50 +, Stuart A. Yeates wrote: > Does anyone know of a document outlining the IGS protocol? > > There are a number of programs and servers which support the IGS > protocol, including the IGS server. I am trying write a tool to > interact with these servers and would prefer not to have to reverse > engineer the protocol from the programs, especially since most > implement only a very small handful of commands. This one looks reasonable complete and original (though a bit verbose): http://www.koders.com/noncode/fid2C78D24147B76E1CF1196C20428DC7BC62715F38.aspx This looks excellent. Thank you very much. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] documentation for the IGS protocol ?
Does anyone know of a document outlining the IGS protocol? There are a number of programs and servers which support the IGS protocol, including the IGS server. I am trying write a tool to interact with these servers and would prefer not to have to reverse engineer the protocol from the programs, especially since most implement only a very small handful of commands. I'm aware of http://panda-igs.joyjoy.net/java/gGo/igscp/IGSCP_draft.txt which is a set of extensions to the protocol, but which doesn't really discuss the protocol itself. The activities I'm interested in engaging with are: a) finding players worthy of watching b) watching their games c) playing games myself So I think I'm looking at most of the protocol. I'm currently not having much luck by trial and error, since at least one server locks out badly behaved clients... cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
On 2/22/07, steve uurtamo <[EMAIL PROTECTED]> wrote: > I'm not sure I agree with this. I hypothesize that 2d, 3d, 4d, torus, > or any other shape is completely irrelevant with regard to game play. > The only thing that matters is the graph topology. it is true that the only thing that matters is graph topology. it is also true that graph topology cannot be separated from the actual topology of the surface. dimensionality of the embedding space is irrelevant -- topology of the embedded surface is quite important. you should be able to extract the topology of the graph from any embedded surface upon which it can be drawn and vice-versa. If I take a plane, I can draw a 9x9 board on it or a 19x19 board on it. I can also draw the previously mentioned circular / cylindrical board on it. Could you explain how you propose to extract the topology of these, given only the fact that I have drawn them on a plane? I don't see it cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
On 2/21/07, alain Baeckeroot <[EMAIL PROTECTED]> wrote: Le mercredi 21 février 2007 02:10, Antonin Lucas a écrit: > No need for those difficulties, you can play along this board : > > http://www.youdzone.com/go.html I think this is not a torus, even if each vertice has 4 neighbours. I can easily mentally transform this into a cylinder, with an rectangular lattice and additional connection on the borders to have 4 neighbours. I agree If this were a torus, there would be links between the inner ring and the outer ring of vertexes. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Serializing a very large object in Java
I serialised some very large Markov models (tens to low hundreds of megabytes) for my PhD using java serialisation. A couple of hints: *) they can be faster if you compress them (I used the standard Java libraries). Disk access was the limiting factor in my case and compression (I got 80% compression routinely) eased this bottleneck. *) write functions to allow standard tail recursion optimisations to performed by the compiler. I admit I never actually tested the effectiveness of this, but it should improve with successive generations of compiler. http://en.wikipedia.org/wiki/Tail_recursion *) I only ever serialised classes of trivial structure which other classes acted upon. I don't recall serialisation ever breaking. If the classes you are serialising are the same classes you're changing every time you make a minor change to your algorithm, that many change. Yes, this breaks the vision of objects as both the data and the algorithms acting on them. *) If your data structure is very deep (which I imagine it is, if you're seeing stack overflows), you may be better to store pointers to every node in a hashtable (which is iterated though by the serialiser) and serialise that. *) The command line option "-Xss" controls the size of the stack (with the Sun JVM). Use it just like the other memory options. *) as pointed out elsewhere, this is probably not an ideal archival format. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Is skill transitive? No.
On 1/31/07, Tapani Raiko <[EMAIL PROTECTED]> wrote: > I imagine that the most significant intransitivity would be would be in > relation to the bots (principally GnuGo?), because some players have played > dozens (maybe hundreds) of games against these bots and their playing style > is likely to have been modified by the experience. True. Another effect that might appear is if part of the players are developing in skill and at the same time switching to stronger opponents. Or perhaps some are better in changing their style (risk level) according to opponent strength. Maybe CGOS data would be the best: lots of games between a limited number of stable players. "Best" for proving beyond a shadow of a doubt that intransitivity exists in game playing? yes. "Best" but not necessarily best for proving that intransitivity exists in ways that matter to most users of ELO-type systems? no. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Is skill transitive? No.
On 1/31/07, Tapani Raiko <[EMAIL PROTECTED]> wrote: Even if each player's performance is asymmetrical but identical, the difference of performance becomes symmetrical again. But still, intransitivity can be seen from results of matches. If one has enough results of N people playing against each other, one could use the vector of performances against each opponent as an input to some machine learning method, such as a neural network or principal component analysis. I would assume that the first principal component would represent strength and the second would give some kind of intransitivity. If someone has result data with dense enough pairings, I could run some experiments. Would the results of kgs (or similar) games being appropriate if one considered only un-handicapped games? I imagine that the most significant intransitivity would be would be in relation to the bots (principally GnuGo?), because some players have played dozens (maybe hundreds) of games against these bots and their playing style is likely to have been modified by the experience. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] an idea... computer go program's rank vs time
On 1/25/07, Don Dailey <[EMAIL PROTECTED]> wrote: I also had a difficult time producing a player that was less than 200 ELO stronger than a random player. Even a single play-out, which seems hardly enough to discriminate between moves, is enormously stronger than a random player.It was pretty much like this: ASSUME computer is black 0. with probably P, play a random move (using the same selection methodology as the random player) 1. play 1 random game. 2. If black wins, play one of the first N black moves in the play-out (all-as-first, for me it's some-as-first.) 3. If white wins, play one of the black move NOT in the play-out. 4. Crush a random player! Surely by varying P, you can get a player arbitarily close to the random player? Or am I missing something? cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Can a computer beat a human?
If god is building it, does it need to be in the universe? cheers stuart On 1/24/07, alain Baeckeroot <[EMAIL PROTECTED]> wrote: Le mercredi 24 janvier 2007 19:56, Stuart A. Yeates a écrit: > Since no one has mentioned bounding memory, a complete lookup table (a > complete table of correct moves, perfect-hashed by board state) should do > the trick. With 10^170 legal position for 19x19 what would be the size of this table ? I m afraid we cannot build it with all the matter in visible universe. Cheers. Alain ___ 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] Can a computer beat a human?
On 1/24/07, Nick Apperson <[EMAIL PROTECTED]> wrote: In my original question I stated minimum resources. I agree with you that lots of memory could be highly useful: "... I would say a computer with perfect software, 32 GB of RAM (so a lot) and a 300 Mhz processor (slow processor) would be able to beat a human." (from my original post) So it sounds to me like most people think that if we had a perfect program, computers would be able to win. So at this point hardware will only allow us to get away with writing less perfect code. On 1/24/07, Stuart A. Yeates <[EMAIL PROTECTED]> wrote: > > On 1/24/07, Don Dailey <[EMAIL PROTECTED] > wrote: > > > I am fairly sure a perfect program would be impossible, even among > > the set of all possible programs that could find a move within let's > > say 60 seconds per move. > > > Since no one has mentioned bounding memory, a complete lookup table (a > complete table of correct moves, perfect-hashed by board state) should do > the trick. > You are right. It's been a long thread and I'd forgotten that. sorry stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Can a computer beat a human?
On 1/24/07, Don Dailey <[EMAIL PROTECTED]> wrote: I am fairly sure a perfect program would be impossible, even among the set of all possible programs that could find a move within let's say 60 seconds per move. Since no one has mentioned bounding memory, a complete lookup table (a complete table of correct moves, perfect-hashed by board state) should do the trick. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Planet Computer-Go
More correctly, a planet aggregates RSS feeds (rather than blogs). This means that you can add things like the the RSS feeds from version control systems, wikis, mailing lists, etc, etc Have you trawled through http://senseis.xmp.net/?GoBlogs ? cheers stuart On 1/17/07, Urban Hafner <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hej everybody, I'd like to announce Planet Computer-Go at http://computer-go.bettong.net. This is a website that aggregates all the blog posts about Computer-Go. Unfortunately it's very hard (at least for me) to find blog about computer go. I mean googling for "computer go blog" is obviously out of question ;) So, I depend on all of you. If you have a blog that is about computer go (even if only marginally), please contact me so I can add you to the site. Urban - -- http://bettong.net - Urban's Blog -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD8DBQFFrjGnggNuVCIrEyURAgKmAKC4tSWYIrvH7d7U8U4lftfrWdrPWgCfRxkK tyjKWpYn9Hasu/Dvd91aLGQ= =tpGc -END PGP SIGNATURE- ___ 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] Testing against gnugo
A closely related question: Is there a test suite for GTP, other than using the various forms of TwoGTP? I've got a computer-go player for which I'm currently writing an interface to GTP, and would like to test it comprehensively, including the moves that TwoGTP doesn't seem to use. I'm not averse to writing my own junit suite for GTP, but would rather not duplicate anyone else's work (also, my misunderstandings of the protocol are like to present themselves in both my implementation and my tests...). cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Interesting problem
Is there a reason why we need to decide, in advance, which of these many candidates should be the anchorman? If we set up a whole swathe of them, surely a week of random even games answers many of these questions and gets us well on our way to a stable basis for a 19x19 competition? Maybe after the first 100 games between each pairing we can even play at random handicaps. I realise that there are questions that even this will not answer, but at least we will have numbers to argue over. I suggest: a) everyone who has knows of a reasonable contender for the role posts a URL and details of how to set it up. b) those of us who have access to a machine that can reasonably run a go player for a week offer to host / run one of these c) once the resource constraints become clear it may be possible to host more than one player per machine. I'm more than happy to volunteer a machine week for such a purpose, and a couple of hours to set a player up. Unfortunately my own computer-go player will probably not be robustly playable in time. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Anchor Player
On 12/21/06, Jacques Basaldúa <[EMAIL PROTECTED]> wrote: Handicap play is a *different* problem. The rules of go include rules for handicapping. It seems to me that this implies that a complete solution for the game of go must include the ability to play such games. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Anchor Player
Increasing komi is much easier than placing stores, but a much weaker representation of how go games are actually played in the real world. cheers stuart On 12/15/06, Hideki Kato <[EMAIL PROTECTED]> wrote: Increasing KOMI is much easier than placing stones, right? Jacques Basaldúa‚³‚ñ <[EMAIL PROTECTED]>: >I would like to take part in the 19x19 competition. >I also prefer kyu rating to Elo, but I got the impression that >you were relating kyu rating with handicap games (that is >usually done by human players). > >I think handicap is a bad idea for computers. Handicap >requires human intelligence to understand how the playing >style must be changed. It completely ruins fuseki databases >and may also make josekis that are good under equal play >too slow. Of course, if you pretend to ruin fuseki database >programs, its a good idea. But I think dan/pro level fuseki >is not only legitimate, but probably the best possible fuseki >and it can be played in ultrablitz which preserves computing >time for later moves. The only drawback is 10 Mb of >disk space. Any silly welcome video is heavier than that. > >I suggest, if handicap is implemented, it should be optional. > >Jacques. >___ >computer-go mailing list >computer-go@computer-go.org >http://www.computer-go.org/mailman/listinfo/computer-go/ -- [EMAIL PROTECTED] (Kato) ___ 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] Are there researches about human annotation to gamerecords ?
On 12/14/06, Chrilly <[EMAIL PROTECTED]> wrote: > If you had such annotated games, wouldn't you also need an impressive > English language parser? Even more impressive if you consider the > task of parsing English-as-a-second-language dialects. > > I do not understand the meaning of this sentence. Could you please explain it more explicetly? If I understand correctly, the point was that: (a) parsing English is hard (b) most English language comments on Go games are made by those for whom English is a second language, who don't use "correct" English :. (c) (b) is likely to make (a) even harder. Personally I disagree, but that's entirely off topic. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language choices
On 12/4/06, Peter Drake <[EMAIL PROTECTED]> wrote: The three most important things seem to be: 1) Run java in -server mode. This appears to double speed for no effort I understand this is largely the old optimize for processing or optimize for interactivity trade off. It's almost as old as multitasking computers. Sun's Java out of the box is optimized for interaction. 2) As you say, avoid creating objects. For example, instead of creating a new array each time a method is invoked, make the array a field and just clear it out when you need a "new" one. Similarly, instead of Foo x = y.clone(); do something like x.copyDataFrom(y); where of course you have to write copyDataFrom(). There are a related class of optimizations here. Object creation on the heap, as you've observed can be slow and has a delayed penalty for object destruction (which may or may not be reflected in profiling). You can avoid this by reusing objects, or by allowing the interpreter to allocate as many as possible objects on the stack. I haven't looked at this in at least two generations of Java compilers, but it used to be faster to allocate four ints on the stack called one, two, three and four than an array of four ints, and if you're worried about the memory footprint / cache efficiency, then the stack frame is already in memory. The code is necessarily more complex to write, but if you already have a known-working version, you can write / generate a comprehensive suite to confirm they perform identically. 3) Algorithmic improvements are always more important that fine-tuning. Indeed. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Making Java much faster
Other tricks for faster java include ensuring that, wherever possible, you use the final, static and private keywords. This enables the compiler to apply more compilation tricks in more places. Obviously there are places where you sholdn't use these (think interfaces), but in the inner loop they can have an impact, particularly in a multi-threaded application (because they avoid needing to test for locks). If memory is a stumbling block and you have complex object stuctures, you may also want to set references to objects to null explicitly when you know they're no longer needed. cheers stuart On 11/29/06, Graham Thomson <[EMAIL PROTECTED]> wrote: You can also squeeze a little more runtime performance by increasing the size of object nursery. The commands would be: java -XX:NewSize=256m -Xms512m -Xmx512m -server MyApp The NewSize command alters the object nursery size - note that this is in the addition to the heap size. So if you had 1G of memory on your machine, these sizes would be good choices - 256M for the object nursery, 512M for the heap, and 256M for your OS. Tweaking the nursery / heap size ratio for best performance is of course, application dependant. Cheers, Graham. On 29/11/06, William M. Shubert <[EMAIL PROTECTED] > wrote: > > To be more specific, "-server" tells java to spend more time on the > compilation. This is good if you compile a little bit of code and run it > over and over, but it makes programs seem sluggish at first and take a > long time to start up, which is why it isn't the default. > > Also, the documentation says that "-server" will take up a lot more > memory for the compiled code. I haven't verified that myself though. > > On Tue, 2006-11-28 at 21:44 +, Lucas, Simon M wrote: > > Both do just in time compilation, > > but the -server option uses more > > optimisation tricks. Sometimes these > > make a significant difference, sometimes not. > > > > Without the JIT, it would be *very* much slower. > > > > Best regards, > > > >Simon Lucas > > ___ > 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/
