Re: [computer-go] Re: Open source real time Go server
On Fri, Jan 22, 2010 at 1:46 AM, Stefan Kaitschick stefan.kaitsch...@hamburg.de wrote: 2010/1/19 terry mcintyre terrymcint...@yahoo.com: ( 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] Re: Open source real time Go server
On Mon, Jan 18, 2010 at 9:21 PM, Dave Dyer dd...@real-me.net 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] Fwd: [gnugo-devel] (GNU) Open source real time Go server
On Mon, Jan 18, 2010 at 11:14 PM, Petr Baudis pa...@ucw.cz 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] 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] 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=alllang=atslang2=gpp http://shootout.alioth.debian.org/u64q/benchmark.php?test=knucleotidelang=all http://shootout.alioth.debian.org/u64q/benchmark.php?test=knucleotidelang=gppid=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] 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/
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] 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: [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
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] 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] 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] 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 computer-go@computer-go.org 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] 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] 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] 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] 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
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] 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] 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] 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
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 ! are quotes from the DTD. !-- P is the Paragraph of HTML -- !ELEMENT P (#PCDATA) 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. !-- Each Go file consists of one or several GoGame -- !ELEMENT Go (GoGame*) I believe it is a mistake not to have a protocol version number here. !ELEMENT Application (#PCDATA) !ATTLIST Application format CDATA
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
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 ! are quotes from the DTD. !-- P is the Paragraph of HTML -- !ELEMENT P (#PCDATA) 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. !-- Each Go file consists of one or several GoGame -- !ELEMENT Go (GoGame*) I believe it is a mistake not to have a protocol version number here. !ELEMENT Application (#PCDATA) !ATTLIST Application format CDATA #IMPLIED It seems unfortunate that there is no explicit version number here and no url link to the application website. !ELEMENT Date (#PCDATA) !ATTLIST Date format CDATA #IMPLIED 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. !ELEMENT User (#PCDATA) The user tag is ambiguous, is this a person's name? a user name? a user name on what server? !ELEMENT Copyright (P+) 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. !ELEMENT Rules (#PCDATA) !ATTLIST Rules format CDATA #IMPLIED 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. !ELEMENT Black ((at)*) Using schemas allows the content of tags to be restricted. See also discussion in the docs. !-- This is to take care of SGF tags, which are not translated -- !ELEMENT SGF (Arg*) !ATTLIST SGF type CDATA #REQUIRED !ELEMENT Arg (#PCDATA) 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=detailatid=489967aid=1752711group_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: ?xml version=1.0 encoding=utf-8? ?xml-stylesheet href=go.xsl type=text/xsl? !DOCTYPE Go SYSTEM go.dtd Go GoGame name=* Information ApplicationJago:Version 4.7/Application BoardSize19/BoardSize /Information Nodes Node/ Black number=1 at=D16/ White number=2 at=E16/ Black number=3 at=H13/ White number=4 at=D15/ Black number=5 at=E12/ White number=6 at=C16/ Black number=7 at=G15/ White number=8 at=D17/ /Nodes /GoGame /Go 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] 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: 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] 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] 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] 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?
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] 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?
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] 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] 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
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/
