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 (http://www.ggzgamingzone.org/) would be a good way forward. I've never played there myself, and I'm not sure whether or not it's currently a lively place. But if it is, then this might be a solution for both the running a server is a lot of admin effort and the people want friends to chat with, not just opponents to play problems. Their web site implies that there is some Go support already, but that it needs work. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 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 likely to be less efficient than treating it as a bandit problem. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 the new parameter set to zero? If you have 50 parameters already, doesn't adding a new parameter create a rather large number of new parameter sets, most of which there will never be time to investigate? I have been using UCB and UCT to tune engine settings, but I don't think these methods work well to tune more than a handful of parameters at the same time. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 the evaluation function should do the trick. In principle it's not difficult to change from tracking win/loss counts to tracking average score + number of games. But I think it's quite common to express 'knowledge' by using rules like if such-and-such a pattern matches, add 10 RAVE wins to the node; it's not so obvious how to modify these rules for a Hahn engine. (I suppose working out a good approach to this might suggest ideas which could be used in standard engines: for example, it might turn out that rules like the one above are weighting the knowledge too low/high in positions where the engine is already doing well/badly.) -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[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- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 before. Can you give me a link or date? I think it was in the big RAVE threads in February 2008. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 before. In positions where the RAVE values tend to be too high, the effect is that moves with few visits will be favoured, which will then equalise the RAVE weight again. The effect is rather like temporarily increasing the exploration coefficient, and nothing very bad happens. But in positions where the RAVE values are too low (which mostly means positions where the current player is winning), the effect is worse: the program will be reluctant to explore different moves, and this time there is positive feedback (the RAVE weights will diverge) and so the situation won't correct itself. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 behaviour? -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 goal. How did you form this opinion? Can you show an example game record (on 19x19) showing this behaviour? Your kidding, right?Does anyone honestly dispute this? I believe it to be false, yes. There are plenty of records of 19x19 MCTS computer games available. I haven't seen one in which the computer very quickly committed to anything, and I don't believe you have either. I suggest your view of computer go may be distorted by too much concentration on 9x9. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 D O O X - X O O O - E X O - X X X O - O F - O X X O O O O X G - O X O O O O X X H O X X O O X X X - J - X X X O X - - - O to play If komi is 7.5, it looks like a simple win for White. White will win if the main fight turns seki, without trying to kill the bottom right. Black has no ko threats and White already has an eye on the left, so seki seems inevitable. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 understandable code, particularly for a new engine. I am not debating (and do not want to start a flame war on the subject) that good data structures lead to good programs, but I think that trying to wring every last bit out of the stored data is silly when machines these days have up to 8 GB of RAM. I don't particularly disagree with what you write, but it's worth remembering that on a modern processor you might well find yourself with 32k of level 1 cache shared between two threads, so it's worth keeping an eye on the size of the main board structure. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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. That is NOT a good algorithm for winning against fallible opponents when you are behind. It's NOT a natural algorithm and I don't believe it's what humans do either. It is how I was taught to play when giving a handicap: don't overplay, let your opponent make their own mistakes. This is partly because handicap games are traditionally supposed to be teaching games: you're aiming to set a good example, not to win at all costs. But I've also found that avoiding conscious overplays in handicap games is a good winning strategy. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 komi?If you restart then you have wasted effort. [...] The dynamic komi adjustment, from my recollection was more promising, but still played worse. So what board sizes were you working with? -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 in the tree search part though. I found that even with ultra-light playouts, checking for simple ko cost only about 1% in speed. So I think programs might as well include it. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 reference MCTS implementation by Dailey [6] provides a very useful | starting point, but is far from a competitive system. But reference [6] is to a description of a non-tree-search program. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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,a})
where V_s is ideally the «true» value of node s.
In UCT2, they use V_s = Q_{s,a} the win average of simulations going
through a, and then through s.
In UCT3, they use V_s = Q_s the win average of all simulations through
s.
There is a danger. The problem is that the selection policy also
implements the soft-max like behavior that ensures convergence to the
minimax result. If the you backup to all possible parents, including
those for which the child would have been an inferior choice, you may
get into trouble.
That's what I was worried about.
But I think it's ok the way Jonas describes above: you don't add
anything to the false-parent node's simulation count, and you don't
change the weight of the false-child in its value; you just change the
evaluation of the false-child.
(This means that the effect of backing up to alternate parents will be
smaller than the effect of backing up to the 'true' parent, which is
presumably part of the reason why this variant is less attractive.)
-M-
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
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/archive/4571/01/8057.pdf
Thank you (and to the others who replied).
The idea of backing a simulation's results up to all parents ('UCT3' in
that paper) seems very dangerous to me! It's a shame they didn't have
any Go results to show for that one.
-M-
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
[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 only update the nodes for the simulation actually played). But I see in some of the Mogo papers that some of the contributions to the heuristic value of a node depend on the position of the previous move. So do MCTS programs not recognise transpositions at all? Or are the heuristics from the time when the node was first created allowed to stand, no matter what the simulation route is next time? -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 small number of people would have been in a position to download anything, several decades ago. What kind of 'site' was it, anyway? Doubtless not a web site! -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 process wait until the pipe is read before shutting down?It seems like I remember reading that you are supposed to try to read from the pipe before shutting it down. If this is a Unix pipe, the kernel will buffer what you write, so you can safely shut down before it's been read. If you try to write more than the kernel is willing to buffer, the write call won't return until enough has been read. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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: BLACK WINS/GAMES PERCENTAGE - - C3 D4 C4 D3 C20 out of6 = 0.000 percent C3 D4 C4 D3 C51 out of4 =25.000 percent C3 D4 C4 D3 D2 103 out of 428 =24.065 percent C3 D4 C4 D3 D5 82 out of 339 =24.189 percent C3 D4 C4 D3 E30 out of4 = 0.000 percent C3 D4 C4 D3 E40 out of2 = 0.000 percent C3 D4 C4 D3 E50 out of1 = 0.000 percent In this sequence, the only statistically interesting moves are D2 and D5 for black, because these 2 choice constitute the vast majority of the games. (It might be slightly more interesting if other moves showed black doing well, but in the minor lines of play black is losing.) The 2 good moves appear to be approximately equal in value ... however, let's check that out. They ought to be equal in value, because they're equivalent moves under reflection. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 archives of (the predecessors of) this mailing list from the mid-90s, and my impression is very different. I'd say the optimists were predicting 1 dan (AGA) in 10 years, and the pessimists were saying rather longer. This quote from a prominent list member in 1996 is not untypical: I'm not saying that you can get to shodan just by taking today's programs and running them on a machine 100 times faster. I'm saying that a 100 times faster machine is needed to run the new algorithms that will be developed for a shodan strength program. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 can be changed. I'm really very weak on networking so I'm not sure what I'm actually reading or whether this fix needs to be applied on the server end or the client end. Any ideas is this is relevant? That page is talking about long-obsolete software, but yes, it seems very likely that this is the basic issue. Most home 'internet routers' and many firewalls do network address translation, and will fail to maintain a connection after some amount of idle time. Trying to reconfigure the firewalls to have a longer timeout is probably a waste of effort. I think arranging for either the CGOS server or the client to send some boring message every few minutes will be the most practical solution. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 century away. Where did you get that impression? You don't have to go back to the archives, I'll give you something that you can find on the web right now that retains the old fashion thinking. But first ... I don't know what I was thinking when I said optimists felt it was 100 years away. That certainly wouldn't make them optimists would it? In fact that is how pessimists felt. I was probably typing this very quickly and not proof-reading it before I sent it. I easily found an article on the web that has the feel of the type of pessimism I'm talking about. The author of this page sets up a straw man, shoots it down, and indirectly implicates any approach that uses look-ahead. Then in the final Future Directions of Research no type of global search is even mentioned so the page is essentially out of date. Certainly that page is out of date; clearly it was written before the monte-carlo programs raised their heads. But it really doesn't contain the kind of pessimism you described at all. In 'future directions' it explicitly contemplates that a very strong Go program will appear in the future. It doesn't say anything one way or another about how long we could expect it to take. Of course hind-sight is 20/20. I don't fault people for making faulty prognostications. I'm just trying to make the point that as a whole we have been pretty short-sighted in thinking that global search of any kind was out of the question. I'm entirely unconvinced that go programmers did rule out 'global search of any kind', as opposed to 'global search of the kind used in Chess programs'. That article says that the 'tried-and-true techniques applied to solving chess' won't work with go. But by that it explicitly means 'alpha-beta plus evaluation function', not 'any type of global search'. Well, as far as we know now the author was entirely right. The article goes on to describe how the current top programs are made up of heuristics and specialised programs, which also was doubtless entirely true when it was written. It doesn't say that the 'very strong Go program of the future' is expected to be written like this. They don't list 'different kinds of global search' in their future directions, but they don't say anything to disparage the idea either. And in any case, the question we're talking about is how long people expected it to take before we would see a dan-strength program, not what techniques they expected it to use. I think it's rather dangerous to make wild claims, especially if you are perceived as an expert in that area. I agree entirely. Which is why I questioned your statement about how people were thinking in the 1990s. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 rating system. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 dead. Doesn't B3 kill in response to C1? -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 the nakade problem? And if you start including self-atari you weaken the program in general? I think the self-atari moves are only part of the story. With MogoRelease3, a lot of its life and death errors appear to happen when an approach move is required before the capture can happen, particularly when one player has to go back and make a solid connection on the first line before it can remove one of its opponent's liberties. I guess it isn't considering these moves (which can be thought of as filling a false eye). This can happen even when there is no capturing race involved. Certainly in some positions when Mogo has a game-losing dead group but thinks it's ahead, making such a solid connection can be the trigger for it to realise what's going on and resign. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[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 obviously dead. If I try MogoRelease3 playing as Black on position 2, it shows a 20% score and resigns either immediately or after a couple of moves. If I try it on position 1, it shows a score of 70%+ for Black, and continues to play until White takes steps to remove the dead groups from the board. I've tested with up to 2^24 playouts. I have tried increasing --collectorLimitTreeSize and --limitTreeSize (like bigMogo in the scalability study), but I can't set them much higher than the default on this machine without running out of memory. I'd be interested to see if someone with a bigger computer can find out what resources it needs to judge this position well, and to see how other engines do. Position 1 (;GM[1]FF[4] CA[UTF-8] SZ[13] HA[0] KM[0.5] AB[jb:kb][cb:cc][kc][bd:cd][jd:ld][be][he][cf:df][bg][gb:gh] [ig:ih][jh:kh][eg:ei][li][aj:bj][hi:hj][lk][al][ck:cl][ji:jl] [dm][im] AW[ia:ja][ib][hc:jc][db:dd][hd:id][ce:de][ie][ke:le][bf][hf:jf] [lf][jg:kg][mg][lh][ai:di][gi][mi][cj][ej:gj][ij][dk:fk][hk:ik] [dl][il][bm][fl:fm][hm] ) Position 2 (;GM[1]FF[4] CA[UTF-8] SZ[13] HA[0] KM[0.5] AB[jb:mb][cb:cc][kc][bd:cd][jd:md][be][he][cf:df][bg][gb:gh] [ig:ih][jh:kh][eg:ei][li][aj:bj][hi:hj][bk:ck][lk][al][cl] [ji:jl][im] AW[ia:la][ib][hc:jc][mc][db:dd][hd:id][ce:de][ie][ke:le][bf] [hf:jf][lf][jg:kg][mg][lh][ai:di][gi][mi][cj][ej:gj][ij][dk:fk] [hk:ik][dl][fl][il][bm:cm][em:fm][hm] ) -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 to do it in order to beat the program. It turns out not to be difficult at all. When it has a killable group, Mogo actively cooperates to bring about these situations, because it thinks it has found a way to live. I have killed more groups in bent-4 in a few evenings of playing mogo at 13x13 than I have otherwise in the last ten years. Most MC programs won't just let you pick off points because that is normally a strategy that decreases your winning chances. They will only do that if every move leads to the same win or loss in every single play-out, or if the small win turns out to be easier to manage. If you watch mogo playing on KGS, you will see that when it ahead it does consistently let its opponent 'pick off points' until the game becomes very close. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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. Remember that there's good reason to believe that this technique will be less helpful in self-play. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 excels at reducing clear winning positions to close games they | lose because of botched up tsumego Is it mogo botching up the tsumego or its opponents? Do you have any example game records for this? -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 games. I see people getting excited about this idea as if it's the holy grail of computer go I do wish you wouldn't say such silly things. Nobody here has said anything of the sort. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 confident in yose and see you are only little behind, you frequently don't start overplaying hopelessly, but instead still play the best you can and hope for an overturn in yose. That's right. This isn't just a theoretical case: it happens in practice when I play the publicly available mogo on 9x9. If I reach an endgame position where it thinks it's unlikely to win, it goes into self-destruct mode and loses. But it is better than me at the 9x9 endgame, and if it were to lower its sights and wait for me to go wrong it could win (I can verify this after the end of the game by going back to an earlier position and fiddling the komi). One way to think of this is that the computer's opponent model has broken down (ie, its effective assumption that it's playing against another instance of mogo). This also suggests that trying to investigate such a rule using self-play is unlikely to work well. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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, switch back to normal evaluation, else resign. I experimented with something similar a while ago, using the publicly available mogo and manipulating komi between moves. If its win probability fell below a certain threshold (and the move number wasn't too high), I told it to play on the assumption that it would receive a few points more komi (and similarly when the win probability became high). This did seem to make it stronger vs gnugo on 13x13, but I didn't investigate thoroughly. I hope that techniques like this will be able to avoid the situation where the computer starts playing very risky moves when it judges it is only a little behind (which can be foolish if the opponent is likely to make plenty of mistakes of its own). They could also help a computer make better use of handicap stones. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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++ in the first place. C++ code is harder to wrap than C code just because C++ interfaces are that much richer, and because Pyrex isn't really designed for C++. (Well, there was one thing: I didn't find a nice way to wrap the functions that use iostreams in their interfaces. But that's not very interesting, because those are the text-manipulation bits that you wouldn't write in C++ if you were making a hybrid program). A lot of the inefficiency comes because I was aiming for a Python extension with pretty much the same interface as libego. For real work it would be better to start with the attitude let's make a decent Python extension for working with go boards, and use libego to build it. I suppose you'd have functions for looping over each point in the board, for example, which would avoid constructing a silly Python Vertex object for each point. A real hybrid program would be more efficient again, because you could have C++ code implementing exactly what the interpreted code happens to need, and you could do away with the expectation that you shouldn't be able to crash the Python interpreter by passing bad parameters to an extension module. I still suspect that Python would be too slow to use for anything that happens as frequently as once per playout. In notes.txt you say the speed dropped from 70-75 kpps to 43 kpps when used in the wrapper (compared to 1 or 2.5 kpps in native python). And you say this is due to the overhead of converting and checking parameters? If you increase the number of playouts by a factor of 10 does it close in to 70kpps? That drop happens because the Python code for running the benchmark itself is slower than the C++ code for doing so. That is, (I think) we lose so much speed because each iteration of the Python code in this loop for i in xrange(playout_count): working_board = start_board.copy() playout = Playout_cls(working_board, first_player) status = runner(playout) if status == pyego.PLAYOUT_OK: wins[working_board.winner()] += 1 elif status == pyego.PLAYOUT_MERCY: wins[working_board.approx_winner()] += 1 takes similar time to the single 9x9 libego playout that it runs. Increasing the number of playouts doesn't change things. But if I try it on a 19x19 board the penalty is rather lower, because the C++ code takes more time. I wondered if it might be possible that some compiler optimization got missed, or is just not possible, when built as an extension? The drop from ~75 to ~70 kpps is because of poorer compiler output when building as an extension (that is: I changed 'always_inline' to plain 'inline' everywhere to get the extension to compile; I presume it would be possible to put always_inline back and have separate entry points for the Python code marked plain 'inline', and I should think this would regain that 7%). -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 some other scripting language). I have done a Python binding for the current libego. You can get it from http://mjw.woodcraft.me.uk/2007/pyego/ . I did this as an exercise in using Pyrex (in fact, I ended up using a variant called Cython) to wrap a C++ library. I'm not planning to use it myself, and I'm not particularly planning to update it for future releases of libego. -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 do selectivity. They kept noticing that when they threw out moves, they would accidentally throw out good moves because a lot of terrible looking moves are actually good moves. So in their ignorance they build a program that didn't throw out moves and decided to live with the consequences - a program that couldn't look very far ahead and thus would be totally incapable of long term planning. [...] The big surprise was that this program dominated computer chess for a period of time - until everyone got wise to their foolishness and started copying them. Thus was born the age of brute force chess. [...] The best programs in the world HAD to have good evaluation functions (which deflates another myth - that chess programs are nothing more than a very simplistic evaluation function thrown together with a few terms and that all the effort is in the search.) But the best programs had to have very good searches too. Can you elaborate on the relation between the 'ELO curve' and the improved evaluation functions? Is it that if you took this original 'brute force' program and ran it on current hardware, it would gain 250 rating points per ply, and the improved evaluation functions allow modern programs to do even better than this? -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
