Re: [computer-go] XML alternatives to SGF
On Mon, Oct 22, 2007 at 10:03:56PM -0700, Phil G wrote: To my surprise, GoGui can already read SGF with standard coordinates! :) I think you are muddying the waters by calling non-standard extensions 'standard' coordinates. I don't see any reason why [C4] should be harder to read than [cd]. Not for humans, and not for computers. I see many good reasons for sticking to *one* standard, and everyone using the same. At least for exchange of data - what you use internally in your programs is of course your own business. Even if a new proposed standard would have many benefits, obvious to everyone (which I have not yet seen), I would stuill urge people to consider those benefits carefully, and to weigh them against the problems that arise from having two incompatible standards. Just my personal opinion, of course. - Heikki -- Heikki Levanto In Murphy We Turst heikki (at) lsd (dot) dk ___ 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
From: Heikki Levanto [EMAIL PROTECTED] I don't see any reason why [C4] should be harder to read than [cd]. Not for humans, and not for computers. Actually, C4 is not [cd]. C4 is actually [cf] on a 9x9 board. It's something else on a 19x19 or 13x13 board. The row character depends on the board size. SGF coordinate for a row are labeled top to bottom. Go boards are exactly opposite. In my opinion, it is SGF that uses a non-standard coordinate system to represent positions on a Go board. As a community, I believe we can improve SGF by extending the specification slightly to allow points to also be encoded in standard coordinates and depreciated, admittedly slowly, the use of the old coordinate system. We already see Go programs (SmartGo, GoGui and others) supporting this format. Maybe this can be a key point in the proposed FF[5] specification. Phil___ 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 Tue, 2007-10-23 at 01:16 -0700, Phil G wrote: As a community, I believe we can improve SGF by extending the specification slightly to allow points to also be encoded in standard coordinates and depreciated, admittedly slowly, the use of the old coordinate system. We already see Go programs (SmartGo, GoGui and others) supporting this format. Maybe this can be a key point in the proposed FF[5] specification. As a community, I don't think we should support *breaking* an existing, well-established data format over something as trivial as the coordinate system used. There are much bigger issues with sgf, such as not being able to follow a teaching review that jumps around nodes. What I would support is a new standard that was backwards compatible with existing tools. -Jeff ___ 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
Heikki Levanto wrote: On Mon, Oct 22, 2007 at 10:03:56PM -0700, Phil G wrote: To my surprise, GoGui can already read SGF with standard coordinates! :) I think you are muddying the waters by calling non-standard extensions 'standard' coordinates. I don't see any reason why [C4] should be harder to read than [cd]. Not for humans, and not for computers. I have a few books on GO and there are many articles on the web and they all seem to use one standard. Are you saying that the standard is really 'cd' and not 'C4' ? If we are to stick to one standard what are you saying it should be? I see many good reasons for sticking to *one* standard, and everyone using the same. At least for exchange of data - what you use internally in your programs is of course your own business. Even if a new proposed standard would have many benefits, obvious to everyone (which I have not yet seen), I would stuill urge people to consider those benefits carefully, and to weigh them against the problems that arise from having two incompatible standards. Just my personal opinion, of course. - Heikki ___ 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 lot to be said about standards, but common sense should prevail. Very few things have remained the same in computers, such as the program language you use.I've programmed for years and C is not the same as it was when I started and will not compile on the original compilers. Is that a bad thing? Heck no! I much prefer the advancements over slavish devotion to remain compatible at all costs. On the other hand I don't think standards should be broken at the drop of a hat. Microsoft breaks standards on purpose as a matter of course just to remain incompatible and to distinguish themselves and discourage people from moving to superior operating system. 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. I think this is a good move. Make your software read both formats seamlessly, and make it write either format optionally. Provide conversion utilities that convert in both directions. It's a relatively painless improvement to SGF. - Don Jeff Nowakowski wrote: On Tue, 2007-10-23 at 01:16 -0700, Phil G wrote: As a community, I believe we can improve SGF by extending the specification slightly to allow points to also be encoded in standard coordinates and depreciated, admittedly slowly, the use of the old coordinate system. We already see Go programs (SmartGo, GoGui and others) supporting this format. Maybe this can be a key point in the proposed FF[5] specification. As a community, I don't think we should support *breaking* an existing, well-established data format over something as trivial as the coordinate system used. There are much bigger issues with sgf, such as not being able to follow a teaching review that jumps around nodes. What I would support is a new standard that was backwards compatible with existing tools. -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] 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/
Re: [computer-go] XML alternatives to SGF
to be fair, most KR code will compile on modern compilers, if you ask nicely. s. - Original Message From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Tuesday, October 23, 2007 8:42:15 AM Subject: Re: [computer-go] XML alternatives to SGF There is a lot to be said about standards, but common sense should prevail. Very few things have remained the same in computers, such as the program language you use.I've programmed for years and C is not the same as it was when I started and will not compile on the original compilers. Is that a bad thing? Heck no! I much prefer the advancements over slavish devotion to remain compatible at all costs. On the other hand I don't think standards should be broken at the drop of a hat. Microsoft breaks standards on purpose as a matter of course just to remain incompatible and to distinguish themselves and discourage people from moving to superior operating system. 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. I think this is a good move. Make your software read both formats seamlessly, and make it write either format optionally. Provide conversion utilities that convert in both directions. It's a relatively painless improvement to SGF. - Don Jeff Nowakowski wrote: On Tue, 2007-10-23 at 01:16 -0700, Phil G wrote: As a community, I believe we can improve SGF by extending the specification slightly to allow points to also be encoded in standard coordinates and depreciated, admittedly slowly, the use of the old coordinate system. We already see Go programs (SmartGo, GoGui and others) supporting this format. Maybe this can be a key point in the proposed FF[5] specification. As a community, I don't think we should support *breaking* an existing, well-established data format over something as trivial as the coordinate system used. There are much bigger issues with sgf, such as not being able to follow a teaching review that jumps around nodes. What I would support is a new standard that was backwards compatible with existing tools. -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/ __ 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
There was some chatter a while back concerning it. I offered to admin it, and possibly to host it. Though there was another taker so not sure what it's current status is. -Josh On 10/22/07, Christoph Birk [EMAIL PROTECTED] wrote: What happened to the 19x19 CGOS revival? 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
But that's backward compatibility.We don't write code that compiles on old compliers even though we can compile older code on new compilers. Which is exactly what is being suggested by me. We can improve SGF without losing the ability to read older SGF files with no sweat. - Don steve uurtamo wrote: to be fair, most KR code will compile on modern compilers, if you ask nicely. s. - Original Message From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Tuesday, October 23, 2007 8:42:15 AM Subject: Re: [computer-go] XML alternatives to SGF There is a lot to be said about standards, but common sense should prevail. Very few things have remained the same in computers, such as the program language you use.I've programmed for years and C is not the same as it was when I started and will not compile on the original compilers. Is that a bad thing? Heck no! I much prefer the advancements over slavish devotion to remain compatible at all costs. On the other hand I don't think standards should be broken at the drop of a hat. Microsoft breaks standards on purpose as a matter of course just to remain incompatible and to distinguish themselves and discourage people from moving to superior operating system. 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. I think this is a good move. Make your software read both formats seamlessly, and make it write either format optionally. Provide conversion utilities that convert in both directions. It's a relatively painless improvement to SGF. - Don Jeff Nowakowski wrote: On Tue, 2007-10-23 at 01:16 -0700, Phil G wrote: As a community, I believe we can improve SGF by extending the specification slightly to allow points to also be encoded in standard coordinates and depreciated, admittedly slowly, the use of the old coordinate system. We already see Go programs (SmartGo, GoGui and others) supporting this format. Maybe this can be a key point in the proposed FF[5] specification. As a community, I don't think we should support *breaking* an existing, well-established data format over something as trivial as the coordinate system used. There are much bigger issues with sgf, such as not being able to follow a teaching review that jumps around nodes. What I would support is a new standard that was backwards compatible with existing tools. -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/ __ 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/ ___ 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 find it interesting the position I am taking on this.I'm a bit of believer in not making your parser too forgiving, or gratuitously breaking standards because it encourages sloppiness. In the days when PGN files for chess were just starting to become popular, it was horrible what you would find in the PGN files. Castling could appear as o-o, O-O, 0-0 and e1g1 among other things.Instead of Nbd2 you might have the incorrect disambiguation of N1d2 - which describes the move un-ambiguously, but is non-standard (unless there is also a knight on b3 in which case N1d2 is correct.) So many people made their parsers forgiving because many of the problems were easily corrected and it was easy to tell what move was intended.The idea was to make you parser strict on export, forgiving on import. The problem with being forgiving on input is that it doesn't encourage others to strictly adhere to the standards. Suddenly new defacto standards are acceptable which can complicate things. Once everyone else forgives, you must forgive or suddenly your software becomes non-standard in a defacto way. I think the right way to deal with this is to always be strict but provide cleaner tools. If a tool can correct a non-standard format, make it clear that it is broken and needs correction.Then the file can be passed on in a properly working state. However, I differently with this issue of allowing standard notation with SGF. I advocate defining it as acceptable. One of the primary reasons for having non-binary formats such as SGF and XML is to make it human readable.It's supposed to be made easy to edit these files manually without absolutely requiring special tools, not to mention the ease of debugging. I would rather look at a text file than a hex dump and is why we use text formats instead of binary formats. Despite posts to the contrary, ae is harder for humans to read than E5 for two reasons: 1. We are used to E5 notation. This IS the standard used by everything except SGF. Esperanto may be just as easy to learn as English but nobody speaks it (or only about 1 million out of 6.5 billion do.) 2. I would argue that having a letter and a number is more clear than having 2 letters or 2 numbers. This is an aid to distinguishing file and rank, or row and column. If I say the A edge, it means something with e5 notation but it could mean 2 different things with aa notation.Number is always row, Letter is always column. No big deal, but nice. - Don Jeff Nowakowski wrote: 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] XML alternatives to SGF
On Oct 23, 2007, at 9:01 AM, Stuart A. Yeates wrote: Much of the discussion in this thread has focused very narrowly on using an XML format to replace SGF, I believe that if an XML format is to take off, it should offer capabilities beyond what are possible in SGF, conversion to XML for XMLs sake is pointless. Possibilities include: * A method for presenting translated comments, i.e. the same comments in different languages, so a program can display only the appropriate ones. cheers stuart I'm surprised no one has brought up an obvious benefit of XML: well defined character encoding. A prime weakness of SGF is its unspecified character encoding. I thought that SGF is not well accepted in Asia due to this limitation. Re: coordinate normalization. This seems really trivial to me, easily something that could be incorporated as an option into the existing SGF standard. The code change would be minor. (I also presume that any proposal would retain the quirk of skipping the letter i in the horizontal coordinates?) Ian ___ 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
What is used in Asia? Terry McIntyre [EMAIL PROTECTED] They mean to govern well; but they mean to govern. They promise to be kind masters; but they mean to be masters. -- Daniel Webster - Original Message From: Ian Osgood [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Tuesday, October 23, 2007 9:26:25 AM Subject: Re: [computer-go] XML alternatives to SGF On Oct 23, 2007, at 9:01 AM, Stuart A. Yeates wrote: Much of the discussion in this thread has focused very narrowly on using an XML format to replace SGF, I believe that if an XML format is to take off, it should offer capabilities beyond what are possible in SGF, conversion to XML for XMLs sake is pointless. Possibilities include: * A method for presenting translated comments, i.e. the same comments in different languages, so a program can display only the appropriate ones. cheers stuart I'm surprised no one has brought up an obvious benefit of XML: well defined character encoding. A prime weakness of SGF is its unspecified character encoding. I thought that SGF is not well accepted in Asia due to this limitation. Re: coordinate normalization. This seems really trivial to me, easily something that could be incorporated as an option into the existing SGF standard. The code change would be minor. (I also presume that any proposal would retain the quirk of skipping the letter i in the horizontal coordinates?) Ian ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ __ 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] XML alternatives to SGF
I'm surprised no one has brought up an obvious benefit of XML: well defined character encoding. A prime weakness of SGF is its unspecified character encoding. I thought that SGF is not well accepted in Asia due to this limitation. I'm also a firm believer in UTF-8 only. This is an example of insanity, having so many different encodings. But please let's not talk about that one here. Re: coordinate normalization. This seems really trivial to me, easily something that could be incorporated as an option into the existing SGF standard. The code change would be minor. (I also presume that any proposal would retain the quirk of skipping the letter i in the horizontal coordinates?) That's how I feel. It's trivial and highly benefical. Not everyone would benefit because most people never directly look at SGF. However it's supposed to be human readable friendly and this is a no-brainer. - Don Ian ___ 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'm surprised no one has brought up an obvious benefit of XML: well defined character encoding. A prime weakness of SGF is its unspecified character encoding. I thought that SGF is not well accepted in Asia due to this limitation. I'm also a firm believer in UTF-8 only. This is an example of insanity, having so many different encodings. But please let's not talk about that one here. Re: coordinate normalization. This seems really trivial to me, easily something that could be incorporated as an option into the existing SGF standard. The code change would be minor. (I also presume that any proposal would retain the quirk of skipping the letter i in the horizontal coordinates?) That's how I feel. It's trivial and highly benefical. Not everyone would benefit because most people never directly look at SGF. However it's supposed to be human readable friendly and this is a no-brainer. - Don Ian ___ 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
On Mon October 22 2007 18:24, Don Dailey wrote: On Mon October 22 2007 10:15, Don Dailey wrote: it also seems to be hard to write an SGF file without bugs. 20% of the games or 20% of the sources? 20% of the games could have come from a single source. from different sources. You can check it yourself. Most of the files came from freely available sources linked from here: http://www.u-go.net/links/gamerecords/ I modified GoGui to output non-critical warnings for this experiment. Usually it warns only about problems that could cause information loss. For example KM[] or KM[ 6.5 ] (with spaces) are both invalid according to the standard, even if a forgiving SGF reader will accept them. So are you arguing that you should have no control over properties? Is this a strength of XML that you cannot define properties in a flexible way? yes. Allowing everyone to add non-standard properties means that you cannot validate the files in a meaningful way anymore. Also, I haven't really seen convincing use cases for non-standard properties. SGF defines (more than) enough, even if some of them are a bit underspecified (like OT allowing arbitrary text, which makes this part of the time settings practically unparsable for programs). That's the problem. The constant pressure to add more and more libraries to do simple things in more complicated ways. I don't want to link in yet another library to my code. its not about adding more and more. Its about selecting a few best-practice norms and conventions. XML is a standard that is used by a large number of projects and it handles problems on an intermediate layer that every complicated file format will run into. IMO, reinventing the wheel in this case is inferior coding practice. But I am not pushing for a new standard here. It was Jason who wrote the initial mail about the topic. Remembering earlier discussions on the list, it is not surprising to see the usual amount of XML hate mails. I simply wanted to support an XML-based file format in GoGui and I selected Jago's XML format, because it already seems to be supported by some existig programs: Jago, qGo, glGo (read support only?), GoSVG. The next major version of GoGui will also include a converter program that allows conversion from SGF to XML and backwards. - Markus ___ 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/
[computer-go] Ruby GTP shell
Does anyone know of a simple GTP engine written in Ruby that I would be able to use as a starting point? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Ruby GTP shell
I have a simple GO class in ruby that you can have if you are interested and if I can find it. It's doesn't do GTP but it creates a game object and validates moves and calculates scores. Send me private email if you are interested and I will look around for it. - Don Chris Fant wrote: Does anyone know of a simple GTP engine written in Ruby that I would be able to use as a starting point? ___ 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 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/
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/
Re: [computer-go] XML alternatives to SGF
On Tue, 23 Oct 2007, Markus Enzenberger wrote: its not about adding more and more. Its about selecting a few best-practice norms and conventions. XML is a standard that is used by a large number of projects and it handles problems on an intermediate layer that every complicated file format will run into. IMO, reinventing the wheel in this case is inferior coding practice. It is not re-inventing the wheel! SGF exists and is well supported for many years. Christoph ___ 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
Jason House 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. For use in GNU Go it would need to have quite compelling benefits to become interesting. Let's look at numbers. GNU Go 3.7.10 roughly consists of 2.4 MB C code (83000 lines), 1.4 MB pattern data, 0.45 MB testcase files, 1.8 MB sgf game records (1500 sgf files), and 2 MB documentation. Of the C code 2600 lines come from the sgf library. If we want to use an available C library for XML, expat seems like a possible choice. The whole distribution is 2.5 MB but maybe it's possible to get away with the 400 kB (13000 lines) C code in the lib directory. Five times bigger than our sgf library but manageable. (That cannot be said of libxml2 though, with some 14 lines of code.) 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? 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. 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. 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. /Gunnar ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 19x19 CGOS
Less than 20 minutes per side would be practically blitz speed. - Original Message From: Chris Fant [EMAIL PROTECTED] 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/ __ 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
Christoph Birk 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 I'll connect Crazy Stone after the tournament in Hakone (mid november). 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
Chris, I think Olivier is using fast games only because he is testing the server. I want to see if Mogo can beat Many Faces at a level that at least resembles what they play the top 19x19 computer Go tournaments. But Olivier will be running the server, so it's his choice. - Don Chris Fant wrote: 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/
Re: [computer-go] XML alternatives to SGF
yes. Allowing everyone to add non-standard properties means that you cannot validate the files in a meaningful way anymore. Also, I haven't really seen convincing use cases for non-standard properties. SGF defines (more than) enough, even if some of them are a bit underspecified ... I've been using the C[] tag whenever I've wanted to extend SGF with a non-standard property. It has the great advantage that just about every SGF viewer allows viewing and editing of comments; the same cannot be said for support of some of the more exotic commands. Re: XML vs. SGF, neither is particularly easy to parse, but sgf has the market share, so I think ultimately the argument is pointless. Re: changing SGF coord syntax: does anyone seriously read or edit sgf by hand? Get yourself an sgf viewer. The only people who ever have to deal with B[dc] are the programmers on this list, and I'm sure we're all capable of writing board_height-y. And, as I'm here spouting opinions, I think the bicycle shed should be painted chrome, so it looks all futuristic. Darren ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Hakone 2007
The Workshop itself is usual but we have a local computer-go tournament as a night event this year (and possibly following years). -Hideki Darren Cook: [EMAIL PROTECTED]: Rémi wrote: I'll connect Crazy Stone after the tournament in Hakone (mid november). Is it a tournament or the usual annual Game Programming Workshop? Do you have any more information? I've found a page saying the tentative date is Nov 9th to Nov 11th, but haven't yet tracked down exact information, who is speaking, etc. even in Japanese. Darren -- [EMAIL PROTECTED] (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
