Re: [computer-go] Should 9x9 komi be 8.0 ?

Vlad Dumitrescu wrote: > Why throttle the playing strength? Wouldn't be enough to raise the > threshold where the program resigns? > Naively put: if all results say the game is lost, switch the > evaluation to "best possible score" and continue playing for a while. > If any winning paths appear, s

Re: [EMAIL PROTECTED]: Re: [computer-go] Should 9x9 komi be 8.0 ?]

Petr Baudis wrote: > The point here is to prevent the program from playing the "MC-hamete" > moves that in most cases have no hope of working, but instead still aim > at a close game and wait for some opponent's yose mistake. This closely > matches human approach to the game as well - if you are co

Re: [computer-go] Re: Should 9x9 komi be 8.0 ?]

Don Dailey wrote: > If the opponent is beating you, he is probably relatively near your > strength level. If your program KNOWS it is losing by 0.5 points, then > it's reasonable to expect that your opponent does too, especially given > the fact that he just outplayed you. Don't forget handicap

Re: endgame (Was [computer-go] Re: Should 9x9 komi be 8.0 ?])

Petr Baudis wrote: > MoGo can indeed play out some rather spectacular ko fights; > unfortunately, I couldn't find any quickly, so here is at least an > example of a shorter one. I see you made the following comment in that game record, which seems relevant to recent discussions here. | mogo excel

Re: endgame (Was [computer-go] Re: Should 9x9 komi be 8.0 ?])

Don Dailey wrote: > Although it's easy to see that nakade is a problem, I agree with > someone who said it takes a lot of skill to produce this. In fact, I > believe that it cannot be done reliably by any player unless he is > already much stronger than the program, in which case he doesn't > "need

Re: [computer-go] Floating komi

Don Dailey wrote: > I would be satisfied if someone implemented it, reported a 500 game > self-test sample and concluded that it didn't hurt the program > measurably and show a few examples of how it improved the moves > cosmetically, perhaps even comparing both version with specific > positions

Re: endgame (Was [computer-go] Re: Should 9x9 komi be 8.0 ?])

Don Dailey wrote: > I want to make sure I understand the nakade problem, please correct me > if I am wrong: > My understanding of this is that many program do not allow self-atari > moves in the play-outs because in general the overwhelming majority are > stupid moves. Is that what is causing

[computer-go] Life and Death

I've included two 13x13 positions below. In both positions it is Black's move. The first position is simplified from a real game. Black has two enclosed dead groups, and White has a small but easy win. The second position is a modified version of the first in which the dead groups are more obviou

Re: [computer-go] Life and Death

David Fotland wrote: > I just looked at this position and it looks like a win for black in the > first position. Many Faces evaluates it as a win for black, and plays c1 to > save the lower left black group with almost no thinking time. > Mogo is correct because the lower left black group is not

Re: [computer-go] CG'2008 paper: Whole-History Ratings

Christoph Birk wrote: > On Wed, 9 Apr 2008, terry mcintyre wrote: >> Beginning players do improve by 4-5 ranks in a short >> period of time. We don't all start as dan-level >> players, alas! > Yes, but short time will still be many games. It might be that most of those games aren't visible to the

Re: [computer-go] Re: mogo beats pro!

Don Dailey wrote: > Much the same as in GO, where 10 -15 years ago the idea of Dan level > play was so far off it was considered completely unattainable by > pessimists, and even optimists viewed it as a century away. Where did you get that impression? I've recently spent some time reading the ar

Re: [computer-go] Program don't start playing on CGOS

Don Dailey wrote: > I am looking at this page: > > http://cryp.to/publications/masquerading-idle-connections/ > > and wondering if it's relevant. It seems to describe the problem > pretty well, talks about a 15 minute timeout which would do it and the > timeout is built into the linux kernel but

Re: [computer-go] Re: mogo beats pro!

Don Dailey wrote: > Matthew Woodcraft wrote: >> Don Dailey wrote: >>> Much the same as in GO, where 10 -15 years ago the idea of Dan level >>> play was so far off it was considered completely unattainable by >>> pessimists, and even optimists viewed it as a cent

Re: [computer-go] Correct Komi for 6x6 is 2.0

Don Dailey wrote: > After converting all the game to a canonical representation, I > discovered that Leela always plays the first 4 moves the equivalent of > this: > > C3 D4 C4 D3 - all 784 games started like this or the equivalent > > > After this, BLACK varied significantly: > >

Re: [computer-go] Re: Reference bot and gtpstatistics

Don Dailey wrote: > When you get a quit command, you send something over the pipe but then > you immediately shutdown the program (and the pipe) so I'm not sure what > happens if the controller doesn't read it before it shuts down. This > is probably a bug if it isn't handled properly. Does the

Re: [computer-go] On Don Dailey's first chess program

Don Dailey wrote: > A few years later I was pointed to a site where I could download that > and just about any commercial chess program.We are talking several > decades ago, I didn't bookmark the site or use it myself and I have no > idea if it's still there. It seems to me that only a very s

[computer-go] Transpositions in Monte-carlo tree search

How are transpositions normally handled in monte-carlo tree search? I have been assuming that the natural thing would be to have a single shared node for each board position, so that simulations which reach the same position will use the same set of statistics (but when backing up the result, to o

Re: [computer-go] Transpositions in Monte-carlo tree search

Jonas Kahn wrote: > You might be interested by this article, for a very complete and tested > answer. Plus the idea of grouping, but a good part of the effect seems > to me to be giving a heuristic pre-value to moves, which might be done more > efficiently otherwise: > > eprints.pascal-network.org/

Re: [computer-go] Transpositions in Monte-carlo tree search

Erik van der Werf wrote: > >> Jonas Kahn wrote: >> No there is no danger. That's the whole point of weighting with N_{s,a}. >> >> N_{s,a} = number of times the node s has been visited, starting with parent >> a. >> >> You can write Value of a node a = (\sum_{s \in sons} N_{s,a} V_s) / (\sum >> N_{s

Re: [computer-go] Fuego technical report

Martin Mueller wrote: > Our technical report describing the Fuego framework is now available on > http://www.cs.ualberta.ca/research/techreports/2009/TR09-08.php > > I will probably make at least one more revision, so all feedback and > suggestions are welcome. On page 2, the report says | The re

Re: [computer-go] Implications of a CPU vs Memory trend on MCTS

Michael Williams wrote: > I want to correct that last statement. With about 350M nodes currently > in the tree (~30M of which fit into memory), I am averaging 0.06 disk > reads per tree traversal. What makes the nodes so big? -M- ___ computer-go mailin

Re: [computer-go] Implications of a CPU vs Memory trend on MCTS

David Fotland wrote: > Are you not using rave? If you keep rave counters for each legal move in > the node it should be much bigger than this. If you don't start keeping RAVE stats until the node is expanded, it need only cost two more integers per node (or perhaps a bit more if there is some con

Re: [computer-go] Ko in light playouts

Ivan Dubois wrote: > It has been discussed already on this list. The common approach is to not > even bother to try detect ko in playouts. In case of infinite game (very > rare but happens) you can just put a threshold on the number of moves and > igore the result. Of course you have to detect ko i

Re: [computer-go] Re: Dynamic komi in commercial programs

Don Dailey wrote: > You just hit the nail on the head. Dynamic komi does not encourage a > program to overplay the position. Since you are starting from a losing > position you HAVE to overplay a bit. You have to attack when it is > futile. > Dynamic komi just makes the program happy with less. Th

Re: [computer-go] Re: Dynamic komi in commercial programs

Benjamin Teuber wrote: > I would like to know what exact experiments with "virtual komi" have > been made and why thay failed. In particular, it would be interesting to know what board sizes people have tried it with. -M- ___ computer-go mailing list co

Re: [computer-go] Re: Dynamic komi in commercial programs

Don Dailey wrote: > I did try this myself but I don't have any data to show what I did.What > I remember is that it's incredibly tricky - how do you actually know when > and how much to adjust? If the score starts getting really low or really > high, do you restart the search with a new kom

Re: [computer-go] Basic question concerning the edges of the board

David Doshay wrote: > My personal opinion is that way too much effort is put into > optimizations that used to be very important when memory was small, > but now is nice but not really needed. My bias is that efficiency is a > good thing as long as it does not get in the way of easily > understanda

Re: [computer-go] Double/Triple Ko situation

Brian Sheppard wrote: > I analyzed the following position as a win for O, but there are > two or three kos involved (A1/A2, H1/G1, and the bent four at J9), > so I am wondering if there are any other opinions. > > 1 2 3 4 5 6 7 8 9 > A X - X X - X X X - > B O X X O X - X O O > C - O O O X X O O O

Re: [computer-go] Dynamic komi at high handicaps

Don Dailey wrote: > The problem with MCTS programs is that they like to consolidate. You > set the komi and thereby give them a goal and they very quickly make > moves which commit to that specific goal. How did you form this opinion? Can you show an example game record (on 19x19) showing this beh

Re: [computer-go] Dynamic komi at high handicaps

Don Dailey wrote: > Matthew Woodcraft wrote: > > Don Dailey wrote: > > > The problem with MCTS programs is that they like to consolidate. You > > > set the komi and thereby give them a goal and they very quickly make > > > moves which commit to that specific

Re: [computer-go] Is RAVE weighting biased?

Łukasz Lew wrote: > If the weight in RAVE formula is near 1 in one child of tree and near > 0 in other then you basically compare RAVE value to regular average > value, which might be comparing apples to oranges. Yes, and this can cause problems in practice. There's been some discussion of this be

Re: [computer-go] Is RAVE weighting biased?

Łukasz Lew wrote: >>> If the weight in RAVE formula is near 1 in one child of tree and near >>> 0 in other then you basically compare RAVE value to regular average >>> value, which might be comparing apples to oranges. >> >> Yes, and this can cause problems in practice. There's been some >> discuss

[computer-go] Parameter Tuning by the Cross-Entropy Method

I've just been reading the paper /Parameter Tuning by the Cross-Entropy Method/ from Guillaume Chaslot et al. Unless I'm missing it, the paper doesn't say what step size (their 'alpha') they used in the experiments with Mango. Has anyone here tried this technique? What step size did you use? -M-

Re: [computer-go] Optimizing combinations of flags

Brian Sheppard wrote: > I think that I am assuming only that the objective function is convex. The > parameters in Go programs are always inter-dependent. What do you do when you add a new parameter? Do you retain your existing 'history', considering each game to have been played with the value of

Re: [computer-go] Re: Hahn system tournament and MC bots. and KGS tournament ?

Alain Baeckeroot wrote: > If i understand what D.Hillis said, it can put in light some hidden > aspects of the bots, and should be more spectacular than the > wise-sure-win style of MC *Go* bots. > And i guess it does not require lot of change in the code, "only" > points instead of win/loss in th

Re: [computer-go] Optimizing combinations of flags

steve uurtamo wrote: > the way to do all of this exactly is with experimental design. > > to design experiments correctly that handle inter-term interactions of > moderate degree, this tool is quite useful: > > http://www2.research.att.com/~njas/gosset/index.html That doesn't seem to directly supp

Re: [computer-go] Optimizing combinations of flags

Don Dailey wrote: > Matthew Woodcraft wrote: >> That doesn't seem to directly support deriving information from >> random trials. For computer go tuning, would you play multiple games >> with each parameter set in order to get a meaningful figure? That >> seems

Re: [computer-go] The global search myth

Don Dailey wrote: > Back then the ELO curve was not understood. The basic formula was > eventually found that 1 ply added 250 ELO rating points to a program. [...] > At some point, some incredibly foolish programmers at Northwestern > University built a program and decided that it was too hard to

Re: [computer-go] A thought about Bot-server communications

Don Dailey wrote: > Ok, let's get into semantics. Is superko an illegal move? Is it > simply forbidden or is it part of the rules that you lose immediately if > you play it? In card games that is called an irregularity and there > are separate rules to deal with these. > > If you make som

Re: [computer-go] Python bindings for libego?

Heikki Levanto wrote: > I was thinking that it could be quicker to do prototyping in something > like python, while having fast low-level functions in C. Since we > already have Lukasz Lew's ego library, I wonder if anyone has written > a wrapper around it to call it from python (or ruby, perl, or

Re: [computer-go] Python bindings for libego?

Darren Cook wrote: > I wonder if you had anything to say on how the development was? I'm > especially interested if you think if there was some aspect of the way > libego is written that made it either hard work for you, or made it > inefficient to wrap? I don't think so, beyond being written in C

Re: [computer-go] Fwd: [gnugo-devel] (GNU) Open source real time Go server

Giudici Raphaël wrote: > I contacted the FSF to talk about the possible creation of an open > source real time Go server backed up by the FSF. According to John > Sullivan, they are interested by such project and advised me to get in > touch with your team. Perhaps using the GGZ Gaming Zone (