Re: [computer-go] java reference bot
On Fri, 2008-10-24 at 23:59 -0400, Michael Williams wrote: > I noticed that the Java reference bot does not listen to the color parameter > of genmove. It alternates colors regardless of what is specified. Yes, it's hacked together. I meant to come back to it later to clean up stuff like that. The GTP stuff is horrible anyway, I cut and pasted it from something on the web and then modified that. - Don > > Don Dailey wrote: > > On Mon, 2008-10-13 at 23:21 -0400, Joshua Shriver wrote: > >> Is the source available would be neat to see. > > > > Yes, get it here: http://cgos.boardspace.net/public/javabot.zip > > > > It includes a unix style simple Makefile. > > > > For you java programmers: I'm sure you won't like it - I'm not a java > > programmer but I did try to comment it fairly well and make it readable > > because it's supposed to be a reference bot. > > > > If anyone wants to clean it up, make it more readable, speed it up > > (without uglying it up) I would be interested and would incorporate that > > into the final reference bot.I don't know java specific do's and > > dont's and idioms for getting faster code. > > > > But of course first I want to find all the bugs. > > > > - Don > > > > > > > > > > > >> -Josh > >> > >> On Mon, Oct 13, 2008 at 7:14 PM, Don Dailey <[EMAIL PROTECTED]> wrote: > >> I made a reference bot and I want someone(s) to help me check > >> it out > >> with equivalent data from their own program. There are no > >> guarantees > >> that I have this correct of course. > >> > >> > >> > >> ___ > >> 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/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] C# Reference bot
It rarely plays anything other that E5, was E6 a fluke?The other numbers look correct to me. I haven't posted the Vala version yet, but I bet it would be even easier to port from it, since Vala is heavily based on C#. I thought it was pretty easy to port from Java to Vala except that I spent too much time digging around in the documentation because I don't know C# or Vala or barely Java. - Don On Sat, 2008-10-25 at 00:46 -0400, Michael Williams wrote: > Porting the Java version to C# was really easy. Here are the numbers for 0.5 > komi and 100 playouts: > > genmove b > = E6 > (took 136 seconds) > > ref-nodes > = 111061901 > > ref-score > = 0.523573 > ___ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] C# Reference bot
Porting the Java version to C# was really easy. Here are the numbers for 0.5 komi and 100 playouts: genmove b = E6 (took 136 seconds) ref-nodes = 111061901 ref-score = 0.523573 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] java reference bot
I noticed that the Java reference bot does not listen to the color parameter of genmove. It alternates colors regardless of what is specified. Don Dailey wrote: On Mon, 2008-10-13 at 23:21 -0400, Joshua Shriver wrote: Is the source available would be neat to see. Yes, get it here: http://cgos.boardspace.net/public/javabot.zip It includes a unix style simple Makefile. For you java programmers: I'm sure you won't like it - I'm not a java programmer but I did try to comment it fairly well and make it readable because it's supposed to be a reference bot. If anyone wants to clean it up, make it more readable, speed it up (without uglying it up) I would be interested and would incorporate that into the final reference bot.I don't know java specific do's and dont's and idioms for getting faster code. But of course first I want to find all the bugs. - Don -Josh On Mon, Oct 13, 2008 at 7:14 PM, Don Dailey <[EMAIL PROTECTED]> wrote: I made a reference bot and I want someone(s) to help me check it out with equivalent data from their own program. There are no guarantees that I have this correct of course. ___ 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] reference bots testing.
On Oct 24, 2008, at 11:09 PM, Don Dailey <[EMAIL PROTECTED]> wrote: Hi Jason, That's great! Thanks. Did you test for basic conformance based on the numbers I reported earlier for black score and average nodes per game? No. I probably should have... I will check it out later if I can get D installed and run the big self-test too. Can you send me a statically compiled linux binary? Absolutely... I did not want to email a half 500k attachment. - Don On Fri, 2008-10-24 at 23:01 -0400, Jason House wrote: On Sat, 2008-10-18 at 09:26 -0400, Don Dailey wrote: I have two versions of the reference bot. A C and a Java version. I've ported the Java position.d to D2 and added a basic wrapper around it. Here are performance numbers on my laptop javabot runs in 132 seconds for 1,000,000 simulations drefbot runs in 146 seconds for 1,000,000 simulations compilation command with dmd 2.014: dmd -gc -O -release drefbot.d gtp.d position.d phobosrandom.d tangoshuffle.d -ofdrefbot (windows user append .exe to end of line) Here's a basic description of the files: position.d - A D2 port of position.java gtp.d - GTP implementation using some generic programming (automatic parameter conversion, uses command registration) drefbot.d - Basic glue of position.d with gtp.d tangoshuffle.d - Used as replacement for Collections.shuffle phobosrandom.d - Patched version of std.random to fix a serious bug It's possible to eliminate tangoshuffle.d, but I was lazy with my initial port and didn't bother thinking about how to efficiently shuffle (and debug whatever I hacked together) ___ 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] reference bots testing.
Hi Jason, That's great! Thanks. Did you test for basic conformance based on the numbers I reported earlier for black score and average nodes per game? I will check it out later if I can get D installed and run the big self-test too. Can you send me a statically compiled linux binary? - Don On Fri, 2008-10-24 at 23:01 -0400, Jason House wrote: > On Sat, 2008-10-18 at 09:26 -0400, Don Dailey wrote: > > I have two versions of the reference bot. A C and a Java version. > > I've ported the Java position.d to D2 and added a basic wrapper around > it. Here are performance numbers on my laptop > javabot runs in 132 seconds for 1,000,000 simulations > drefbot runs in 146 seconds for 1,000,000 simulations > > compilation command with dmd 2.014: > dmd -gc -O -release drefbot.d gtp.d position.d phobosrandom.d > tangoshuffle.d -ofdrefbot > (windows user append .exe to end of line) > > Here's a basic description of the files: > position.d - A D2 port of position.java > gtp.d - GTP implementation using some generic programming > (automatic parameter conversion, uses command registration) > drefbot.d - Basic glue of position.d with gtp.d > tangoshuffle.d - Used as replacement for Collections.shuffle > phobosrandom.d - Patched version of std.random to fix a serious bug > > It's possible to eliminate tangoshuffle.d, but I was lazy with my > initial port and didn't bother thinking about how to efficiently shuffle > (and debug whatever I hacked together) > ___ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] reference bots testing.
On Sat, 2008-10-18 at 09:26 -0400, Don Dailey wrote:
> I have two versions of the reference bot. A C and a Java version.
I've ported the Java position.d to D2 and added a basic wrapper around
it. Here are performance numbers on my laptop
javabot runs in 132 seconds for 1,000,000 simulations
drefbot runs in 146 seconds for 1,000,000 simulations
compilation command with dmd 2.014:
dmd -gc -O -release drefbot.d gtp.d position.d phobosrandom.d
tangoshuffle.d -ofdrefbot
(windows user append .exe to end of line)
Here's a basic description of the files:
position.d - A D2 port of position.java
gtp.d - GTP implementation using some generic programming
(automatic parameter conversion, uses command registration)
drefbot.d - Basic glue of position.d with gtp.d
tangoshuffle.d - Used as replacement for Collections.shuffle
phobosrandom.d - Patched version of std.random to fix a serious bug
It's possible to eliminate tangoshuffle.d, but I was lazy with my
initial port and didn't bother thinking about how to efficiently shuffle
(and debug whatever I hacked together)
import gtp;
import position;
import std.conv;
int boardSize = 9;
int level = 1000;
Position gme;
void main(string[] args){
if (args.length > 1)
level = to!(int)(args[1]);
gme.init();
register("boardsize", (int n){boardSize = n; gme.setBoardSize(n);});
register("clear_board", (){gme.setBoardSize(boardSize);});
register("final_status_list", (string s){return ""[];});
register("genmove", (string color){
string smv = gme.genmove(level);
gme.make(smv);
debug gme.display;
return smv;
});
register("komi", (double n){gme.setKomi(n);});
register("name", (){return "DrefBot"[];});
register("play", (string color, string vertex){gme.make(vertex);});
register("ref-nodes", (){return gme.final_search_nodes;});
register("ref-playouts", (){return level;});
register("ref-score", (){return gme.final_search_score;});
register("version", (){return "0.1"[];});
run();
}module gtp;
import std.conv;
import std.stdio;
import std.string;
import std.c.stdlib;
alias string delegate(string[]) gtpCommandProcessor_t;
gtpCommandProcessor_t[string] gtpCommands;
void register(R, T...)(string commandName, R delegate(T) f){
string callback(string[] args){
T translatedArgs;
try{
assert(T.length == args.length, "Incorrect number of arguments");
foreach(i, type; T)
translatedArgs[i] = to!(type)(args[i]);
string r = "";
static if (is(R==void))
f(translatedArgs);
else
r = to!(string)(f(translatedArgs));
return "= " ~ r ~ "\n\n";
}
catch (Exception e){
return "? " ~ e.msg ~ "\n\n";
}
}
gtpCommands[commandName] = &callback;
}
R delegate(T) toDelegate(R, T...)(R function(T) f){ return delegate R(T t){return f(t);}; }
void register(R, T...)(string commandName, R function(T) f){
register(commandName, toDelegate(f));
}
string listCommands(){
string retval = "";
foreach(string key, gtpCommandProcessor_t value; gtpCommands){
if (retval.length == 0)
retval = key;
else
retval ~= "\n" ~ key;
}
return retval;
}
void run(){
register("known_command",
delegate bool (string cmd){return (cmd in gtpCommands) !is null; });
register("list_commands", &listCommands);
register("protocol_version", (){return 2;});
register("quit", (){exit(0);});
foreach(string line; lines(stdin)){
if (line.length==0 || line[0] == '#')
continue;
auto pieces = split(line);
if (pieces[0] in gtpCommands)
writef("%s",gtpCommands[pieces[0]](pieces[1..$]));
else
writef("? Unknown command %s\n\n", pieces[0]);
}
}// Written in the D programming language
/**
Facilities for random number generation. The old-style functions
$(D_PARAM rand_seed) and $(D_PARAM rand) will soon be deprecated as
they rely on global state and as such are subjected to various
thread-related issues.
The new-style generator objects hold their own state so they are
immune of threading issues. The generators feature a number of
well-known and well-documented methods of generating random
numbers. An overall fast and reliable means to generate random numbers
is the $(D_PARAM Mt19937) generator, which derives its name from
"$(WEB math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html, Mersenne
Twister) with a period of 2 to the power of 19937". In
memory-constrained situations, $(WEB
en.wikipedia.org/wiki/Linear_congruential_generator, linear
congruential) generators such as $(D MinstdRand0) and $(D MinstdRand)
might be useful. The standard library provides an alias $(D_PARAM
Random) for whichever generator it finds the most fit for the target
environment.
Example:
Random gen;
// Generate a uniformly-distributed integer in the range [0, 15]
auto i = uniform!(int)(gen, 0, 15);
// Generate a uniformly-distributed real in the range [0, 100$(RPAREN)
auto r = uniform!(real)(gen, 0.0L, 100.0L);
In addition to random number generators, this module features
distributions, which skew a generator's output statistical
distribution in various ways. So
Re: [computer-go] From zero to playing on CGOS in 10 minutes
On Fri, 2008-10-24 at 20:56 -0200, Mark Boon wrote: > Hi Don, > > I fixed another bug and now I get an average game-length of 111.05, > which seems to be closer again to what you have. A million > simulations now takes about 35 seconds. Is it a kind of bug that others might make? I want to keep a list of common implementation mistakes that I might add to the web page later. So if you want to share this just let me know, otherwise no worries. > > I'm now running a twogtp test against your ref-bot. After 1,000 games > my bot has a winning percentage of 48.8% (+/- 1.6) according to > twogtp. That is well within 2 standard deviations so I don't think there is a problem. In fact it is within 1 standard deviation - you should get scores outside 1 SD fairly often, so this is actually quite good. > I suppose that's barely within the margin of error. I would > have felt more confident if it had been closer. I'll run more tests > over the weekend. And I'll put it up at CGOS as well. What are the > number of playouts to use on CGOS? I believe the default of your ref- > bot is 1,000, but on CGOS I see jref-XXX-2k and myCtest-2k-AMAF. So > should I use 2,000 playouts? Yes, if you want a direct comparison. We should all bunch up together. Over time we should trade places and shuffle around a bit. - Don > > Mark > signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] From zero to playing on CGOS in 10 minutes
Hi Don, I fixed another bug and now I get an average game-length of 111.05, which seems to be closer again to what you have. A million simulations now takes about 35 seconds. I'm now running a twogtp test against your ref-bot. After 1,000 games my bot has a winning percentage of 48.8% (+/- 1.6) according to twogtp. I suppose that's barely within the margin of error. I would have felt more confident if it had been closer. I'll run more tests over the weekend. And I'll put it up at CGOS as well. What are the number of playouts to use on CGOS? I believe the default of your ref- bot is 1,000, but on CGOS I see jref-XXX-2k and myCtest-2k-AMAF. So should I use 2,000 playouts? Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Git, any other ideas?
For those of you who use windows, I highly recommend tortoise cvs and tortoise svn, which map access to whichever repository you prefer into an incredibly useful and intuitive interface piggybacked on windows explorer. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Git, any other ideas?
For those of you who use windows, I highly recommend tortoise cvs and tortoise svn, which map access to whichever repository you prefer into an incredibly useful and intuitive interface piggybacked on windows explorer. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Git, any other ideas?
On Fri, 2008-10-24 at 14:27 -0700, Ian Osgood wrote: > I cannot argue with this. I too have found git to have a steep > learning curve. Like others, I believe it has been worth it. Also, > it > is rather young compared to CVS and Subversion, and it is still > coming to maturity. I only use a small fraction of the git commands and haven't taken the time to learn beyond the very basics. However, it is incredibly snappy. I don't think Mark will be able to complain about the speed. - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Git, any other ideas?
Strange. I had tried that same update-site before but got an error. At another site I found very complicated instructions, which seemed to involve a plugin based on files a year old. And it didn't work with my Eclipse installation. Now I tried the update-site again, just to make sure I didn't overlook anything, and now it seems to have worked. I may give it another try tomorow... Mark On Fri, Oct 24, 2008 at 7:27 PM, Ian Osgood <[EMAIL PROTECTED]> wrote: > > On Oct 24, 2008, at 1:58 PM, Mark Boon wrote: > >> Well, the reason for moving off Subversion (potentially) was that I >> found it too slow to have my repository online. I can use mirroring, >> which may be the best option for now, but if possible I'd prefer it to >> be set up so that others can make changes as well. >> >> The only Eclipse plugin I found for git (and I did look around) seems >> to be an abandoned project. So that doesn't instill any confidence at >> all that the situation will improve any time soon. > > ??? > > The last commits to egit were just two days ago: > > http://www.jgit.org/cgi-bin/gitweb/gitweb.cgi?p=EGIT.git;a=summary > > Plugin update site for Update Manager: > http://www.jgit.org/update-site > > It does seem to require you to have installed the git command line tools > first (either Cygwin or MSYS). > >> >> I feel I have better things to do with my scarce time than figuring >> out complicated install procedures, so if I don't find anything easy >> to replace Subversion I'll stick to that. >> >> Mark > > I cannot argue with this. I too have found git to have a steep learning > curve. Like others, I believe it has been worth it. Also, it is rather young > compared to CVS and Subversion, and it is still coming to maturity. > > 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] Git, any other ideas?
On Oct 24, 2008, at 1:58 PM, Mark Boon wrote: Well, the reason for moving off Subversion (potentially) was that I found it too slow to have my repository online. I can use mirroring, which may be the best option for now, but if possible I'd prefer it to be set up so that others can make changes as well. The only Eclipse plugin I found for git (and I did look around) seems to be an abandoned project. So that doesn't instill any confidence at all that the situation will improve any time soon. ??? The last commits to egit were just two days ago: http://www.jgit.org/cgi-bin/gitweb/gitweb.cgi?p=EGIT.git;a=summary Plugin update site for Update Manager: http://www.jgit.org/update-site It does seem to require you to have installed the git command line tools first (either Cygwin or MSYS). I feel I have better things to do with my scarce time than figuring out complicated install procedures, so if I don't find anything easy to replace Subversion I'll stick to that. Mark I cannot argue with this. I too have found git to have a steep learning curve. Like others, I believe it has been worth it. Also, it is rather young compared to CVS and Subversion, and it is still coming to maturity. Ian ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Git, any other ideas?
Well, the reason for moving off Subversion (potentially) was that I found it too slow to have my repository online. I can use mirroring, which may be the best option for now, but if possible I'd prefer it to be set up so that others can make changes as well. The only Eclipse plugin I found for git (and I did look around) seems to be an abandoned project. So that doesn't instill any confidence at all that the situation will improve any time soon. I feel I have better things to do with my scarce time than figuring out complicated install procedures, so if I don't find anything easy to replace Subversion I'll stick to that. Mark On Fri, Oct 24, 2008 at 6:30 PM, Jim O'Flaherty, Jr. <[EMAIL PROTECTED]> wrote: > Mark, > > I would figure that given the popularity of both Eclipse and git, the > problems connecting the two easily, similar to the way Eclipse and > Subversion connect, will be solved sooner rather than later. And once they > are, it won't be too difficult to transition from whatever you choose to use > in the interim. It's not like the core "framework" project is going to have > a ton of supported branches or even contributors, right? > > BTW, I don't recall why you were moving off of Subversion. Why not stay > there for the interim unless you have lots of coders who will be working on > the framework (as opposed to being a client using the framework .jar-s). I > figure the JAGS framework would only have a couple of contributors. It's the > clients of the framework who want to experiment with the least investment in > "install, set up and indefinitely tinker" who will gain advantage. And they > don't need version control at all. Almost all of them will just be consuming > the framework .jar-s and likely doing the development alone. And for those > who are part of a team (or are just have to work with a one), they will be > choosing their own VCS completely decoupled from the choices around the > development of the JAGS framework. > > > Jim > > > > From: Mark Boon <[EMAIL PROTECTED]> > To: computer-go > Sent: Friday, October 24, 2008 3:13:09 PM > Subject: Re: [computer-go] Git, any other ideas? > > > On 24-okt-08, at 16:15, Zach Wegner wrote: > >> Use git anyways ;) I don't use an IDE, but git works great for me from >> the command line. After I realized that "git" in pkgsrc was actually >> GNU Interactive Tools and not git, it took me just a few minutes to >> set up. The basic commands are really easy to learn, especially if you >> are familiar with CVS/SVN. There are also separate GUI frontends for >> git, so that might be an option worth looking at. >> > > Over my dead body :) > > If I don't get similar integration in Eclipse as Subversion I'm not > interested. > > Now trying Mercurial. Also problems there, as it complains about some > python library. At least the Eclipse plugin installed without a hitch. > > Mark > > ___ > 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] Git, any other ideas?
Mark, The usual questions: what versions of things were you trying, config logs, what responses you got from the support mailing lists and IRC, etc. Did you look at these pages for advice? * http://www.jgit.org/ * http://git.or.cz/gitwiki/EclipsePlugin Our shop does cross platform Eclipse Java development using git at the command line, and we have been thinking of using Egit on Windows to avoid some file permission problems (unlike other platforms, Eclipse on Windows holds some files open exclusively so that Cygwin git can't manipulate the working copy reliably), so I'm interested in your experience. Ian On Oct 24, 2008, at 11:03 AM, Mark Boon wrote: Due to several recommendations from this list I decided to take a look at git. After wasting a few hours trying to get the Eclipse plugin to work I decided to give up. I might give it a look again when it comes with a reliable installer / update-link. Any other ideas? I can keep using Subversion and mirror it. But then traffic can only go one way... Mark ___ 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] Git, any other ideas?
Mark, I would figure that given the popularity of both Eclipse and git, the problems connecting the two easily, similar to the way Eclipse and Subversion connect, will be solved sooner rather than later. And once they are, it won't be too difficult to transition from whatever you choose to use in the interim. It's not like the core "framework" project is going to have a ton of supported branches or even contributors, right? BTW, I don't recall why you were moving off of Subversion. Why not stay there for the interim unless you have lots of coders who will be working on the framework (as opposed to being a client using the framework .jar-s). I figure the JAGS framework would only have a couple of contributors. It's the clients of the framework who want to experiment with the least investment in "install, set up and indefinitely tinker" who will gain advantage. And they don't need version control at all. Almost all of them will just be consuming the framework .jar-s and likely doing the development alone. And for those who are part of a team (or are just have to work with a one), they will be choosing their own VCS completely decoupled from the choices around the development of the JAGS framework. Jim From: Mark Boon <[EMAIL PROTECTED]> To: computer-go Sent: Friday, October 24, 2008 3:13:09 PM Subject: Re: [computer-go] Git, any other ideas? On 24-okt-08, at 16:15, Zach Wegner wrote: > Use git anyways ;) I don't use an IDE, but git works great for me from > the command line. After I realized that "git" in pkgsrc was actually > GNU Interactive Tools and not git, it took me just a few minutes to > set up. The basic commands are really easy to learn, especially if you > are familiar with CVS/SVN. There are also separate GUI frontends for > git, so that might be an option worth looking at. > Over my dead body :) If I don't get similar integration in Eclipse as Subversion I'm not interested. Now trying Mercurial. Also problems there, as it complains about some python library. At least the Eclipse plugin installed without a hitch. Mark ___ 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] Git, any other ideas?
On 24-okt-08, at 16:15, Zach Wegner wrote: Use git anyways ;) I don't use an IDE, but git works great for me from the command line. After I realized that "git" in pkgsrc was actually GNU Interactive Tools and not git, it took me just a few minutes to set up. The basic commands are really easy to learn, especially if you are familiar with CVS/SVN. There are also separate GUI frontends for git, so that might be an option worth looking at. Over my dead body :) If I don't get similar integration in Eclipse as Subversion I'm not interested. Now trying Mercurial. Also problems there, as it complains about some python library. At least the Eclipse plugin installed without a hitch. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] go rules in Haskell
After some more tinkering, I put two new versions of Go Rules in Haskell on my go page at http://www.cwi.nl/~tromp/go.html The simpler one is annotated with the 10 articles of the rules, while the fancier one is parametrized by board topology (like templates in C++). Yesterday, I discovered a cute tutorial for Haskell at http://learnyouahaskell.com/ After completing that, it should be pretty easy to understand my programs... regards, -John ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Ending games by two passes
On Oct 24, 2008, at 1:07 PM, Nick Wedd <[EMAIL PROTECTED]> wrote:
In message <[EMAIL PROTECTED]>, Jason
House <[EMAIL PROTECTED]> writes
On Oct 24, 2008, at 11:23 AM, "Erik van der Werf" <[EMAIL PROTECTED]
wrote:
On Fri, Oct 24, 2008 at 4:57 PM, Robert Jasiek <[EMAIL PROTECTED]>
wrote:
[EMAIL PROTECTED] wrote:
In my opinion the goal of a ko rule is to prevent games from not
ending.
All restriction rules (about suicide, cyclic repetition,
successions
passes) contribute to that goal. Ko rules do so by restricting
cycles,
succession of pass rules do so to avoid very long encores.
1: [1-eye-flaw], 2: [triple-ko,...]
Is it mathematically impossible to construct a ko rule that
allows 1 and
avoid 2? [...]
superko. It is overly restrictive.
In principle, everything can be expressed by rules. E.g., both 1
and 2 can
be avoided by the following, not overly restrictive restriction
rules
combination:
- the basic ko rule as the 2 move rule (i.e., passes serve as ko
threats)
- the fixed ko rule ("A play may not leave position A and create
position B
if any earlier play has left position A and created position B.")
- 3 ending passes
The effect is that 1-eye-flaws can be removed, triple-kos are not
fought,
and triple-kos can be removed (one side is dead!).
Fine in theory but nobody likes my very efficient invention :
( Maybe you?
I guess more people would like it if triple-kos and other non-
abusive
long cycles would lead to a tie.
Erik
I'd prefer to see them treated luke a seki. I'd only want a tie if
the capture cycle changed the score back and forth between B+0.5
and W+0.5
This implies that someone or something is capable of calculating the
score. But a cycle can occur long before the endgame makes the
score calculable.
I mean that after the game is ended and enters scoring. Scoring a seki
can be tough for programs, but is part of the rules.
Nick
--
Nick Wedd[EMAIL PROTECTED]
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Git, any other ideas?
If you are interested, search for "git versus bazaar" or "mercurial versus git" or whatever for any pair of mercurial, git, and bazaar on google. For my purposes, it really didn't matter too much which one I used so I used the first thing that worked. Git has a reputation for being very fast and having loads of advanced features and being hard to learn. - George On Fri, Oct 24, 2008 at 2:45 PM, Don Dailey <[EMAIL PROTECTED]> wrote: > On Fri, 2008-10-24 at 16:03 -0200, Mark Boon wrote: >> Due to several recommendations from this list I decided to take a >> look at git. >> >> After wasting a few hours trying to get the Eclipse plugin to work I >> decided to give up. I might give it a look again when it comes with a >> reliable installer / update-link. >> >> Any other ideas? > > I would suggest that you stay with Git. I think it is rapidly becoming > the king and I think it's probably the best. > > You are probably going to have some pain with anything at first - it's > worth going beyond the learning curve. > > Git is very simple to use from the command line and you should check out > "instaweb" (git instaweb) which builds a very nice web page where you > can trace your projects history and so on. > > - Don > > > >> >> I can keep using Subversion and mirror it. But then traffic can only >> go one way... >> >> Mark >> >> ___ >> 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] Git, any other ideas?
On Fri, 2008-10-24 at 16:03 -0200, Mark Boon wrote: > Due to several recommendations from this list I decided to take a > look at git. > > After wasting a few hours trying to get the Eclipse plugin to work I > decided to give up. I might give it a look again when it comes with a > reliable installer / update-link. > > Any other ideas? I would suggest that you stay with Git. I think it is rapidly becoming the king and I think it's probably the best. You are probably going to have some pain with anything at first - it's worth going beyond the learning curve. Git is very simple to use from the command line and you should check out "instaweb" (git instaweb) which builds a very nice web page where you can trace your projects history and so on. - Don > > I can keep using Subversion and mirror it. But then traffic can only > go one way... > > Mark > > ___ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Ending games by two passes
On Fri, 2008-10-24 at 19:40 +0200, [EMAIL PROTECTED] wrote: > After reading up a bit on this issue, I didn't find a clear positive > consensus in this list about a preferred ruleset for computer-go, > human-computer-go, real life go and go servers. > (I did find a negative consensus about the current Japanese rules, > though) > > I'm curious if there exists a positive consensus about a > particular ruleset from the point of view of a go software user who is > also very familiar with real life go playing (so not from a > mathematical or pedagogical point of view, but from the point of view > of a go player playing on a server and/or playing against a bot). This > user could prefer area counting or territory counting. I think the current rules CGOS uses are pretty popular for CGOS and I think it's what you get with KGS games played under Chinese rules too. CGOS rules are basically Tromp/Taylor rules but where suicide is forbidden. Suicide makes the game slightly less practical, especially for computers (but it's not a big deal.) Other than that Tromp/Taylor rules shine because they are very intuitively simple to learn and state. Just simple and clean. I'm not an expert on AGA rules but I think it's almost the same. There are tons of simple rule variations, the kind of ko to use, whether to use suicide or not, how many passes to end the game, scoring system, how to deal with handicaps, which komi to use, etc. I think Japanese hurts the game, but even if we confine ourselves to Chinese it hurts the game that there are so many variations of the rules.You cannot really play a game without first negotiating which rules you will be using. - Don > Specifically: could the current AGA rules be a serious > competitor (http://www.usgo.org/resources/downloads/completerules.pdf)? > > Dave > > > __ > Van: [EMAIL PROTECTED] namens Erik van der Werf > Verzonden: vr 24-10-2008 12:18 > Aan: computer-go > Onderwerp: Re: [computer-go] Ending games by two passes > > > On Fri, Oct 24, 2008 at 11:47 AM, <[EMAIL PROTECTED]> wrote: > > Please correct me if I'm wrong, but are you saying that white is > alive with > > TT-rules (=Tromp-Taylor?) or other rulesets with positional superko > if black > > has not enough eyes left to fill as ko threats? > > Yes. > > > If that's true, I would be disgusted if positional superko would > ever be > > accepted as a rule in human vs. human games. > > Does it really matter if it is human vs. human games? Why have > different (inferior?) standards for computers anyway? > > Erik > ___ > 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/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Git, any other ideas?
Use git anyways ;) I don't use an IDE, but git works great for me from the command line. After I realized that "git" in pkgsrc was actually GNU Interactive Tools and not git, it took me just a few minutes to set up. The basic commands are really easy to learn, especially if you are familiar with CVS/SVN. There are also separate GUI frontends for git, so that might be an option worth looking at. But anyways, I've heard good things about Darcs and Mercurial. The time I spent trying to use Darcs wasn't very pleasant (and it was hard to setup IIRC). I gather that it is far less mature than git, so it probably won't have a plugin. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Git, any other ideas?
mercurial or bazaar. I use bazaar myself. It took me 5 minutes to figure out how to do the very basics, which so far has been enough for me. I think both have eclipse plugins, but I haven't used them. - George On Fri, Oct 24, 2008 at 2:03 PM, Mark Boon <[EMAIL PROTECTED]> wrote: > Due to several recommendations from this list I decided to take a look at > git. > > After wasting a few hours trying to get the Eclipse plugin to work I decided > to give up. I might give it a look again when it comes with a reliable > installer / update-link. > > Any other ideas? > > I can keep using Subversion and mirror it. But then traffic can only go one > way... > > Mark > > ___ > 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] Git, any other ideas?
Due to several recommendations from this list I decided to take a look at git. After wasting a few hours trying to get the Eclipse plugin to work I decided to give up. I might give it a look again when it comes with a reliable installer / update-link. Any other ideas? I can keep using Subversion and mirror it. But then traffic can only go one way... Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Ending games by two passes
After reading up a bit on this issue, I didn't find a clear positive consensus in this list about a preferred ruleset for computer-go, human-computer-go, real life go and go servers. (I did find a negative consensus about the current Japanese rules, though) I'm curious if there exists a positive consensus about a particular ruleset from the point of view of a go software user who is also very familiar with real life go playing (so not from a mathematical or pedagogical point of view, but from the point of view of a go player playing on a server and/or playing against a bot). This user could prefer area counting or territory counting. Specifically: could the current AGA rules be a serious competitor (http://www.usgo.org/resources/downloads/completerules.pdf)? Dave Van: [EMAIL PROTECTED] namens Erik van der Werf Verzonden: vr 24-10-2008 12:18 Aan: computer-go Onderwerp: Re: [computer-go] Ending games by two passes On Fri, Oct 24, 2008 at 11:47 AM, <[EMAIL PROTECTED]> wrote: > Please correct me if I'm wrong, but are you saying that white is alive with > TT-rules (=Tromp-Taylor?) or other rulesets with positional superko if black > has not enough eyes left to fill as ko threats? Yes. > If that's true, I would be disgusted if positional superko would ever be > accepted as a rule in human vs. human games. Does it really matter if it is human vs. human games? Why have different (inferior?) standards for computers anyway? Erik ___ 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] Ending games by two passes
[EMAIL PROTECTED] wrote: Is your "unpopular invention" equivalent to situational superko? You underestimate my creativity! :) Test the "fixed ko rule" by applying it to some shapes. Here is the most basic application: . # O . # O . O . # O . start . # O . # O 1 O . # O . legal . # O . # 2 # O . # O . legal . # O . # O 3 O . # O . illegal Since the fixed ko rule lets all(!) known kos be fixed (therefore its cute name!), we also need the basic ko rule to have at least all our standard ko fights and to avoid that a basic ko would equal an eye in an ordinary tsumego situation. -- robert jasiek ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Ending games by two passes
In message <[EMAIL PROTECTED]>, Jason House
<[EMAIL PROTECTED]> writes
On Oct 24, 2008, at 11:23 AM, "Erik van der Werf"
<[EMAIL PROTECTED]
wrote:
On Fri, Oct 24, 2008 at 4:57 PM, Robert Jasiek <[EMAIL PROTECTED]>
wrote:
[EMAIL PROTECTED] wrote:
In my opinion the goal of a ko rule is to prevent games from not
ending.
All restriction rules (about suicide, cyclic repetition, successions
passes) contribute to that goal. Ko rules do so by restricting
cycles,
succession of pass rules do so to avoid very long encores.
1: [1-eye-flaw], 2: [triple-ko,...]
Is it mathematically impossible to construct a ko rule that allows
1 and
avoid 2? [...]
superko. It is overly restrictive.
In principle, everything can be expressed by rules. E.g., both 1 and
2 can
be avoided by the following, not overly restrictive restriction rules
combination:
- the basic ko rule as the 2 move rule (i.e., passes serve as ko
threats)
- the fixed ko rule ("A play may not leave position A and create
position B
if any earlier play has left position A and created position B.")
- 3 ending passes
The effect is that 1-eye-flaws can be removed, triple-kos are not
fought,
and triple-kos can be removed (one side is dead!).
Fine in theory but nobody likes my very efficient invention : (
Maybe you?
I guess more people would like it if triple-kos and other non-abusive
long cycles would lead to a tie.
Erik
I'd prefer to see them treated luke a seki. I'd only want a tie if the
capture cycle changed the score back and forth between B+0.5 and W+0.5
This implies that someone or something is capable of calculating the
score. But a cycle can occur long before the endgame makes the score
calculable.
Nick
--
Nick Wedd[EMAIL PROTECTED]
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Ending games by two passes
Erik van der Werf wrote: I guess more people would like it if triple-kos and other non-abusive long cycles would lead to a tie. For that purpose one can use different rules: - 2 or 3 play rule (applies to basic ko and sending-2-returning-1) - pass lifts 2-move cycle ko ban rule - long-cycle-tie rule - 3 ending passes -- robert jasiek ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Ending games by two passes
On Oct 24, 2008, at 11:23 AM, "Erik van der Werf" <[EMAIL PROTECTED]
> wrote:
On Fri, Oct 24, 2008 at 4:57 PM, Robert Jasiek <[EMAIL PROTECTED]>
wrote:
[EMAIL PROTECTED] wrote:
In my opinion the goal of a ko rule is to prevent games from not
ending.
All restriction rules (about suicide, cyclic repetition,
successions of
passes) contribute to that goal. Ko rules do so by restricting
cycles,
succession of pass rules do so to avoid very long encores.
1: [1-eye-flaw], 2: [triple-ko,...]
Is it mathematically impossible to construct a ko rule that allows
1 and
avoid 2? [...]
superko. It is overly restrictive.
In principle, everything can be expressed by rules. E.g., both 1
and 2 can
be avoided by the following, not overly restrictive restriction rules
combination:
- the basic ko rule as the 2 move rule (i.e., passes serve as ko
threats)
- the fixed ko rule ("A play may not leave position A and create
position B
if any earlier play has left position A and created position B.")
- 3 ending passes
The effect is that 1-eye-flaws can be removed, triple-kos are not
fought,
and triple-kos can be removed (one side is dead!).
Fine in theory but nobody likes my very efficient invention :
( Maybe you?
I guess more people would like it if triple-kos and other non-abusive
long cycles would lead to a tie.
Erik
I'd prefer to see them treated luke a seki. I'd only want a tie if the
capture cycle changed the score back and forth between B+0.5 and W+0.5
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Ending games by two passes
On Fri, Oct 24, 2008 at 4:57 PM, Robert Jasiek <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>>
>> In my opinion the goal of a ko rule is to prevent games from not ending.
>
> All restriction rules (about suicide, cyclic repetition, successions of
> passes) contribute to that goal. Ko rules do so by restricting cycles,
> succession of pass rules do so to avoid very long encores.
>
>> 1: [1-eye-flaw], 2: [triple-ko,...]
>>
>> Is it mathematically impossible to construct a ko rule that allows 1 and
>
>> avoid 2? [...]
>> superko. It is overly restrictive.
>
> In principle, everything can be expressed by rules. E.g., both 1 and 2 can
> be avoided by the following, not overly restrictive restriction rules
> combination:
>
> - the basic ko rule as the 2 move rule (i.e., passes serve as ko threats)
> - the fixed ko rule ("A play may not leave position A and create position B
> if any earlier play has left position A and created position B.")
> - 3 ending passes
>
> The effect is that 1-eye-flaws can be removed, triple-kos are not fought,
> and triple-kos can be removed (one side is dead!).
>
> Fine in theory but nobody likes my very efficient invention :( Maybe you?
>
I guess more people would like it if triple-kos and other non-abusive
long cycles would lead to a tie.
Erik
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Ending games by two passes
Thank you for clearing this up.
One more question: Is your "unpopular invention" equivalent to situational
superko?
(after some reading I think that means that a position may not be repeated with
the same player to move)
Dave
Van: [EMAIL PROTECTED] namens Robert Jasiek
Verzonden: vr 24-10-2008 16:57
Aan: computer-go
Onderwerp: Re: [computer-go] Ending games by two passes
[EMAIL PROTECTED] wrote:
> In my opinion the goal of a ko rule is to prevent games from not ending.
All restriction rules (about suicide, cyclic repetition, successions of
passes) contribute to that goal. Ko rules do so by restricting cycles,
succession of pass rules do so to avoid very long encores.
> 1: [1-eye-flaw], 2: [triple-ko,...]
> Is it mathematically impossible to construct a ko rule that allows 1 and
> avoid 2? [...]
> superko. It is overly restrictive.
In principle, everything can be expressed by rules. E.g., both 1 and 2
can be avoided by the following, not overly restrictive restriction
rules combination:
- the basic ko rule as the 2 move rule (i.e., passes serve as ko threats)
- the fixed ko rule ("A play may not leave position A and create
position B if any earlier play has left position A and created position B.")
- 3 ending passes
The effect is that 1-eye-flaws can be removed, triple-kos are not
fought, and triple-kos can be removed (one side is dead!).
Fine in theory but nobody likes my very efficient invention :( Maybe you?
--
robert jasiek
___
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] Ending games by two passes
[EMAIL PROTECTED] wrote:
In my opinion the goal of a ko rule is to prevent games from not ending.
All restriction rules (about suicide, cyclic repetition, successions of
passes) contribute to that goal. Ko rules do so by restricting cycles,
succession of pass rules do so to avoid very long encores.
> 1: [1-eye-flaw], 2: [triple-ko,...]
Is it mathematically impossible to construct a ko rule that allows 1 and
> avoid 2? [...]
> superko. It is overly restrictive.
In principle, everything can be expressed by rules. E.g., both 1 and 2
can be avoided by the following, not overly restrictive restriction
rules combination:
- the basic ko rule as the 2 move rule (i.e., passes serve as ko threats)
- the fixed ko rule ("A play may not leave position A and create
position B if any earlier play has left position A and created position B.")
- 3 ending passes
The effect is that 1-eye-flaws can be removed, triple-kos are not
fought, and triple-kos can be removed (one side is dead!).
Fine in theory but nobody likes my very efficient invention :( Maybe you?
--
robert jasiek
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Ending games by two passes
In my opinion the goal of a ko rule is to prevent games from not ending. 1: If one player can force a game to an end even when the other player aims at not ending the game, then the rule is good enough. In my previous example I would consider it an undesired side effect of a ko rule that white would win he game. There would be no danger of the game not ending if the ko rule were less restrictive than positional superko. Black should be allowed to capture white. 2: In rare cases the only non-losing way for either player could be to aim for an everlasting game, like a triple ko. In that case an everlasting game it near optimal play for both players. 3: I guess a ko rule does not have to be so restrictive to prevent everlasting games in in general. If it can solve situation 2 while still allowing 1, than that is good enough. Is it mathematically impossible to construct a ko rule that allows 1 and avoid 2? If not, I would prefer keep 1 and leave 2 undefined. I am no rules expert, but I cannot explain more clearly why I would be disgusted by positional superko. It is overly restrictive. Dave Van: [EMAIL PROTECTED] namens Robert Jasiek Verzonden: vr 24-10-2008 14:10 Aan: computer-go Onderwerp: Re: [computer-go] Ending games by two passes [EMAIL PROTECTED] wrote: > Is it correct to end games by 2 consecutive passes? It is correct to end games according to the used rules. Different rules use different numbers of passes, meanings of passes, or procedures assiated with passes. Some examples of numers of passes in actually used rulesets are: 2 passes 3 passes 2 passes + optionally once 2 passes 2 passes + optionally an arbitrary occurrence of yet 2 more passes 2 passes + 2 mandatory further passes after the first, 2 passes etc. One cannot say in general which better because this depends on one's aims. E.g., if the aim is shortest procedure on the rules level, then one would choose 2 passes. E.g., if the aim is to always allow each player a pass as a ko threat while a pass does relieve ko bans sufficiently, then one might choose 3 passes. E.g., if the first pass generates a conditional compensation and one wants to allow each player the filling of 1-sided dame regardless, then one might choose after the first, 2 passes. Etc. > white is alive [under] rulesets with positional superko if black has not > enough eyes left to fill as ko threats? > If that's true, I would be disgusted if positional superko would ever be > accepted as a rule in human vs. human games. Why would you be disgusted? The so called 1-eye-flaw occurs in much less than 1 of 10,000,000 games on the 19x19 board. In the entire history of go, it is reported to have occurred exactly once on the 9x9 board. Why do you dislike rules that enable something possible in theory but never occurring in practice? What do you have against 1-eye-flaw staying on the board at the game end? a) That it is a group with only 1 eye, b) that it is a group with only 1 ko, or c) that there is a string with only 1 liberty? Discussion of (a), (b), and (c): All rulesets used by humans allow games to end with groups with only 1 liberty. Example: # O # . # O . O # O # O # . # O . O # O # O # . # O . O # O # O # . # O . O # O . O # . # O . O # . This example shows two stable anti-sekis. By symmetry, it would be superfluous to prolong the game to dissolve either. If you are disgusted by 1-eye-flaw, then you should be even more disgusted by anti-sekis. I.e., you are disgusted by all rulesets currently used by humans. Strings with 1 liberty at the game end can also occur in hane-sekis, double ko sekis, quadruple kos, etc. Maybe you would human rules to be changed by ca so called greedy rule like "A player may not pass if there is at least one string with exactly 1 liberty on the board." Such would dissolve all those disgusting things. One can even be more brutal in rules design like dissolving all those disgusting ordinary sekis, too. :) If you want to criticise positional superko, then state your first order aims! Which are they? "I hate 1-eye-flaw!"? Why should one particular shape be that all-important while we do not know some 100^500 other shapes yet? List them all, and then tell us what makes 1-eye-flaw so special :) More importantly, why are you worried about a shape at all? Shapes are the consequences of move-sequences and strategic decisions, see http://home.snafu.de/jasiek/j2003.html for a basis with that I defined "eye" formally. Write down your disgusting rules with such a design to enable yourself to define particular shapes in the first place so that you won't overlook any of your potentially hated disgusting shapes... BTW, positional superko IS accepted in some human rulesets like Chinese, Simplified Ing, or World Mind Sports Games 2008. -- robert jasiek ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listi
Re: [computer-go] Ending games by two passes
[EMAIL PROTECTED] wrote: Is it correct to end games by 2 consecutive passes? It is correct to end games according to the used rules. Different rules use different numbers of passes, meanings of passes, or procedures assiated with passes. Some examples of numers of passes in actually used rulesets are: 2 passes 3 passes 2 passes + optionally once 2 passes 2 passes + optionally an arbitrary occurrence of yet 2 more passes 2 passes + 2 mandatory further passes after the first, 2 passes etc. One cannot say in general which better because this depends on one's aims. E.g., if the aim is shortest procedure on the rules level, then one would choose 2 passes. E.g., if the aim is to always allow each player a pass as a ko threat while a pass does relieve ko bans sufficiently, then one might choose 3 passes. E.g., if the first pass generates a conditional compensation and one wants to allow each player the filling of 1-sided dame regardless, then one might choose after the first, 2 passes. Etc. white is alive [under] rulesets with positional superko if black has not > enough eyes left to fill as ko threats? If that's true, I would be disgusted if positional superko would ever be > accepted as a rule in human vs. human games. Why would you be disgusted? The so called 1-eye-flaw occurs in much less than 1 of 10,000,000 games on the 19x19 board. In the entire history of go, it is reported to have occurred exactly once on the 9x9 board. Why do you dislike rules that enable something possible in theory but never occurring in practice? What do you have against 1-eye-flaw staying on the board at the game end? a) That it is a group with only 1 eye, b) that it is a group with only 1 ko, or c) that there is a string with only 1 liberty? Discussion of (a), (b), and (c): All rulesets used by humans allow games to end with groups with only 1 liberty. Example: # O # . # O . O # O # O # . # O . O # O # O # . # O . O # O # O # . # O . O # O . O # . # O . O # . This example shows two stable anti-sekis. By symmetry, it would be superfluous to prolong the game to dissolve either. If you are disgusted by 1-eye-flaw, then you should be even more disgusted by anti-sekis. I.e., you are disgusted by all rulesets currently used by humans. Strings with 1 liberty at the game end can also occur in hane-sekis, double ko sekis, quadruple kos, etc. Maybe you would human rules to be changed by ca so called greedy rule like "A player may not pass if there is at least one string with exactly 1 liberty on the board." Such would dissolve all those disgusting things. One can even be more brutal in rules design like dissolving all those disgusting ordinary sekis, too. :) If you want to criticise positional superko, then state your first order aims! Which are they? "I hate 1-eye-flaw!"? Why should one particular shape be that all-important while we do not know some 100^500 other shapes yet? List them all, and then tell us what makes 1-eye-flaw so special :) More importantly, why are you worried about a shape at all? Shapes are the consequences of move-sequences and strategic decisions, see http://home.snafu.de/jasiek/j2003.html for a basis with that I defined "eye" formally. Write down your disgusting rules with such a design to enable yourself to define particular shapes in the first place so that you won't overlook any of your potentially hated disgusting shapes... BTW, positional superko IS accepted in some human rulesets like Chinese, Simplified Ing, or World Mind Sports Games 2008. -- robert jasiek ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Ending games by two passes
I'm glad we agree on this :) Your previous respons suggests that this issue has been debated before on this list, so I'll probably be able to find references about this issue. I wouldn't want to restart a debate here about positional superko :) Thanks, Dave Van: [EMAIL PROTECTED] namens Erik van der Werf Verzonden: vr 24-10-2008 12:18 Aan: computer-go Onderwerp: Re: [computer-go] Ending games by two passes On Fri, Oct 24, 2008 at 11:47 AM, <[EMAIL PROTECTED]> wrote: > Please correct me if I'm wrong, but are you saying that white is alive with > TT-rules (=Tromp-Taylor?) or other rulesets with positional superko if black > has not enough eyes left to fill as ko threats? Yes. > If that's true, I would be disgusted if positional superko would ever be > accepted as a rule in human vs. human games. Does it really matter if it is human vs. human games? Why have different (inferior?) standards for computers anyway? Erik ___ 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] Ending games by two passes
On Fri, Oct 24, 2008 at 11:47 AM, <[EMAIL PROTECTED]> wrote: > Please correct me if I'm wrong, but are you saying that white is alive with > TT-rules (=Tromp-Taylor?) or other rulesets with positional superko if black > has not enough eyes left to fill as ko threats? Yes. > If that's true, I would be disgusted if positional superko would ever be > accepted as a rule in human vs. human games. Does it really matter if it is human vs. human games? Why have different (inferior?) standards for computers anyway? Erik ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Ending games by two passes
Please correct me if I'm wrong, but are you saying that white is alive with TT-rules (=Tromp-Taylor?) or other rulesets with positional superko if black has not enough eyes left to fill as ko threats? If that's true, I would be disgusted if positional superko would ever be accepted as a rule in human vs. human games. Dave Van: [EMAIL PROTECTED] namens Erik van der Werf Verzonden: vr 24-10-2008 11:32 Aan: computer-go Onderwerp: Re: [computer-go] Ending games by two passes Hi Dave, This is a well-known problem with overly simplified rulesets. TT-advocates don't care about the rare anomalies. Did you notice that under positional superko you cannot take back the ko after *any* number of consecutive passes? This is yet another reason why in some cases filling an eye or playing in sure territory may be the best move... In your engine you don't want to use 3 passes unless absolutely necessary because of horizon effects. In my experience it is best to use 3 passes only if there is exactly one basic ko, and in all other cases use 2 passes to end the game. Erik On Fri, Oct 24, 2008 at 10:00 AM, <[EMAIL PROTECTED]> wrote: > Is it correct to end games by 2 consecutive passes? > > When I learned go 20 years ago I was taught that 3 consecutive passes are > required to end a game of go. > In practice 2 passes are sufficient in nearly all cases, but sometimes 2 > passes is not enough. > Suppose we have this position in a 5x5 game with area scoring and 2.5 komi: > > (0 = white, # = black) > > ABCDE > 5 00### > 4 00#+# > 3 +0### > 2 00##+ > 1 0#+## > > Black has just played C4. > > The controller is very simple. It only prohibits simple ko (superko is not > checked) and all stones left on the board when the game ends are considered > alive. > White now at C1. Black has no choice but pass and then white quickly passes > too. What happens now? > > If 2 passes end the game, the controller will award a win to white by the > komi. > If 3 passes are required to end the game, black captures at B1, white has no > choice but pass, then black captures at A3 and will (probably) win the game. > > On could argue that controllers are smarter than the controller in my > example, so 2 passes are usually sufficient in pactice, because the > controller will query the engines for dead stones. > But in my example, wouldn't both engines be justified to declare the white > stones alive because of the 2 pass rule? > > Also, if I am correct, (light) playouts are usually controlled by an > internal "controller" that is very similar to the controller in my example. > Wouldn't they be vulnerable to this type of situation? > > Why not avoid this issue simply by requiring 3 consecutive passes to end the > game? > > Am I missing something here? > > Dave > > > > > > > > > ___ > 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] Ending games by two passes
Hi Dave, This is a well-known problem with overly simplified rulesets. TT-advocates don't care about the rare anomalies. Did you notice that under positional superko you cannot take back the ko after *any* number of consecutive passes? This is yet another reason why in some cases filling an eye or playing in sure territory may be the best move... In your engine you don't want to use 3 passes unless absolutely necessary because of horizon effects. In my experience it is best to use 3 passes only if there is exactly one basic ko, and in all other cases use 2 passes to end the game. Erik On Fri, Oct 24, 2008 at 10:00 AM, <[EMAIL PROTECTED]> wrote: > Is it correct to end games by 2 consecutive passes? > > When I learned go 20 years ago I was taught that 3 consecutive passes are > required to end a game of go. > In practice 2 passes are sufficient in nearly all cases, but sometimes 2 > passes is not enough. > Suppose we have this position in a 5x5 game with area scoring and 2.5 komi: > > (0 = white, # = black) > > ABCDE > 5 00### > 4 00#+# > 3 +0### > 2 00##+ > 1 0#+## > > Black has just played C4. > > The controller is very simple. It only prohibits simple ko (superko is not > checked) and all stones left on the board when the game ends are considered > alive. > White now at C1. Black has no choice but pass and then white quickly passes > too. What happens now? > > If 2 passes end the game, the controller will award a win to white by the > komi. > If 3 passes are required to end the game, black captures at B1, white has no > choice but pass, then black captures at A3 and will (probably) win the game. > > On could argue that controllers are smarter than the controller in my > example, so 2 passes are usually sufficient in pactice, because the > controller will query the engines for dead stones. > But in my example, wouldn't both engines be justified to declare the white > stones alive because of the 2 pass rule? > > Also, if I am correct, (light) playouts are usually controlled by an > internal "controller" that is very similar to the controller in my example. > Wouldn't they be vulnerable to this type of situation? > > Why not avoid this issue simply by requiring 3 consecutive passes to end the > game? > > Am I missing something here? > > Dave > > > > > > > > > ___ > 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] RE: Ending games by two passes
I know white is dead, but what matters is that the controller does not know. The only way for the controller to know that white is dead is by requiring black to capture white before ending the game. And when 2 passes end the game, black is unable to do that. So the controller will have to assume that white is alive. Dave Van: [EMAIL PROTECTED] namens Li Li Verzonden: vr 24-10-2008 11:23 Aan: computer-go Onderwerp: Re: [computer-go] RE: Ending games by two passes Wrong assertion: "all stones left on the board when the game ends are considered alive." The result has nothing to do with how many "pass". The white is dead when the game is finished. On Fri, Oct 24, 2008 at 4:02 PM, <[EMAIL PROTECTED]> wrote: ERRATUM: Sorry, I made a small mistake in my example. The komi should be 3.5 so white wins by 0.5 if 2 passes end the game. Dave Van: [EMAIL PROTECTED] Verzonden: vr 24-10-2008 10:00 Aan: computer-go Onderwerp: Ending games by two passes Is it correct to end games by 2 consecutive passes? When I learned go 20 years ago I was taught that 3 consecutive passes are required to end a game of go. In practice 2 passes are sufficient in nearly all cases, but sometimes 2 passes is not enough. Suppose we have this position in a 5x5 game with area scoring and 2.5 komi: (0 = white, # = black) ABCDE 5 00### 4 00#+# 3 +0### 2 00##+ 1 0#+## Black has just played C4. The controller is very simple. It only prohibits simple ko (superko is not checked) and all stones left on the board when the game ends are considered alive. White now at C1. Black has no choice but pass and then white quickly passes too. What happens now? If 2 passes end the game, the controller will award a win to white by the komi. If 3 passes are required to end the game, black captures at B1, white has no choice but pass, then black captures at A3 and will (probably) win the game. On could argue that controllers are smarter than the controller in my example, so 2 passes are usually sufficient in pactice, because the controller will query the engines for dead stones. But in my example, wouldn't both engines be justified to declare the white stones alive because of the 2 pass rule? Also, if I am correct, (light) playouts are usually controlled by an internal "controller" that is very similar to the controller in my example. Wouldn't they be vulnerable to this type of situation? Why not avoid this issue simply by requiring 3 consecutive passes to end the game? Am I missing something here? Dave ___ 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] RE: Ending games by two passes
Wrong assertion: "all stones left on the board when the game ends are considered alive." The result has nothing to do with how many "pass". The white is dead when the game is finished. On Fri, Oct 24, 2008 at 4:02 PM, <[EMAIL PROTECTED]> wrote: > ERRATUM: > > Sorry, I made a small mistake in my example. > The komi should be 3.5 so white wins by 0.5 if 2 passes end the game. > > Dave > > -- > *Van:* [EMAIL PROTECTED] > *Verzonden:* vr 24-10-2008 10:00 > *Aan:* computer-go > *Onderwerp:* Ending games by two passes > > Is it correct to end games by 2 consecutive passes? > > When I learned go 20 years ago I was taught that 3 consecutive passes are > required to end a game of go. > In practice 2 passes are sufficient in nearly all cases, but sometimes 2 > passes is not enough. > Suppose we have this position in a 5x5 game with area scoring and 2.5 komi: > > (0 = white, # = black) > > ABCDE > 5 00### > 4 00#+# > 3 +0### > 2 00##+ > 1 0#+## > > Black has just played C4. > > The controller is very simple. It only prohibits simple ko (superko is > not checked) and all stones left on the board when the game ends are > considered alive. > White now at C1. Black has no choice but pass and then white quickly passes > too. What happens now? > > If 2 passes end the game, the controller will award a win to white by the > komi. > If 3 passes are required to end the game, black captures at B1, white has > no choice but pass, then black captures at A3 and will (probably) win the > game. > > On could argue that controllers are smarter than the controller in my > example, so 2 passes are usually sufficient in pactice, because the > controller will query the engines for dead stones. > But in my example, wouldn't both engines be justified to declare the white > stones alive because of the 2 pass rule? > > Also, if I am correct, (light) playouts are usually controlled by an > internal "controller" that is very similar to the controller in my example. > Wouldn't they be vulnerable to this type of situation? > > Why not avoid this issue simply by requiring 3 consecutive passes to end > the game? > > Am I missing something here? > > Dave > > > > > > > > > > ___ > 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] RE: Ending games by two passes
ERRATUM: Sorry, I made a small mistake in my example. The komi should be 3.5 so white wins by 0.5 if 2 passes end the game. Dave Van: [EMAIL PROTECTED] Verzonden: vr 24-10-2008 10:00 Aan: computer-go Onderwerp: Ending games by two passes Is it correct to end games by 2 consecutive passes? When I learned go 20 years ago I was taught that 3 consecutive passes are required to end a game of go. In practice 2 passes are sufficient in nearly all cases, but sometimes 2 passes is not enough. Suppose we have this position in a 5x5 game with area scoring and 2.5 komi: (0 = white, # = black) ABCDE 5 00### 4 00#+# 3 +0### 2 00##+ 1 0#+## Black has just played C4. The controller is very simple. It only prohibits simple ko (superko is not checked) and all stones left on the board when the game ends are considered alive. White now at C1. Black has no choice but pass and then white quickly passes too. What happens now? If 2 passes end the game, the controller will award a win to white by the komi. If 3 passes are required to end the game, black captures at B1, white has no choice but pass, then black captures at A3 and will (probably) win the game. On could argue that controllers are smarter than the controller in my example, so 2 passes are usually sufficient in pactice, because the controller will query the engines for dead stones. But in my example, wouldn't both engines be justified to declare the white stones alive because of the 2 pass rule? Also, if I am correct, (light) playouts are usually controlled by an internal "controller" that is very similar to the controller in my example. Wouldn't they be vulnerable to this type of situation? Why not avoid this issue simply by requiring 3 consecutive passes to end the game? Am I missing something here? Dave ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Ending games by two passes
Is it correct to end games by 2 consecutive passes? When I learned go 20 years ago I was taught that 3 consecutive passes are required to end a game of go. In practice 2 passes are sufficient in nearly all cases, but sometimes 2 passes is not enough. Suppose we have this position in a 5x5 game with area scoring and 2.5 komi: (0 = white, # = black) ABCDE 5 00### 4 00#+# 3 +0### 2 00##+ 1 0#+## Black has just played C4. The controller is very simple. It only prohibits simple ko (superko is not checked) and all stones left on the board when the game ends are considered alive. White now at C1. Black has no choice but pass and then white quickly passes too. What happens now? If 2 passes end the game, the controller will award a win to white by the komi. If 3 passes are required to end the game, black captures at B1, white has no choice but pass, then black captures at A3 and will (probably) win the game. On could argue that controllers are smarter than the controller in my example, so 2 passes are usually sufficient in pactice, because the controller will query the engines for dead stones. But in my example, wouldn't both engines be justified to declare the white stones alive because of the 2 pass rule? Also, if I am correct, (light) playouts are usually controlled by an internal "controller" that is very similar to the controller in my example. Wouldn't they be vulnerable to this type of situation? Why not avoid this issue simply by requiring 3 consecutive passes to end the game? Am I missing something here? Dave ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
