Re: [computer-go] XML alternatives to SGF
I'm not an authority on SGF, but I am the owner of one of the larger SGF libraries (the KGS archives, 19,599,303 games as of this moment), and author one of the more common SGF editors (CGoban 3). Everybody wants something different from a SGF replacement. The syntax of SGF sucks, but once you write the parser your motivation to see it change drops to near zero. If it had to be replaced, I think JSON would be better than XML just because JSON is lighter and go doesn't really need the features that XML provides. I don't much care about the coordinates. I can't read c5 or cd either, I always use a program to parse. In general human readability isn't something that interests me at all, when I want to see a go game on paper I use the numbered diagrams. What would make my life significantly easier would be a way to searialize comments and tag them with the author instead of one C[] block per node. Breaking up the C[] into comments and figuring out who originally wrote the comment is helpful in some cases on KGS, and the current system is very clumsy. Another thing that would be nice (which a few other people here have mentioned) is a way to specify a path through an SGF tree. The KGS lessons are actually XML files that have bits of SGF embedded in them, describing how to incrementally build the SGF tree you get at the end. The audio in the lesson files is in blocks of base64-encoded SPEEX data. The whole XML file gets put into a ZIP file, packing it down very nicely...whenever people complain about the size of XML, I don't really see the issue, it compresses so nicely that you can easily get rid of the file size problem by a couple calls to zlib or java.util.compress or whatever the equivalent for your language is. So really there are only two things that would make my life easier, but whenever I look at it, and think about all the backward compatibility issues...well, I always decide to move on to something more useful. ___ 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/
[computer-go] SGF Utility
Hi! I put together a small utility that converts coordinate encodings in SGF files to/from the official SGF specification and normal Go board coordinates and optionally format the file to be easier to read. One of the cool uses is to convert a SGF file to standard Go board coordinates, make changes with my favorite text editor, and revert back to SGF coordinates; like this: sgfconvert -pretty -2g -i:game.sgf -o:game+.sgf notepad (or vi) game+.sgf sgfconvert -rws -2s -i:game+.sgf -o:game.sgf The program is written in C# with a GPLv3 license. Documentation, source code, and pre-compiled windows binary can be download from: http://www.codeplex.com/SGFConvert This is the first initial release, so please report bugs if you use the utility. - Phil Garcia http://www.thinkedge.com (My web site) http://www.gotraxx.com (C# program that plays the game of Go)___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] 19x19 CGOS
10 minutes per side should be enough for Many Faces 11. Version 11 has fixed search limits, and only does time management if it runs low on time. It can usually play a game in 10 minutes on the computer I'll use. It will be slower against Mogo since the games are longer and there might me more unsettled situations to read. If you do add more time, 15 or 20 minutes per side should be enough. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Fant Sent: Tuesday, October 23, 2007 1:27 PM To: computer-go Subject: Re: [computer-go] 19x19 CGOS I oppose more time per side. On 10/23/07, Christoph Birk [EMAIL PROTECTED] wrote: On Tue, 23 Oct 2007, Olivier Teytaud wrote: http://www.lri.fr/~teytaud/cgosStandings.html If someone wants to test it, the port is 6919 on machine pc5-120.lri.fr. 10 minutes per side. But only try it if you want to take risks, it is almost surely not stable yet, and the connection might be refused for an unknown reason :-) Am really curious to see MFGO, Crazystone and Mogo play at 19x19. But I suggest allowing more time, at least 20 minutes per side. 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/
[computer-go] MoGo
Is MoGo a commercial or free program? Open or closed source? Linux version available? Thanks in advance :) -Josh ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] 19x19 CGOS
I just tried it, but I can't connect. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christoph Birk Sent: Tuesday, October 23, 2007 1:16 PM To: [EMAIL PROTECTED]; computer-go Subject: Re: [computer-go] 19x19 CGOS On Tue, 23 Oct 2007, Olivier Teytaud wrote: http://www.lri.fr/~teytaud/cgosStandings.html If someone wants to test it, the port is 6919 on machine pc5-120.lri.fr. 10 minutes per side. But only try it if you want to take risks, it is almost surely not stable yet, and the connection might be refused for an unknown reason :-) Am really curious to see MFGO, Crazystone and Mogo play at 19x19. But I suggest allowing more time, at least 20 minutes per side. 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 10/25/07, David Fotland [EMAIL PROTECTED] wrote: I just tried it, but I can't connect. That's expected. Past discussion seems to imply there's some kind of firewall (or similar) blocking external access. ___ 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
GMP (go modem protocol) was invented for direct computer to computer play using a 300 baud modem, before the internet existed. It was used in tournaments since it was easy to connect up serial ports to emulate modems. GTP solves a completely different problem, of go engines communicating with a GUI or referee. GMP is no longer interesting since no one does direct computer to computer connection using modems today. GTP may replace GMP as a tournament method, but it is in no way a replacement for GMP. GMP is simply obsolete, since the problem it solves no longer exists. Replacing sgf with xml is very different, since they do the same thing. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Nowakowski Sent: Tuesday, October 23, 2007 5:57 AM To: computer-go Subject: Re: [computer-go] XML alternatives to SGF On Tue, 2007-10-23 at 08:42 -0400, Don Dailey wrote: GTP pretty much replace GMP.A lot of resistance because GMP was the defacto standard at the time. It would have been foolish to insist on being backwards compatible. GTP was a huge change in protocol with clear benefits. What's being quibbled over now is minor change in the coordinate system at the cost of breaking all existing tools, with the exception of a couple that have implemented this incompatible change. The benefit does not outweight the cost. -Jeff ___ 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] MoGo
Free, Closed, It prefers Linux. On 10/25/07, Joshua Shriver [EMAIL PROTECTED] wrote: Is MoGo a commercial or free program? Open or closed source? Linux version available? Thanks in advance :) -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] MoGo
Free but closed source. There is a linux version, see http://www.lri.fr/~gelly/MoGo_Download.htm On 10/25/07, Joshua Shriver [EMAIL PROTECTED] wrote: Is MoGo a commercial or free program? Open or closed source? Linux version available? Thanks in advance :) -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] XML alternatives to SGF
There is a standard file format like PGN for Go, that uses standard go notation. It's the Ishi Press Go Format used by the original Many Faces of go, and still supported by Many Faces. You might still find files out there with a .go extension. It was invented before sgf, but the go commuinity preferred sgf, I think because the files were smaller. I think Anders supports using Korshelt notation in sgf (E4, etc, with no I). David I'd just like to see adoption of a standard file format for go that is human readable. To me, that requires standard algebraic notation such as E4.I'd definitely prefer to see an sgf-like or PGN-like variant over XML. I can't yet commoent on JSON or YAML. ___ 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
Anders Kierulf, who created the sgf standard for the go program he wrote for his Ph.D thesis in 1990. Search for Smart Go to see his current go program. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason House Sent: Thursday, October 25, 2007 11:45 AM To: computer-go Subject: Re: [computer-go] XML alternatives to SGF On 10/25/07, David Fotland [EMAIL PROTECTED] wrote: I think Anders supports using Korshelt notation in sgf (E4, etc, with no I). Who or what is Anders? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 19x19 CGOS
Hi David, I argue that the matches should be longer, perhaps 30 minutes per side.They should more closely resemble time controls used in a serious competition. Here is the reason I say that.One could argue that with computers it doesn't matter, they do not need to be constrained as much by our sense of time - they do not feel pressure or get rattled if they play too fast and they don't get bored or lose focus if they play too slow. I've argued that way myself many times. However, the choice of time control, in my estimation, has a good chance of influencing the outcome, especially if we view this as a test of a strong commercial program versus a new experimental technology, which I think it is. Mogo is a program that clearly performs better with more time.I suspect that MFGO is a program that is close to optimal at 10 or 15 minutes. I can't say that for sure, perhaps you can give us your insights on that. In such a case what is fair depends on the point of view of the observer. If someone wanted to see Mogo dominate such a match he would consider short time controls unfair and the opposite would be true if one wanted to see Many Faces win. Of course I could be wrong, perhaps Many Faces is the one that would benefit more from extra time - but I'm working from the assumption that Mogo would benefit the most based on my own knowledge of how UCT works. Regardless of the time control used another issue is the selection of hardware. Doubling the computer power effectively doubles the programs thinking time. Having considered all of these issues, and also taking into consideration that this is a contest of sorts, it makes sense that we should testing at a level that simulates or at least approaches serious computer chess time-controls. Certainly no faster than 30 minutes per side.These are levels at which most humans will take the results seriously. In addition to this, it makes sense to know what hardware and what time-setting is being used. Many programs on CGOS were set to play very fast, often indicated their level in the name of the program something like mogo4k or something similar. So if we set a liberal time control on CGOS 19x19 we could publish the identify of the players and draw conclusion based on that. Mogo could be tested at several levels and/or hardware configurations and so could Many Faces. It's not difficult to set up a rotating script for logging off one bot and starting up another. (By the way, the right way to do this is to select the bot RANDOMLY, not to rotate back and forth.) The server does report the time each side spent calculating in the SGF files, although it's not reported on the web sites, so this is useful information if we are considering the scalability of programs. My feeling is that there is likely to be a crossover point - that MFGO will win at time-controls faster than this and Mogo will win at time-controls slower than this.That point may be beyond what we can test, or it may be testable on the CGOS server soon. By the way, I would probably argue for longer than 30 minutes per side, but for a server like CGOS that would involve a long wait between matches. Anyway, that's my 2 cents. - Don David Fotland wrote: 10 minutes per side should be enough for Many Faces 11. Version 11 has fixed search limits, and only does time management if it runs low on time. It can usually play a game in 10 minutes on the computer I'll use. It will be slower against Mogo since the games are longer and there might me more unsettled situations to read. If you do add more time, 15 or 20 minutes per side should be enough. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Fant Sent: Tuesday, October 23, 2007 1:27 PM To: computer-go Subject: Re: [computer-go] 19x19 CGOS I oppose more time per side. On 10/23/07, Christoph Birk [EMAIL PROTECTED] wrote: On Tue, 23 Oct 2007, Olivier Teytaud wrote: http://www.lri.fr/~teytaud/cgosStandings.html If someone wants to test it, the port is 6919 on machine pc5-120.lri.fr. 10 minutes per side. But only try it if you want to take risks, it is almost surely not stable yet, and the connection might be refused for an unknown reason :-) Am really curious to see MFGO, Crazystone and Mogo play at 19x19. But I suggest allowing more time, at least 20 minutes per side. 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
Re: [computer-go] XML alternatives to SGF
I tried to manually compose a JSON example to roughly match the xml
example Stuart Yates gave. I don't know if I did it right because I'm
not an expert on JSON although I've used it a little bit in javascript
programming:
{
White: John Doe,
Black: Fred Johnson,
BoardSize: 19,
Moves: [ D16, E16, H13, D15, E12, C16, G15 ]
}
The moves can be on separate lines if you want them to.
JSON is designed to be read directly into a data structure in your
program. Square brackets are for lists, strings are quoted and colons
represent records or hashes.
This would be directly read into a data structure in your programming
language of choice.
I'm guessing here because I haven't looked at JSON in C, but it might
place this information in the following data structure:
typedef struct
{
char *White;
char *Black;
int boardsize;
char **Moves;
};
There would have to be some agreement on what to call the names of the
various elements.
Variations can be expressed rescursively with JSON, just as in SGF, so
you can make trees if you want to.
- Don
Stuart A. Yeates wrote:
I've been looking further at the jago xml format, and for a very
simple game it looks like:
?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/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 19x19 CGOS
I'd argue that 30 minutes is a good compromise. Among humans, that would be a brisk pace but not blitz - common time controls are 60 or 90 minutes, and much longer for some pro tournaments. For computers, 30 minutes should give enough time to bump up the standard of play a few more kyu, while allowing enough games to be statistically interesting. I'd still like to see handicap games between computers. Some programs, such as Mogo, dominate the field. Some are quite bad. Is the difference one or two stones, or is it nine or 27 stones? The handicap which gives something close to 50-50 ratio would give a useful idea. This would also encourage programs to learn something about how to deal with handicap stones effectively; it would broaden their range of expertise. __ 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
most computer-computer tournaments have used 1 hour per side, and did 5 or 6 rounds over 1 1/2 days. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Fotland Sent: Thursday, October 25, 2007 1:04 PM To: 'computer-go' Subject: RE: [computer-go] 19x19 CGOS I have no problem with longer time controls. Many Faces 11 was tuned to play in about 45 minutes on hardware available in 2000. It won't take advantage of any extra time given. The global search is 1 ply with quiescence, and always will always complete, and the local search sizes are fixed at something like 200 nodes per search. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Dailey Sent: Thursday, October 25, 2007 11:53 AM To: computer-go Subject: Re: [computer-go] 19x19 CGOS Hi David, I argue that the matches should be longer, perhaps 30 minutes per side.They should more closely resemble time controls used in a serious competition. Here is the reason I say that.One could argue that with computers it doesn't matter, they do not need to be constrained as much by our sense of time - they do not feel pressure or get rattled if they play too fast and they don't get bored or lose focus if they play too slow. I've argued that way myself many times. However, the choice of time control, in my estimation, has a good chance of influencing the outcome, especially if we view this as a test of a strong commercial program versus a new experimental technology, which I think it is. Mogo is a program that clearly performs better with more time.I suspect that MFGO is a program that is close to optimal at 10 or 15 minutes. I can't say that for sure, perhaps you can give us your insights on that. In such a case what is fair depends on the point of view of the observer. If someone wanted to see Mogo dominate such a match he would consider short time controls unfair and the opposite would be true if one wanted to see Many Faces win. Of course I could be wrong, perhaps Many Faces is the one that would benefit more from extra time - but I'm working from the assumption that Mogo would benefit the most based on my own knowledge of how UCT works. Regardless of the time control used another issue is the selection of hardware. Doubling the computer power effectively doubles the programs thinking time. Having considered all of these issues, and also taking into consideration that this is a contest of sorts, it makes sense that we should testing at a level that simulates or at least approaches serious computer chess time-controls. Certainly no faster than 30 minutes per side.These are levels at which most humans will take the results seriously. In addition to this, it makes sense to know what hardware and what time-setting is being used. Many programs on CGOS were set to play very fast, often indicated their level in the name of the program something like mogo4k or something similar. So if we set a liberal time control on CGOS 19x19 we could publish the identify of the players and draw conclusion based on that. Mogo could be tested at several levels and/or hardware configurations and so could Many Faces. It's not difficult to set up a rotating script for logging off one bot and starting up another. (By the way, the right way to do this is to select the bot RANDOMLY, not to rotate back and forth.) The server does report the time each side spent calculating in the SGF files, although it's not reported on the web sites, so this is useful information if we are considering the scalability of programs. My feeling is that there is likely to be a crossover point - that MFGO will win at time-controls faster than this and Mogo will win at time-controls slower than this.That point may be beyond what we can test, or it may be testable on the CGOS server soon. By the way, I would probably argue for longer than 30 minutes per side, but for a server like CGOS that would involve a long wait between matches. Anyway, that's my 2 cents. - Don David Fotland wrote: 10 minutes per side should be enough for Many Faces 11. Version 11 has fixed search limits, and only does time management if it runs low on time. It can usually play a game in 10 minutes on the computer I'll use. It will be slower against Mogo since the games are longer and there might me more unsettled situations to read. If you do add more time, 15 or 20 minutes per side should be enough. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Fant Sent: Tuesday, October 23, 2007 1:27 PM To:
Re: [computer-go] 19x19 CGOS
I would prefer 1 hour actually, but it would take a really long time to get a substantial number of games in, so I think for practical reasons we shouldn't go that far. Unless we set up a special server just for Mogo vs ManyFaces. I could do that on my own computer. I'm not sure what the status of the 19x19 server is, if it looks like it isn't going to happen I have another option. - Don David Fotland wrote: most computer-computer tournaments have used 1 hour per side, and did 5 or 6 rounds over 1 1/2 days. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Fotland Sent: Thursday, October 25, 2007 1:04 PM To: 'computer-go' Subject: RE: [computer-go] 19x19 CGOS I have no problem with longer time controls. Many Faces 11 was tuned to play in about 45 minutes on hardware available in 2000. It won't take advantage of any extra time given. The global search is 1 ply with quiescence, and always will always complete, and the local search sizes are fixed at something like 200 nodes per search. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Dailey Sent: Thursday, October 25, 2007 11:53 AM To: computer-go Subject: Re: [computer-go] 19x19 CGOS Hi David, I argue that the matches should be longer, perhaps 30 minutes per side.They should more closely resemble time controls used in a serious competition. Here is the reason I say that.One could argue that with computers it doesn't matter, they do not need to be constrained as much by our sense of time - they do not feel pressure or get rattled if they play too fast and they don't get bored or lose focus if they play too slow. I've argued that way myself many times. However, the choice of time control, in my estimation, has a good chance of influencing the outcome, especially if we view this as a test of a strong commercial program versus a new experimental technology, which I think it is. Mogo is a program that clearly performs better with more time.I suspect that MFGO is a program that is close to optimal at 10 or 15 minutes. I can't say that for sure, perhaps you can give us your insights on that. In such a case what is fair depends on the point of view of the observer. If someone wanted to see Mogo dominate such a match he would consider short time controls unfair and the opposite would be true if one wanted to see Many Faces win. Of course I could be wrong, perhaps Many Faces is the one that would benefit more from extra time - but I'm working from the assumption that Mogo would benefit the most based on my own knowledge of how UCT works. Regardless of the time control used another issue is the selection of hardware. Doubling the computer power effectively doubles the programs thinking time. Having considered all of these issues, and also taking into consideration that this is a contest of sorts, it makes sense that we should testing at a level that simulates or at least approaches serious computer chess time-controls. Certainly no faster than 30 minutes per side.These are levels at which most humans will take the results seriously. In addition to this, it makes sense to know what hardware and what time-setting is being used. Many programs on CGOS were set to play very fast, often indicated their level in the name of the program something like mogo4k or something similar. So if we set a liberal time control on CGOS 19x19 we could publish the identify of the players and draw conclusion based on that. Mogo could be tested at several levels and/or hardware configurations and so could Many Faces. It's not difficult to set up a rotating script for logging off one bot and starting up another. (By the way, the right way to do this is to select the bot RANDOMLY, not to rotate back and forth.) The server does report the time each side spent calculating in the SGF files, although it's not reported on the web sites, so this is useful information if we are considering the scalability of programs. My feeling is that there is likely to be a crossover point - that MFGO will win at time-controls faster than this and Mogo will win at time-controls slower than this.That point may be beyond what we can test, or it may be testable on the CGOS server soon. By the way, I would probably argue for longer than 30 minutes per side, but for a server like CGOS that would involve a long wait between matches. Anyway, that's my 2 cents. - Don David Fotland wrote: 10 minutes per side should be enough for Many Faces 11. Version 11 has fixed search limits, and only does time management if it runs low on time. It
Re: [computer-go] 19x19 CGOS
I'm not sure what the status of the 19x19 server is, if it looks like it isn't going to happen I have another option. Technically it works, but an authorization (for opening the ports for computers out of the laboratory) is still missing. But, if someone else wants to install it, no problem for me :-) Olivier ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 19x19 CGOS
I think I'm going to restart CGOS 19x19 on boardspace. I'll ping the group when I'm ready - probably be tomorrow night. - Don Olivier Teytaud wrote: I'm not sure what the status of the 19x19 server is, if it looks like it isn't going to happen I have another option. Technically it works, but an authorization (for opening the ports for computers out of the laboratory) is still missing. But, if someone else wants to install it, no problem for me :-) Olivier ___ 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
I'd still like to see handicap games between computers. Some programs, such as Mogo, dominate the field. Some are quite bad. Is the difference one or two stones, or is it nine or 27 stones? The handicap which gives something close to 50-50 ratio would give a useful idea. This would also encourage programs to learn something about how to deal with handicap stones effectively; it would broaden their range of expertise. i agree with this, although i think that the top programs already know how to deal with handicap stones. it'd be a great way for everyone else to learn how, too. (since it would confuse and obscure many fixed opening book strategies). 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
On Thu, 25 Oct 2007, Don Dailey wrote: I think I'm going to restart CGOS 19x19 on boardspace. I'll ping the group when I'm ready - probably be tomorrow night. Thanks. Christoph ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 19x19 CGOS
On Fri, 26 Oct 2007, Hideki Kato wrote: I'd like to ask shorter time settings. How about a compromise of 20 minutes. That's 4 times the amount for 9x9 and (about) proportional to the area. Christoph ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 19x19 CGOS
Let me think about that one. How about 22 min 17 seconds per side? Just kidding. I once thought about setting up fast games on CGOS that ran in sync with slow games. The idea is that when a slow game is finished, you can play 1 or more fast games instead of waiting for the next round. I would synchronize things so that you were always guaranteed to be able to play in the next slow game round.It's kind of like playing speed chess and skittles between rounds of a serious tournament. I assume that happens with Go too? They would be rated separately and your bot could choose to play in either one exclusively or both. The time control for the fast games would be considerably brisker than for the other, so that your bot would be busy the majority of the time if that's what you wanted. If I did such a thing I would probably have 5 minutes per side and 40 minutes per side - scheduling 8 fast rounds during the same time 1 slow one was being played. Another more conservative way is 10 minutes and 40 minutes or even 10 minutes and any multiple of 10 minutes such as 60 minutes. But I would start a new slow round when all the players were ready, not necessarily on a fixed schedule. When I finally get around to fixing the server bug, I will look into how difficult to add this, if anyone thinks it's an interesting idea. - Don Christoph Birk wrote: On Fri, 26 Oct 2007, Hideki Kato wrote: I'd like to ask shorter time settings. How about a compromise of 20 minutes. That's 4 times the amount for 9x9 and (about) proportional to the area. 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] XML alternatives to SGF
I saw this on the web a JSON library for C:
JSON-C implements a reference counting object model that allows you to
easily construct JSON objects in C, output them as JSON formatted
strings and parse JSON formatted strings back into the C representation
of JSON objects.
I think I will change CGOS over to using JSON for the game records
:-)Just kidding!
But seriously, a simple system just for storing games would be to use
the same tags that the
xml version uses and use it pretty much like I have below - assuming
that is valid JSON.
Don't worry, I'm not going to push for yet another standard - but I do
hate SGF.
- Don
Don Dailey wrote:
I tried to manually compose a JSON example to roughly match the xml
example Stuart Yates gave. I don't know if I did it right because I'm
not an expert on JSON although I've used it a little bit in javascript
programming:
{
White: John Doe,
Black: Fred Johnson,
BoardSize: 19,
Moves: [ D16, E16, H13, D15, E12, C16, G15 ]
}
The moves can be on separate lines if you want them to.
JSON is designed to be read directly into a data structure in your
program. Square brackets are for lists, strings are quoted and colons
represent records or hashes.
This would be directly read into a data structure in your programming
language of choice.
I'm guessing here because I haven't looked at JSON in C, but it might
place this information in the following data structure:
typedef struct
{
char *White;
char *Black;
int boardsize;
char **Moves;
};
There would have to be some agreement on what to call the names of the
various elements.
Variations can be expressed rescursively with JSON, just as in SGF, so
you can make trees if you want to.
- Don
Stuart A. Yeates wrote:
I've been looking further at the jago xml format, and for a very
simple game it looks like:
?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/
___
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/
