Re: [computer-go] Generalizing RAVE

2009-09-26 Thread Markus Enzenberger
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

Re: [computer-go] MC and Japanese rules

2009-02-04 Thread Markus Enzenberger
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

Re: [computer-go] Another 6x6 analysis.

2008-10-02 Thread Markus Enzenberger
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

Re: [computer-go] What Do You Need Most?

2008-07-31 Thread Markus Enzenberger
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

Re: [computer-go] re: Fuego

2008-07-08 Thread Markus Enzenberger
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

Re: [computer-go] Some recent papers

2008-07-08 Thread Markus Enzenberger
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

Re: [computer-go] analysis of UCT and BAST

2007-11-21 Thread Markus Enzenberger
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

Re: [computer-go] XML alternatives to SGF

2007-10-23 Thread Markus Enzenberger
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

Re: [computer-go] XML alternatives to SGF

2007-10-22 Thread Markus Enzenberger
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

Re: [computer-go] Binary release of MoGo

2007-09-10 Thread Markus Enzenberger
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

Re: Solved! Re: [computer-go] Re: Binary release of MoGo

2007-09-10 Thread Markus Enzenberger
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

Re: [computer-go] Binary release of MoGo

2007-09-09 Thread Markus Enzenberger
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

Re: [computer-go] Binary release of MoGo

2007-09-09 Thread Markus Enzenberger
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] GTPv3

2007-03-08 Thread Markus Enzenberger
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

Re: [computer-go] GTPv3

2007-03-01 Thread Markus Enzenberger
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

Re: [computer-go] GTPv3

2007-03-01 Thread Markus Enzenberger
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

Re: [computer-go] GtpStatiscics

2007-02-21 Thread Markus Enzenberger
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