Re: [computer-go] re: Fuego
Jason House wrote: What enhancements does fuego have over plain vanilla UCT? Also, what hardware are you using? The name seems to imply it's running with 8 cores. the enhancements are probably similar to what the other programs use: MoGo-like patterns and other heuristics in the playout policy, mercy rule, RAVE, prior knowledge initialization, multi-threading, pondering. The enhancements are configurable and the heuristics pluggable, so you can also run it in plain-vanilla UCT mode for comparison, or test your own playout policy. The version on CGOS with the name ending with 8c runs on a dual quadcore Intel Xeon 2.5 GHz, 8GB RAM. On 9x9, it doesn't scale so well, so it would probably be not much weaker with 4 cores. On 19x19, the 8 cores might make more difference. I haven't tried it recently. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Some recent papers
Rémi Coulom wrote: I could not find the link for suggesting updates to the computer go bibliography, so if the people from the University of Alberta read this, they might like to add those papers to their bibliography. I probably won't continue maintaining the bibliography (from the beginning of next year on at the latest, when I leave UofA). If someone is interested in maintaining an updated version and knows a stable place on the web for it, I would be happy to send him the files. The bibliography is simple a BibTeX file, which is converted to HTML using bibtex2html and a manually updated HTML page with the recent additions. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Some recent papers
Rémi Coulom wrote: This seems to be a good solution. I have just applied to your computer-go group. We just have to try to import the bibtex file. Markus, can you do it ? Or tell us where to download the bibtex file ? I added a link to the bib-file on the website: http://www.cs.ualberta.ca/~games/go/compgo_biblio/ Most of the entries also contain the abstract. A while ago, I found a BibTeX to HTML converter written in Java that could produce separate pages for the entries including the abstract. I thought, it would be nice to combine that with a Google site search box that would allow you to search the abstracts. Unfortunately, the converter was not stable at that time, but I haven't tried a recent version. I forgot the name of the converter, but it should be easy to google for it. Anyway, once you decide on a new place, tell me the URL so that I can add a link from the UofA page, there are a number of inbound links to that page. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] What Do You Need Most?
David Fotland wrote: I prefer keeping 9x9. We have 9x9 for quick testing of changes (because the games are fast), and 19x19 for testing play on a full board. I don't think 13x13 adds anything. It's slower, so I would still use 9x9 for quick tests. It's not a board size that anyone uses, so I would still use 19x19 to test for full boards. I agree. 9x9 and 19x19 are the most popular board sizes and the only ones used in Computer Go tournaments. I think the participation on the 19x19 CGOS would be higher if it wasn't down so often. Sometimes the server does not work for days, sometimes it is only the result pages on the web, which are not updated. I think it would be very helpful to have an 19x19 server with a higher uptime. Unfortunately I cannot offer to run one myself. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] cgos 19x19 has no anchor
Don Dailey wrote: If someone else could please run an anchor until we get this ironed out, it would be appreciated. Contact me by private email if you can run a reliable anchor player for a while. I could run a GNU Go anchor on 19x19 on one of our machines for two weeks. Maybe even a few weeks more, but it won't be a long-term solution - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Another 6x6 analysis.
Gunnar Farnebäck wrote: To do that, just point your regular cgos client to trac.gnugo.org, port 6867. what rules does GNU Go use in the 6x6 analysis? I connected Fuego configured with CGOS rules. After a while it terminated, because Fuego returned an error response to a play command with a move that violated the positional superko rule. (By default, Fuego does not accept illegal moves to avoid that configuration errors in experiments go by unnoticed.) - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Another 6x6 analysis.
Gunnar Farnebäck wrote: Markus Enzenberger wrote: > I connected Fuego configured with CGOS rules. After a while it > terminated, because Fuego returned an error response to a play command > with a move that violated the positional superko rule. (By default, > Fuego does not accept illegal moves to avoid that configuration errors > in experiments go by unnoticed.) Did you notice whether there was something interesting about that position? no, I did not save or log the games. But it would be best for your analysis server, if the connected programs knew about the rules used. It helps them to generate higher quality moves. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MC and Japanese rules
Rémi Coulom wrote: Yes. The recipe is: - play as usual with Chinese rules, - take a one-point security margin with respect to komi, - pass as soon as the opponent passes. You also have to be careful to score seki the Japanese way in the playouts. This is the most difficult part. If your playouts don't understand seki, then you can just ignore seki, or take more than one point of security margin if you wish to be safe. I don't think that works even if there is no seki, because what happens if your opponent passes in a position in which there are still unsettled groups? If you blindly pass after the opponent's pass and thereby terminate the game, who will own the unsettled group under Japanese rules? Here is what Fuego does: Fuego uses Tromp-Taylor rules internally, which makes scoring of terminal positions after two passes trivial. If the value of the root node is very close to a win after half of the search resources are used (time or node limit), the search aborts early. Then a second search is started that checks if the position is still a win after the player to move plays a pass. If this is so, and the point ownership statistics show that the status of all points is decided (close to 0% or 100%) then the player passes, even if the best move of the first search was not a pass. The original idea for this was to pass as soon as a position is won and the status of all points is decided, because continuation of play in this situation offends some humans. But as a side effect, it also avoids to lose points if the game is played by Japanese rules. We haven't done anything for dealing with the different scoring of seki in Japanese rules yet. In reality, the algorithm is a bit more complicated, because there could also be neutral points and Fuego tries to detect them and play moves to fill them. In fact, under some circumstances there are three searches necessary. You can find all details in GoUctPlayer::DoEarlyPassSearch() in Fuego's source code. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fuego performance
Petr Baudis wrote: Just FYI, someone might find interesting that latest SVN of Fuego still does not seem to be on par with Mogo public release 1 (not that it would claim to be - I was just curious where do they stand against each other). Fuego is weaker than MoGo on 19x19. With 15 min games, I am measuring a winning rate of 20% (+-2.5%), which matches your result within your given error. I am using MoGo release 3 with --totalTime and --dontDisplay options. On 9x9, Fuego is stronger than MoGo. With 5 min games, a single core version of Fuego, no book, and about 1GB max tree size, I am measuring a winning rate of 52% (+-1.5%). With opening book, the percentage would be higher (on 9x9). We only started to test and improve Fuego on the large board in summer 2008. Since then, Fuego has improved nearly linearly on the 19x19 CGOS from 1900 to 2100 ELO with 2 cores and is at about 2300 ELO with 8 cores. These numbers are from the same Bayes-ELO run. So Fuego is still about 200-250 ELO below the strongest programs on 19x19. However, it is by far the strongest open source program existing on both 19x19 and 9x9, and one of the strongest programs overall on 9x9. We already have a version of Fuego internally in our group that is about 60-70 ELO stronger on 19x19, but those changes are still under development and it could take a while until they will be committed. Unfortunately, I am leaving the team in a few weeks, and it is unclear how much I can contribute after that. Martin is usually too busy for doing maintainer work and at the moment there is only funding for a few months for a new programmer in our group (Broderick Arneson, who also did a lot of work for MoHex, one of the strongest Hex programs, which is also based on the MCTS search of Fuego's SmartGame library). Martin and I had hoped that making Fuego available under an open source license would attract some outside contributors and potentially even people with excellent C++ skills and experience in Computer Go to become part of the maintainer team, but so far it hasn't happened. This is sad, but I can't help it. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fuego performance
Jason House wrote: I went back to take another look and here are some of the things I'm noticing immediately: * There's both a go and gouct directory. They share many of the same file names (after removing the path-dependent name mangling such as GoBoard.cpp and GoUctBoard.cpp). One would guess that the gouct directory would take precedent. * GoUctPlayoutPolicy.h includes GoUctGlobalSearch.h which includes GoBoard.h??? This obviously conflicts with the first conclusion. Maybe GoUctBoard is just dead code and GoBoard is the file to use? * GoUctGlobalSearch.h also include GoUctSearch.h which includes both GoBoard.h and GoUctBoard.h. Again, another conclusion gone bad. * GoBoard.h includes SgBoardConst.h, which hides in smartgame. There's tons of other references to Sg stuff throughout the code. What is smartgame anyway? I agree that the documentation could be better. The code has been restructured many times within the last years and sometimes it is better not to spend too much time too early on full documentation or tutorials, because it could lead to an accumulation of outdated and therefore misleading documentation. However, the questions you list here can be answered by looking at the existing documentation. The SmartGame, Go, and GoUct library have a hierarchical dependency, see http://www.cs.ualberta.ca/~games/go/fuego/fuego-doc/general/generalmodules.html The main page of these libraries in the doxygen documentation has at least a short description what they are for. Reading the class descriptions would have given you the information that GoBoard is a general implementation of a Go board, whereas GoUctBoard is a version optimized for MC-playouts, which does not support undo or super-ko. GoUctSearch uses both of them. GoUctSearch does not "take precendent" over SgUctSearch, but derives from it. It is indeed a bit unfortunate that we use the prefix GoUct for the GoUct library, because it is ambiguous whether GoUctSearch resides in the Go or GoUct library, but the class listings of the libraries should have answered that question. I actually did spend several weeks on writing a technical report, which gives a high level introduction to Fuego version 0.3 and its current performance. There are still a few paragraphs that Martin has to write, so it could take a few more weeks until it is done. Hopefully it will be made public on Fuego's website by end of March, but that depends on Martin. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fuego performance
terry mcintyre wrote: Does Fuego make use of multiple cores? Does it require some switch setting to do so? The number of threads is controlled by the GTP command "uct_param_search number_threads". On Intel and AMD CPUs, you should also set ""uct_param_search lock_free 1", see http://www.cs.ualberta.ca/~games/go/fuego/fuego-doc/smartgame-doc/sguctsearchlockfree.html The maximum tree size is set with "uct_param_search max_nodes" (the default is very conservative, on 64-bit machines, I would use maybe 600 per GB main memory). You can change these parameters temporarily using the Analyze Command window in GoGui, or write the commands to a config file and add the -config option with the filename to the command line for Fuego. How do I control the time used by Fuego? If the controller sends a time_settings command, Fuego will use this time for the game. If no time settings are given, Fuego will use a fixed time per move, which can be changed with "go_param timelimit". To use a fixed number of simulations, use "uct_param_player ignore_clock 1" and "uct_param_player max_games". - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Generalizing RAVE
Brian Sheppard wrote: Fuego uses a lower weight for distant moves than for nearby moves. I suspect that isn't much better than using uniform weight. I am hope that Martin or Markus will comment. I measured a winning rate of 55.1(+-0.8)% of Fuego with weighted RAVE updates vs. the version with uniform updates. The experiment was done on 9x9 with 10K simulations. There was also a net-positive effect on the number of passes in the regression tests at the time. I did run a few tests against other opponents (GNU Go and MoGo) with longer time settings and on 19x19, but I didn't play enough games for a statistically significant result (it didn't seem to perform worse). It would still be easy to investigate that deeper, if someone has the time and resources to run more experiments. The weighting of the RAVE updates is an optional feature in Fuego's UCT search and can be disabled with the GTP command "uct_param_search weight_rave_updates 0". To be beneficial, it was crucial to make the weight a function of the relative move distance (w.r.t. the length of the simulation), not the absolute move distance. The exact formula is implemented in SgUctSearch::UpdateRaveValues(). It is scaled such that the average weight is still 1. Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] language choices
On Tue December 5 2006 13:31, Don Dailey wrote: > On CGOS, gnugu_3.7.4 is rated 1720. MoGo is is in the 2100-2200, > presumably it's save to assume it is significantly stronger. > > But if we can assign an ELO rating to Gnugo 3.7.4, then we can add 300 > or 400 to get Mogo's current ELO rating. I once did an experiment running NeuroGo as a 9x9 bot on KGS. It used the pseudonym Computer9. KGS does no automatic rating for 9x9, but plotting the distribution of wins versus the rank of the opponent crossed the 50% line between 7 and 8 kyu. The distribution also included wins against opponents rated at Dan-level, see the KGS archives. Since humans could (and did) retract moves, I assume that this is a lower limit of NeuroGo's rating. So if MoGo is 300 ELO stronger than NeuroGo on CGOS, and assuming it would perform stronger against humans by the same amount, that would make it 3 to 4 kyu, which is very impressive. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Anchor Player
On Friday 22 December 2006 13:24, Christian Nilsson wrote: > How is this compensation handled by the various programs on cgos, if at > all? > > Check http://www.britgo.org/rules/compare.html#comp if you don't know > what I'm talking about.. is there any logical explanation for this rule? I mean, White gives Black an advantage in the form of handicap stones, why should Black give White a compensation for a small part of this advantage in return? Since CGOS already uses Tromp-Taylor, which are IMO the most logical and cruft-free rules existing, I would vote for not using the compensation. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
would it make sense to treat players with handicap as completely different players? For example, GNU Go giving one handicap stone would be a different player and get a rating independent of GNU Go in an even game? Then there is no problem about how to shoehorn handicap into the ELO system. It would also be more visible how much different programs can take advantage of getting a handicap stone. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board
On Monday 19 February 2007, Chris Fant wrote: > Here is a completed game of Go between two random players... on a very > large board. > > For ascetics, the eyes have been filled after both players passed. > > http://fantius.com/RandomGo1600x1200.png this is very interesting. Can you compute some properties, like the distribution of cluster sizes, or diagrams for cluster size / boundary size pairs? I don't know much about fractals, but does this picture have some fractal properties, too? - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GtpStatiscics
On Wednesday 21 February 2007, Chris Fant wrote: > It seems that GtpStatistics (java tool that comes in the GoGui > package) is not sending a quit command to my gtp player. This results > in me having to manually kill the gtp player process after each run. please report GoGui bugs to the GoGui bug tracker, not to the computer-go mailing list. GtpStatistics should send a quit, but doesn't. However, it is also a good idea, if a Go engine just quits, if it gets an end-of-stream condition on its input stream. Do you not receive an end-of-stream with your C# engine? - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
On Thu March 1 2007 05:22, Łukasz Lew wrote: > The most important thing is controller - engine architecture. > There are situations that engine would like to have the control. For these requests come up once in a while, but IMO the clear separation between who is the controller and the engine is a big advantage of GTP. It makes both the implementation of engines and controllers much easier. Can you do simple, single-threaded controller scripts with UCI? Is it used for as many use cases as GTP is, ranging from regression testing to any kind of automated experiments with Go engines? The Go server protocols are designed for humans and asynchronous sending of messages between them at any time, but does it make sense for a computer engine to allow it to start chatting, whenever it feels like it? I think that GTP should not be extended in a way that makes the implementation of engines or controllers more complicated. > In gogui this is solved by using stderr to send those commands, but: > - stderr is not network transparent Remi Coulom convinced me that it is more convenient for the engine to write to standard error and he was right. Typically the GTP interface is only one of several interfaces to lower level Go engine code and you don't want to make lower level code aware of this. One idea I had in mind to address this was to allow the engine to send comment lines before the actual response. Then you could tunnel the standard error output through a network connection in these comment lines, maybe starting with a special keyword. It would need only a minor modification to existing controllers to ignore all text before the response. Alternatively, one could extend the tools GtpServer and NetGtp in the GoGui package to internally transmit standard error text in such a way, that would be transparent for the engine and controller on different hosts. > 6. Position setup. I had conversation with Marcus about setup in GoGui. > And we concluded that there should be a separate command for that. The coming version 1.0 of GoGui will support a setup command. It is a simplified version of a suggestion I made a while ago to the GTP list and uses a syntax like: gogui-setup b A1 b B2 w C3 Originally I had an undoable setup command in mind to incrementally follow setup stones in SGF trees, but it is much easier for engine programmers to handle only full position setup on empty boards, so GoGui will follow the SGF properties incrementally and translate setup nodes into clear_board / gogui-setup sequences. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
On Thursday 01 March 2007, Phil G wrote: > I would like to suggest using the command "setup_sequence" instead to miror > the "play_sequence" command which was introduced by GoGui (I believe). I finally followed the GTP (draft) standard and used a prefix separated by a hyphen for non-standard extension commands, so "play_sequence" became "gogui-play_sequence". "setup_sequence" wouldn't be a good name, because the setup stones are not a sequence, you can specify them in any order. There will also be a second command "gogui-setup_player" for setting the color to play, but support for that is optional, since it is not strictly necessary that the engine is informed about the color to play. The genmove and play commands are sent with a color argument anyway. If an engine does not support gogui-setup, setup stones will be sent as moves as previously. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
On Saturday 03 March 2007, Stuart A. Yeates wrote: > In an ideal world I'd love to see go move to RFC 3920, but that would > be quite a disruptive shift. this RFC describes an asynchronous message passing system; GTP is more like a simple remote procedure call at Go engines. These are different things and therefore you cannot really compare GTP to UCI or call UCI more advanced. I cringe, when I think about how to write tools that need to access functionality of Go engines, but have to deal with unexpected messages or state changes at any time. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
I am still frightened by your plans, how to permit asynchronous commands in GTP. Here are some remarks and questions: genmove is only one of many commands that the user might want to abort. We use GTP extension commands for starting life and death searches or other lengthy computations and many of them can be aborted at any time. Do you really want a sync and async version and a different abort command for each of them? Potentially every GTP command can be a candidate for aborting. If a controller provides support for engine-specific extension commands without specifically knowing what they do (like GoGui's Analyze Commands), there should still be a way to let the user send an abort request and let those commands abort that are able to. Why is it necessary that the async genmove returns an immediate response? - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Binary release of MoGo
when I run the Linux exeutable on my Fedora 8/Athlon XP, I get a coredump: $ mogo --9 --time 12 Load opening database opening succeed (nbEntries=618) (nbIllegalMoves removed 0) tried to open opening, success 1 Illegal instruction (core dumped) could it be that it is compiled for specific CPU architecture? - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Binary release of MoGo
> when I run the Linux exeutable on my Fedora 8/Athlon XP, I get a I mean Fedora 7... - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Binary release of MoGo
On Monday 10 September 2007, Sylvain Gelly wrote: > > could it be that it is compiled for specific CPU architecture? > > Of course it is :). > Ok, good (well, rather sad :)), to know that it does not work on > Athlon XP. I should rebuild with an older architecture then (but it > will be slower :-( ). I don't know about Ubuntu, but the default GCC configuration on Fedora does not set CPU-specific compiler options, so an executable should run on the whole family of i386 processors. If you add some Intel-Core 2 specific options yourself, I would be interested, what they are, and in what speedup they really result. For Athlons, I never found a significant difference between enabling AMD architecture or just using the default configuration. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Solved! Re: [computer-go] Re: Binary release of MoGo
On Monday 10 September 2007, Sylvain Gelly wrote: > Ah, now that makes sense, the additional number you posted on your > email was actually sent to MoGo, and I understand now why it did not > work. auto-numbering in GoGui prepends all commands with an integer ID, which is sent to the program and should be used by the program in its response, see the GTP specification. and yes, GoGui 1.0 allows you to specify a working directory to run the program in. - 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
On Mon October 22 2007 10:15, Don Dailey wrote: > almost impossible to write XML manually without bugs. it also seems to be hard to write an SGF file without bugs. I recently run a test on a collection of about 5000 SGF files from various sources on the web and more than 20% of them generated a warning when reading with GoGui. The most frequent problems are duplicate properties or root-properties in non-root nodes. Another problem I have with SGF is that it allows user-defined properties. While this is very appealing at first, because it allows to preserve unknown properties, it creates problems in practice. One is the potential of conflicting property keys, because there are no namespaces. Also, if a program does not know, what a property means, it cannot do much apart from preserving it when saving the file. But of other properties of a node were changed, the unknown property could have lost its context in which it is meaningful. I agree that reading an XML file without using a library is complicated, but there are enough libraries existing and even part of the standard libraries of some languages. The big advantage of an XML-based file format is that it leverages the power of meta-tools. Like it is a big advantage to use line-oriented text-based file formats on Unix, because you can do a lot of tasks simply using standard tools, like grepping, transforming, diffing and merging. But line-oriented text-based file formats reach their limits when you have data with a more complex structure, like trees. Think of resolving a conflict in a Go game file in your version control system. If the file format was XML-based, a meta-tool could merge changes like version control systems do right now with text-based files. Do you want to write a different conflict-resolvers for every file format? Or hava a look at this XSL style sheet: http://homepage.ntlworld.com/daniel.gilder/gosvg.html It creates a nice looking SVG vector graphic from a Jago XML file and the whole transformation is done by a standard tool with the transformation again described in an XML data file. - 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
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] analysis of UCT and BAST
Remi Munos wrote: I have updated the BAST paper, providing additional comparison with UCT, as suggested by one person in the list. See: https://hal.inria.fr/inria-00150207 after reading the paper, I have two questions: How did you deal with unexplored nodes in Flat UCB and BAST in your experiment? If you assign infinity to their bounds that means that the maximum is also infinity and all of the 2^D leaf nodes in the tree will be explored at least once. This doesn't matter with Flat UCB, because the regret is O(2^D) anyway, but it should matter with BAST, right? Have you considered a different definition of your smoothness assumption? I think the bound on the difference between a sub-optimal leaf reward and the optimal reward is not a good model for Go trees. It might be better to model smoothness by assuming a high probability that two leaf rewards in a branch are close to each other, but there might still be a few outliers (losing moves in a won position). - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
