Re: [computer-go] 19x19 CGOS
19x19 server: I have changed 10 minutes to 30 minutes per side. I have modified the anchors (but the --positional-superko option is seemingly not recognized; I'll correct that later). Olivier ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 19x19 CGOS
The anchors are: /usr/games/gnugo --mode gtp --score aftermath --capture-all-dead --chinese-rules --level 0 /usr/games/gnugo --mode gtp --score aftermath --capture-all-dead --chinese-rules --level 10 The numbers (1200 and 1800) are arbitrary; all suggestions welcome, as for the command-line above. I have a trouble with the positional superko, I'll check that soon. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] 19x19 CGOS
How about leaving gnugo 10 at 1800 and let gungo level 0 float for a while. See what rating gnugo level 0 gets, then lock it there as an anchor. If these two programs aren't 600 points apart and you anchor them that way it will prevent the rating system from stabilizing. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Teytaud Sent: Friday, October 26, 2007 11:37 PM To: computer-go Subject: Re: [computer-go] 19x19 CGOS The anchors are: /usr/games/gnugo --mode gtp --score aftermath --capture-all-dead --chinese-rules --level 0 /usr/games/gnugo --mode gtp --score aftermath --capture-all-dead --chinese-rules --level 10 The numbers (1200 and 1800) are arbitrary; all suggestions welcome, as for the command-line above. I have a trouble with the positional superko, I'll check that soon. ___ 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
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 #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
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
Bob Myers [EMAIL PROTECTED] writes: Many of those complaining about XML don't seem to really know too much about it. The problem with XML is, that most people using it don't know anything about it and possible alternatives, using XML for everything, even when there are better alternatives available. XML as an technologie is not very interesting because it doesn't solve any problem, that wasn't solved before. The single advantage of XML is quite a bit of libraries and tools (but hey, there are formats with much more available libraries and tools, say S-Expressions) and that XML is taught to everyone today. By the way, XML does have quite some overhead and there are many platforms like embedded systems, where handling XML is much too expensive. And there is also quite some processing overhead at runtime. Not very much for a single application on modern PC hardware, but there is a cost and there are alternatives in most cases that gives you everything that XML gives you without those additional costs. So it's always good to know your tools and there alternatives. XML for everything ist just brain-dead. Griping that it's too big is roughly equivalent to wanting to go back to six-bit character encodings. That's bullshit. There are file formats with all possibilities of XML but without overhead. If you use XML only via tools and everyone knows, it's not humand readable, why not use binary formats? Yes, you can use XML and compress it, but only on disk. In memory you still have all this overhead and quite some big and complex libraries. The point is that XML offers an incredibly rich environment of transformability and extensibility and interoperability. S-Expressions offers an much richer environment of transformability and extensibility and interoperability. So what? a well-established format such as Dublin Core or an extension thereof To embed metadata of any standard in a file format you don't have to use XML. 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. The problem is not the syntax, that's easy and solved long ago in various other formats. Nothing new here. The real problem is semantics and there XML is of no help. Yes, XML has it's uses. It's a reasonable format for technical documents and that's why DocBook is really nice (if you really need different representations -- I would never use it if I have only need for one representation, say papers in journals; in this cases specialized format like LaTeX are much more powerful and expressive and also easier to handle). And in quite some cases XML does a good job as intermediate format for data exchange (but is often quite a mess as wire format in network protocols -- worst of two worlds in this case). As someone pointed out, using XML would lay to rest once and for all any questions about character encodings. Huh? You think this would only be possible with XML? It's a really simple problem with quite some solutions, all much simpler than running to XML. 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. Oh yes, go back in time to the 1960. Yea, hierachical databases rules, relational databases do suck so hard. Wait? When and why are RDBMS developed? Hmmm... there were problems with hierachical databases? But XML is so cool, there can't be any problems or drawbacks with all these cool tools available... What we need is a new format defined ground-up from an XML perspective. Please, n! -- Until the next mail..., Stefan. pgpDD73fn0wAG.pgp Description: PGP signature ___ 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
In message [EMAIL PROTECTED], Bob Myers [EMAIL PROTECTED] writes 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, that is not the problem. The problem is that if there are two standards, programmers will split their efforts between them, supporting neither correctly, and causing far more incompatibility problems than we have at present. Even now, with only one format, there are enough problems in moving an SGF record from one application to another. 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. Will this round-tripping be done by some magic bug-free program that you are able to provide? If so, could you please start with the much simpler task of providing one that will round-trip SGF-SGF, taking out all the incompatibilities with the standard and preserving all the information? Nick P.S. Bob, could you please configure your intelligentgo.org domain so that it no longer forwards to me all the emails send to its webmaster? -- Nick Wedd[EMAIL PROTECTED] ___ 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
Many of those complaining about XML don't seem to really know too much about it. Dude. It's a file format. File formats don't solve problems. Data structures solve problems. XML is not a data structure, it is a very loosely specified way to arrange tags. By becoming so multipurpose it has the advantage of being able to be modified to do most anything, and the disadvantage of convincing many, many people that if they put it into XML that you'll be able to read it with your XML tools. I think that the 3-character extension is so easy to recognize that people tend to assume that it represents a very stable, steady and reliable way of moving information around. That'd be an error. s. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 19x19 CGOS
Don Dailey wrote: Who is running gnugo 10?You must using the right options. Here is how I run it: gnugo --mode gtp --score aftermath --capture-all-dead --chinese-rules --positional-superko You can skip --score aftermath, it has no effect when --mode gtp is used. (Without --mode gtp it would instead try to score the position but complain that no position was loaded with the -l option.) There is also a min-level and max-level setting - not sure what that does but I think this puts in some default level mode which is reasonbly strong. When playing without time controls you only have to specify --level n to play at level n, where level 10 is default. When playing with time controls GNU Go doesn't have infrastructure to spend a specific amount of time or abort the move generation based on time constraints. Instead it adjusts its playing level after each move, decreased level if it plays too slowly, increased level if it plays unnecessarily fast. This control is kind of crude and it's advisable to limit how high the level may become. Also a lower limit is sometimes useful as GNU Go tends to be rather erratic (more so than usual, that is) at really low level. Thus --min-level and --max-level sets these lower and higher limits that the time control is allowed to adjust the level between. By default min-level is 0 and max-level is 10 or the value set by --level, whichever is highest. /Gunnar ___ 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 Myers wrote: Many of those complaining about XML don't seem to really know too much about it. That is exactly my point. I don't know and I don't want to know! SGF is fine. It has been stable for years because there is no problem at all. Should we find a problem, there is a straightforward solution: a new SGF version. At the end, either creating your own XML parser (by experience, the best option) or entering the nightmare of depending on someone else's library, bugs, updates, limitations, etc. costs A LOT OF TIME. For what? For nothing. Again, sgf works fine. Nothing would be as stupid as having go games split in 2 incompatible formats. Two formats for the same thing is just a tax on go development: Its not enough with one effort for making your program compatible you have to do it twice. Who wins anything with that? I can't guess. Jacques. ___ 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] 19x19 CGOS
At 10 minute time limits Many Faces rated over 2000 and was top of the list. At 30 minutes it's 1650. Many Faces 11 was tuned for the machines in the 1990s, and clearly it needs work for modern machines. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Fotland Sent: Friday, October 26, 2007 6:13 PM To: [EMAIL PROTECTED]; 'computer-go' Subject: RE: [computer-go] 19x19 CGOS I puton Many Faces version 11, but it might not be playing at fill strength. It ouwld be nice if I can click on a game to see the sgf record. right now it gives an error. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Teytaud Sent: Friday, October 26, 2007 9:15 AM To: computer-go Subject: [computer-go] 19x19 CGOS The cgos 19x19 server is seemingly ok, the port 6919 is now opened for all the universe. The name of the machine is cgos.lri.fr (and not pc5-120.lri.fr as previously). The port is 6919. It is 19x19, 10 minutes per side for testing; I will move to something longer later (depending on what people prefer, I'll do a weighted average of durations suggested on the mailing list :-) ). http://www.lri.fr/~teytaud/cgosStandings.html Unfortunately, I'll be away from my email from tomorrow to wednesday and will not be able to correct the troubles that people will almost surely find in this installation; sorry for that. The installation is a bit complicated in order to avoid troubles due to the firewall and I am almost sure that some troubles will appear very soon :-) All comments welcome (in particular in the next hours as I am still close to my computer a few hours :-) ). [EMAIL PROTECTED] ___ 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] 19x19 CGOS
ver 11 does 1 ply search with quiescence so there is no way to crank it up. Ver 12 uses full board alpha beta, but it's too buggy right now to put on cgos. if this server stays up for a while, I'll use it for testing of ver 12. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Tayek Sent: Saturday, October 27, 2007 11:05 AM To: computer-go Subject: RE: [computer-go] 19x19 CGOS At 09:53 AM 10/27/2007, you wrote: At 10 minute time limits Many Faces rated over 2000 and was top of the list. At 30 minutes it's 1650. Many Faces 11 was tuned for the machines in the 1990s, and clearly it needs work for modern machines. i have a copy of 11. is there any way to crank it up other than level 10. maybe a config file somewhere? have you considered a highly configurable version 12 for some of us on the list? thanks --- vice-chair http://ocjug.org/ ___ 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] 19x19 CGOS
On Oct 27, 2007, at 9:53 AM, David Fotland wrote: At 10 minute time limits Many Faces rated over 2000 and was top of the list. At 30 minutes it's 1650. Many Faces 11 was tuned for the machines in the 1990s, and clearly it needs work for modern machines. I don't understand that. The anchor does not take advantage of the time-limit change. I always uses about 3 minutes. It probably means that the 2000 rating was a fluke. Christoph ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Crazy Stone on 19x19 CGOS
Hi, I have just connected Crazy Stone (CS-8-26-10k-1CPU). It uses 10,000 playouts per move, and runs on 1 CPU. It should finish all its games in less than 5 minutes. In my tests, it scores 41% against GNU Go 3.6 Level 10, and 73.5% against MoGo_release3 at 10k playouts per move (the playouts of Mogo are about 10% slower than those of Crazy Stone). These tests were run over 600 games, starting from 300 positions with two stones located at random (but not on the first two lines), and alternating colors. (computational power provided by the Grid5000 project: https://www.grid5000.fr/mediawiki/index.php/Grid5000:Home (they ask for advertisement in exchange)) I am a bit surprised that Crazy Stone won so easily against MoGo, because on the old server, it looked much stronger: http://cgos.boardspace.net/19x19/standings.html Olivier, do the numbers there indicate the number of playouts? Or is it playouts per processor? Maybe I messed up something. The log of Mogo indicates: 1 simulations(average length:0) done, time used: 2.94 seconds.( 3401.4 games/sec) So, it looks OK. I have the feeling that, maybe, MoGo overfits GNU more than Crazy Stone does. In particular, MoGo's romantic opening style is completely confusing for GNU, but Crazy Stone has no problem with it. I'll run Mogo 10k against GNU to check. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] 19x19 CGOS
NO, it's because gnugo got stronger with longer time limits. When the time limit got longer Many Faces started taking 1 minute instead of 5 minutes, so there may be a bug in Many Faces GTP interface time control. DAvid -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christoph Birk Sent: Saturday, October 27, 2007 12:07 PM To: computer-go Subject: Re: [computer-go] 19x19 CGOS On Oct 27, 2007, at 9:53 AM, David Fotland wrote: At 10 minute time limits Many Faces rated over 2000 and was top of the list. At 30 minutes it's 1650. Many Faces 11 was tuned for the machines in the 1990s, and clearly it needs work for modern machines. I don't understand that. The anchor does not take advantage of the time-limit change. I always uses about 3 minutes. It probably means that the 2000 rating was a fluke. Christoph ___ 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] 19x19 CGOS
On Oct 27, 2007, at 3:17 PM, David Fotland wrote: NO, it's because gnugo got stronger with longer time limits. Did it? I thought the anchor (gnugo-level-10) plays just that, at level10. How would it get stronger? When the time limit got longer Many Faces started taking 1 minute instead of 5 minutes, so there may be a bug in Many Faces GTP interface time control. That might be the explanation. Christoph ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] 19x19 CGOS
Because gnugo has time control and when time is short it adjusts the level down between moves. I think with th 30 minute control it is staying at level 10 the whole game. I just found a time control bug in Many Faces, and it's been playing at level 3. It should get stronger soon :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christoph Birk Sent: Saturday, October 27, 2007 3:51 PM To: computer-go Subject: Re: [computer-go] 19x19 CGOS On Oct 27, 2007, at 3:17 PM, David Fotland wrote: NO, it's because gnugo got stronger with longer time limits. Did it? I thought the anchor (gnugo-level-10) plays just that, at level10. How would it get stronger? When the time limit got longer Many Faces started taking 1 minute instead of 5 minutes, so there may be a bug in Many Faces GTP interface time control. That might be the explanation. Christoph ___ 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] 19x19 CGOS
Now I remember - the min-level and max-level settings should be set on the anchor player to make it play exactly the same strength, whether the machine is loaded or not, especially if the anchor is run on more than one machine. - Don David Fotland wrote: Because gnugo has time control and when time is short it adjusts the level down between moves. I think with th 30 minute control it is staying at level 10 the whole game. I just found a time control bug in Many Faces, and it's been playing at level 3. It should get stronger soon :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christoph Birk Sent: Saturday, October 27, 2007 3:51 PM To: computer-go Subject: Re: [computer-go] 19x19 CGOS On Oct 27, 2007, at 3:17 PM, David Fotland wrote: NO, it's because gnugo got stronger with longer time limits. Did it? I thought the anchor (gnugo-level-10) plays just that, at level10. How would it get stronger? When the time limit got longer Many Faces started taking 1 minute instead of 5 minutes, so there may be a bug in Many Faces GTP interface time control. That might be the explanation. Christoph ___ 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] 19x19 CGOS
On Oct 27, 2007, at 3:59 PM, David Fotland wrote: Because gnugo has time control and when time is short it adjusts the level down between moves. I think with th 30 minute control it is staying at level 10 the whole game. But even now it is only using 3 minutes ... it was not short of time even during 10 minute games. Christoph ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] 19x19 CGOS
You're right. the problem was Many Faces was playing at level 3 instead of 10. I fixed it and now Many Faces is taking 5 minutes per game rather than 1 minute. It's rating should come back up now. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christoph Birk Sent: Saturday, October 27, 2007 4:50 PM To: computer-go Subject: Re: [computer-go] 19x19 CGOS On Oct 27, 2007, at 3:59 PM, David Fotland wrote: Because gnugo has time control and when time is short it adjusts the level down between moves. I think with th 30 minute control it is staying at level 10 the whole game. But even now it is only using 3 minutes ... it was not short of time even during 10 minute games. Christoph ___ 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] SGF Viewer for Linux
Anyone recommend a free SGF viewer for Linux? I'd really like to find something like SCID but for Go. -Josh ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] SGF Viewer for Linux
Since you mention SCID, I assume you are looking for something with databasing features as well, instead of just a plain SGF editor. If all you want is just plain SGF editing, glGo, qGo, CGoban3 are all great on Linux. As for databasing apps, you can check out the still-relatively-new-and-under-development version of baduK at : http://baduk.sourceforge.net/ Moreover, Kombilo ( http://www.u-go.net/kombilo/ ) is cross-platform as well. On 10/28/07, Joshua Shriver [EMAIL PROTECTED] wrote: Anyone recommend a free SGF viewer for Linux? I'd really like to find something like SCID but 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] SGF Viewer for Linux
2007/10/28, Joshua Shriver [EMAIL PROTECTED]: Anyone recommend a free SGF viewer for Linux? I'd really like to find something like SCID but for Go. I use qGo and Kombilo. -- Seo Sanghyeon ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
