Re: [Computer-go] Breakthrough: FineArt giving handicap against pro players
Ke Jie sacrificed himself to help the Nihon Kiin get off its high horse. :-) Congrats on your own results. > > ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Project Leela Zero
Is this something LeelaZero might consider using? https://arxiv.org/pdf/1803.05407.pdf The last diagram is looking very impressive. It's not a game playing domain, but still. Maybe this averaging technique could help reduce the gap for a (relatively) low resource project like Leela. On Wed, Jan 10, 2018 at 12:28 AM, uurtamo . wrote: > 4dan? > > On Jan 9, 2018 3:26 PM, "mic" wrote: > >> Thank you very much. >> >> It will play on DGS as LeelaZero19 (without GPU support). I will start >> this night with an unrated test game against FuegoBot, one minute thinking >> time each. Then I will give it a rank, so it can get stronger by the time. >> >> Leela 0.11.0 (on DGS as LeelaBot19) has meanwhile reached a weak 4 dan >> rank, also without GPU support. >> >> -Michael. >> >> --- >> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. >> https://www.avast.com/antivirus >> >> ___ >> Computer-go mailing list >> Computer-go@computer-go.org >> http://computer-go.org/mailman/listinfo/computer-go > > > ___ > Computer-go mailing list > Computer-go@computer-go.org > http://computer-go.org/mailman/listinfo/computer-go > ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [computer-go] Re: verifiable claims
Almost any strategy other than playing out all legal moves involves a lot of hand waving that is unlikely to be accepted as a proof. There are just too many cases where a pitch inside a captured space has global effects. Completely solving small goboards seems like a strange quest to me. Certainly there is no hope of scaling this upwards, so what's the point? When nine men's morris was solved, I thought this was interesting, but tiny go boards just don't make my blood boil. But what I do find interesting about this, is the question of terminating playouts. This is relevant for large boards also. And somehow I don't ever see comments anywhere suggesting that this could be a problem. So what I'd like to know is: is this so trivial that no one ever mentions it, or are the heuristics that programs use to terminate playouts so obscure that they are too embarrasing to mention? Stefan Kaitschick ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MCTS, 19x19, hitting a wall?
Permutating through liberties in a semiai seems especially painful from a human perspective. And doing so in multiple fights, without separating them somehow, is ofcourse much more painful still. Maybe someone will find a way of destilling the concept of leading or trailing a semiai out of the MC tree. Stefan Part of the problem is that we're using global search to play a game with lots of local little fights. If we have say five little fights, and each takes say 11 ply to play well, it means a >50 ply global search just to avoid local blunders. Currently, we try to sidestep this fundamental problem by replacing local search with local knowledge, such as patterns. But that does not fully use the power of search. Martin ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Scoring - step function or sigmoid function?
It seems to be surprisingly difficult to outperform the step function when it comes to mc scoring. I know that many surprises await the mc adventurer, but completely discarding the final margin of victory just can't be optimal. The sigmoid function can be tinkered with ofcourse, by making its slopes steeper and/or by awarding bonus points for victory. But if it looks like the step function in the end, then computational resources could have been saved by just using the step function from the start. The power of the step function is that it directly awards what we are really interested in - victory. And an mc program, holding on to a half point victory in the endgame, is a thing of beauty and terror. But in the opening, where the scoring leaves are 300 moves away from the root, surely a putative half point win doesn't translate to a significant advantage, where as a 100 point win would. My suggestion is this: how about backing up the individual outcomes through the tree and then do the evaluation at the intermediate nodes, using the sigmoid function and the parameters depending on the distance from the root? This might be too expensive computationaly, but shortcuts could be devised. For example, wins could be sorted into a couple of different categories( from half point win to landslide), and those categories could be evaluated differently, depending on the distance to the root. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Scoring - step function or sigmoid function?
My conclusion was that the winning percentage is more than just an estimate of how likely the player is to win. It is in fact a crude estimator of the final score. Going back to your original comment, when choosing between move A that leads to a 0.5pt win, and move B that leads to a 100pt win, you should be seeing move B has a higher winning percentage. Darren Good point. Wins will occur in clusters, so win-rate and score go hand in hand. MC algorithms seem to be treacherous ground when it comes to anticipating consequences. Here's another shot: MC bots play handicap games poorly. When they take w they go into maniac mode because they can't find any wins. When they take b they dither around until the game gets close. What is entirely missing are the concepts of catching up or of preserving a lead. So my suggestion would be to pretend that there is a komi that almost compensates the handicap. A numerical example: a 4 stone handicap is worth about 45 points. Start with a "virtual komi" of about 35 points, and decrease that value to 0 during the course of the game. This works in both directions. If the bot has w he will be pessimistic, but not suicidal. If he has b he will be optimistic, but not so lazy. The rate of "giving rope" should depend on the number of moves played and on the winning percentage. If the winning percentage drops early, reduce the virtual komi more sharply. One advantage of this approach would be that it wouldn't tinker with even game stategies. A more elaborate scheme would be to make several preliminary searches at different komi levels. The goal would not be to find the best move. The search would only try to find the win rate for the komi. Depending on how far the game progressed, giving a virtual komi will be worth some win rate reduction. (Or taking a virtual komi will increase the winrate, making the bot play less maniacal than playing a string of kothreats in an unfavorable position. After a decision on the komi is reached, a search is done for this komi to find the move to be played. Towards the end of the game the virtual komi must allways be 0. This strategy might even be useful for even games, when the winrate strongly favors one side before the late endgame. That would revert to the handicap game situation.(Except that a disparity of strength is not presumed) Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Scoring - step function or sigmoid function?
Thinking about why... In a given board position moves can be grouped into sets: the set of correct moves, the set of 1pt mistakes, 2pt mistakes, etc. Let's assume each side has roughly the same number of moves each in each of these groupings. If black is winning by 0.5pt with perfect play, then mistakes by each side balance out and we get a winning percentage of just over 50%. If he is winning by 1.5pt then he has breathing space and can make an extra mistake. Or in other words, at a certain move he can play any of the moves in the "correct moves" set, or any of the moves in the "1pt mistakes" set, and still win. So he wins more of the playouts. Say 55%. If he is winning by 2.5pts then he can make one 2pt mistakes or two 1pt mistakes (more than the opponent) and still win, so he wins more playouts, 60% perhaps. And so on. My conclusion was that the winning percentage is more than just an estimate of how likely the player is to win. It is in fact a crude estimator of the final score. Going back to your original comment, when choosing between move A that leads to a 0.5pt win, and move B that leads to a 100pt win, you should be seeing move B has a higher winning percentage. Darren Point well taken.Winning positions tend to cluster and critical swing moves are rare, statistically speaking. If the position is more or less evenly balanced, the step function might allready be very close to optimal because of this. But I would like to bring up a well known mc quirk: In handicap positions, or after one side scored a big success in an even game, bots play badly with both sides, until the position becomes closer again. The problem here is that every move is a win (or every move is a loss). On 9*9, its possible to beat a bot, giving it 2 stones, even when it's a close contest on even with komi. All it needs is a single bot missread at the moment the position becomes close(which it will, because the bot will be "lazy" until that point). So it would be desirable for the bot to make keeping the score advantage large an auxiliary goal. This has been tried ofcourse, but without much success sofar. And it seems that the main reason is that tinkering with the scoring function to achive this, tends to worsen play in competitive situations. I have an alternative suggestion: In handicap games, introduce a virtual komi, that gets reduced to 0 as the game progresses. This would work for the bot on both sides: If the bot has b it will make less lazy plays, if it has w, it will be less maniacal. For example, in a 4 stone 19*19 game, if the real starting advantage is about 45 points, the bot could introduce an internal komi of about 30-35. The bot should be optimistic with b and pessimistic with w, but not to the point that every move evaluates to the same value, and move selection becomes a toss-up. Another way to look at this, is that humans that give a handicap know that they can't usually catch up in one piece. And humans that take a handicap know that they can't give up their advantage too quickly. Virtual komi encodes this simple knowledge. During the course of the game this internal komi would ofcourse have to be reduced to 0. The proper criteria can only be found by experimentation, but the important factors will be how far the game has progressed, and what the win rate is for the best move. If the bot becomes pessimistic with b it should lower the internal komi more quickly. One advantage of this approach is that it doesn't mess up even game play. A more elaborate scheme would be to make a "komi search" before the real search - to find the best ratio of win rate to internal komi before making the normal move search with this komi. This could also be useful in even play after one side pulled ahead. Stefan ___ 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
- Original Message - From: "Dave Dyer" To: "computer-go" Sent: Saturday, July 11, 2009 10:54 PM Subject: [computer-go] Re: Dynamic komi in commercial programs If you are in a lost position, "good play" is play that maximizes the probability of a turnaround, which is quite different depending on how far behind you are, and for what reason. If the status of all the major groups is solid, then concentrating on tactics which can gain a few points reliably might be the right thing. On the other hand, if the status of some groups is less than immutable, then focusing on changing their status favorably might be correct. It's hard to see how shifting Komi will influence the style of play in this direction. Dynamic komi in a sense means that the bot is deluding itself on purpose. Obviously this is dangerous medicine, a kind of magic mushroom. So what could be worse than a deluded bot? I say, letting a monkey play could be worse. And monkeys' play is what you get from an mc bot when all possible moves come back with indistinguishably wonderful or terrible win rates. Adding a wishful (or pessimistic) komi will distort reality, but will help create bigger win rate differences between moves. It should be possible to assign costs to both dynamic komi and to insufficiently spreading win rates between moves. My hypothesis is, that with unstable groups on the board, the win-rate spread will tend to be larger then with stable groups. So with proper balancing, the bot should refuse to take dynamic komi when he sees a chance to win outright. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Mirror Go against Zen
Ofcourse they can know. They just have to check for it. Those programs that do well against mirror go probably all do check for it. What to do about it is a bigger problem. My suggestion would be to make an extra search that assumes mirror play by the opponent. This has to be taken with a grain of salt, because the opponent could deviate at any time. So what could be done is to add a small fraction of the mirror search winrates to the regular search win rates. Stefan - Original Message - From: Don Dailey To: computer-go Sent: Monday, July 20, 2009 4:01 PM Subject: Re: [computer-go] Re: Mirror Go against Zen Ok, so I am right about this, you take advantage of the asymmetry of captures. But go programs do not KNOW they are playing mirror go and would have no motivation to specifically set this up. So how is it that some equally strong programs have no problem while others do? - Don On Mon, Jul 20, 2009 at 9:48 AM, Seo Sanghyeon wrote: 2009/7/20 Don Dailey : > Again, I don't understand go so well, but how do you win against mirror > go? You setup two ladders that collide. -- Seo Sanghyeon ___ 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: Dynamic komi in commercial programs
I think the most promising field for using dynamic komi is in low handicap play. Because the main strategic principle for w in low handicap play is patience, which is easily and naturally modeled by a declining komi. For high handicaps the main strategic principle is light play, which is an elusive concept even for humans, and very difficult to even begin to implement. Light play is not the same as bean scattering. Maybe it will be possible to give greater weight to sparse shape patterns in high handicap go, but who knows? Stefan - Original Message - From: terry mcintyre To: computer-go Sent: Wednesday, July 15, 2009 12:29 AM Subject: Re: [computer-go] Re: Dynamic komi in commercial programs Maybe we should go back to the question which dynamic komi is an attempt to solve: how to obtain better discrimination when every move seems to be clustered near "I am so freaking dead" or "I am so far ahead", as the case may be. Terry McIntyre “We hang the petty thieves and appoint the great ones to public office.” -- Aesop -- ___ 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
What a bot does with its playouts in a handicap situation is to essentially try to beat itself, despite the handicap. And in this situation the bot reacts in a very human way, it becomes despondend. Adjusting the komi dynamically shifts the goal from winning to catching up quickly enough. I feel that that is the natural handicap strategy, not a band-aid. Ofcourse, the dynamic komi must be adjusted down to zero in good time. I think there are 2 main reasons that this hasnt been fully explored sofar. 1. Trying to maximize the score turned out to be a huge mistake, compared to trying to maximize the winrate. This makes dynamic komi a kind of blind spot. 2. Handicap go wasnt given special attention sofar. Stefan - Original Message - From: Don Dailey To: computer-go Sent: Wednesday, August 12, 2009 11:24 PM Subject: Re: [computer-go] Dynamic komi at high handicaps Terry, I understand the reasoning behind this, your thought experiment did not add anything to my understanding. And I agree that if the program is strong enough and the handicap is high enough this is probably better than doing nothing at all. However, I think there must be something that is more along the lines of treating the disease, not the symptoms.You might be able to put a band aid on the problem but you have not addressed the real issue in a systematic way. Besides, I have not yet seen anyone demonstrate that this works - it's always talked about but never implemented.It is made to sound so simple that you have to wonder where the implementation is and why the strong programs do not have it. - Don 2009/8/12 terry mcintyre Consider this thought experiment. You sit down at a board and your opponent has a 9-stone handicap. By any objective measure of the game, you should resign immediately. All your win-rate calculations report this hopeless state of affairs. Winrate gives you no objective basis to prefer one move or another. But, you think, what if I can make a small group? What if I try for a lesser goal, such as "don't lose by more than 90 points?" Your opponent has a 9 stone handicap because he makes more mistakes than you do. As the game progresses, those mistakes add up. You set your goal higher - losing by only 50 points; losing by only 10 points. The changing goal permits you to discriminate in a field which would otherwise look like a dark, desolate, win-less landscape. Terry McIntyre “We hang the petty thieves and appoint the great ones to public office.” -- Aesop From: Don Dailey To: computer-go Sent: Wednesday, August 12, 2009 1:05:36 PM Subject: Re: [computer-go] Dynamic komi at high handicaps Ok, I misunderstood his testing procedure. What he is doing is far more scientific than what I thought he was doing. There has got to be something better than this. What we need is a way to make the playouts more meaningful but not by artificially reducing our actual objective which is to win. For the high handicap games, shouldn't the goal be to maximize the score? Instead of adjusting komi why not just change the goal to win as much of the board as possible?This would be far more honest and reliable I would think and the program would not be forced to constantly waste effort on constantly changing goals. - Don On Wed, Aug 12, 2009 at 3:33 PM, Brian Sheppard wrote: >The small samples is probably the least of the problems with this. Do you >actually believe that you can play games against it and not be subjective in >your observations or how you play against it? These are computer-vs-computer games. Ingo is manually transferring moves between two computer opponents. The result does support Ingo's belief that dynamic Komi will help programs play high handicap games. Due to small sample size it isn't very strong evidence. But maybe it is enough to induce a programmer who actually plays in such games to create a more exhaustive test. ___ 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/___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/comput
Re: [computer-go] Dynamic komi at high handicaps
"You are giving the program an arbitrary short term goal which may, or may not be compatible with the long term goal of winning the game." Don, this is a very important consideration. How can an illusionary goal be better than the real goal? But I would argue that in the handicap situation, catching up quickly enough is actually the real goal. You write: "And as the base program gets stronger this aspect of the program becomes more and more of a wart." This I disagree with. Because no matter how strong the program will become, it will never find a way to defeat itself against a large handicap. This is effectively what a program tries to do with its playouts. The only reasonable alternative to trying to catch up quickly enough is to model the weaker players errors straight into the playouts, and try to find a direct win. But this seems more speculative to me than dynamic komi. Surely, it is also harder to implement well. Stefan - Original Message - From: Don Dailey To: computer-go Sent: Wednesday, August 12, 2009 11:11 PM Subject: Re: [computer-go] Dynamic komi at high handicaps 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. Commiting to less than you need to actually win will often involve sacrificing chances to win.Sometime it won't, but you cannot have a scalable algorithm which is this arbitrary. However, if the handicap is too high, the program thinks every line is a loss and it plays randomly. That's why we even consider doing this. Dynamically changing komi could be of some benefit in that situation if there is no alternative reasonable strategy, but it does not address the real problem - which is what I call the "committal consolidation" problem. You are giving the program an arbitrary short term goal which may, or may not be compatible with the long term goal of winning the game. Whether it's compatible or not is based on your own credulity - not anything predictible or that you can scale. And as the base program gets stronger this aspect of the program becomes more and more of a wart. If this can be made to work in the short term, it should be considered a temporary hack which should be fixed as soon as possible. We have to think about this anyway sooner or later because if programs continue to develop and the predictive ability of the playouts and tree search gets several hundred ELO better, these programs may start to see more and more positions as either dead won or dead lost. I'm sure we will want some kind of robust mechanism for dealing with this which is better at estimating chances that the opponent will go wrong as opposed to doing something that is a random benefit or hindrance. - Don 2009/8/12 terry mcintyre Ingo suggested something interesting - instead of changing the komi according to the move number, or some other fixed schedule, it varies according to the estimated winrate. It also, implicitly, depends on one's guess of the ability of the opponent. An interesting test would be to take an opponent known to be weaker, offer it a handicap, and tweak the dynamic komi per Ingo's suggestion. At what handicap does the ratio balance at 50:50? Can the number of handicap stones be increased with such an adaptive algorithm? Even better, play against a stronger opponent; can one increase the win rate versus strong opponents? The usual range of computer opponents is fairly narrow. None approach high-dan levels on 19x19 boards - yet. Terry McIntyre “We hang the petty thieves and appoint the great ones to public office.” -- Aesop From: Brian Sheppard To: computer-go@computer-go.org Sent: Wednesday, August 12, 2009 12:33:13 PM Subject: [computer-go] Dynamic komi at high handicaps >The small samples is probably the least of the problems with this. Do you >actually believe that you can play games against it and not be subjective in >your observations or how you play against it? These are computer-vs-computer games. Ingo is manually transferring moves between two computer opponents. The result does support Ingo's belief that dynamic Komi will help programs play high handicap games. Due to small sample size it isn't very strong evidence. But maybe it is enough to induce a programmer who actually plays in such games to create a more exhaustive test. ___ 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.c
Re: [computer-go] Dynamic komi at high handicaps
"What seems difficult to me however is to devise a reasonable way to decrease this komi as the game progresses" Certainly that is the main problem. But the main considerations are not so hard to find 1. Win rate of the best move. 2. How far has the game progressed 3. deviation between the win rates of all possible moves.( with higher deviation dynamic komi is less called for) Stefan - Original Message - From: "Mark Boon" To: "computer-go" Sent: Wednesday, August 12, 2009 11:36 PM Subject: Re: [computer-go] Dynamic komi at high handicaps I started to write something on this subject a while ago but it got caught up in other things I had to do. When humans play a (high) handicap game, they don't estimate a high winning percentage for the weaker player. They'll consider it to be more or less 50-50. So to adjust the komi at the beginning of the game such that the winning percentage becomes 50% seems a very reasonable idea to me. This is what humans do too, they'll assume the stronger player will be able to catch up a certain number of points to overcome the handicap. What seems difficult to me however is to devise a reasonable way to decrease this komi as the game progresses. In an actual game the stronger player catches up in leaps and bounds, not smoothly. In MC things are not always intuitive though. 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] Dynamic komi at high handicaps
"For instance I am sure he will not sit merrily by and watch his opponent consolidate a won game just so that he can have a "respectable" but losing score.Dynamic komi of course does not address that at all." This seems self evident, but it may actually be a treacherous conclusion. Dynamic komi really only has one legitimate use. To avoid flat lining or, taking handicap, saturated win rates. This doesnt mean that the program needs to be "satisfied" with losing.(A komi that put the win rate to 50% would model that) A win rate range between 35 and 45 percent might make the program locally ambitious, without attempting the impossible with ko threat type moves. Stefan - Original Message - From: Don Dailey To: computer-go Sent: Thursday, August 13, 2009 12:10 AM Subject: Re: [computer-go] Dynamic komi at high handicaps On Wed, Aug 12, 2009 at 5:58 PM, Mark Boon wrote: 2009/8/12 Don Dailey : > > I disagree about this being what humans do. They do not set a fake komi > and then try to win only by that much. I didn't say that humans do that. I said they consider their chance 50-50. For an MC program to consider its chances to be 50-50 you'd have to up the komi. There's a difference. If the handicap is fair, their chance is about 50/50. However, rigging komi to give the same chance is NOT what humans do. The only thing you said that I consider correct is that humans estimate their chances to be about 50/50. One thing humans do is to set short term goals and I think dynamic komi is an attempt to do that - but it's a misguided attempt because you are setting the WRONG short term goal. The human will have a much more specific goal that is going to be compatible with his hope of winning the game.For instance I am sure he will not sit merrily by and watch his opponent consolidate a won game just so that he can have a "respectable" but losing score.Dynamic komi of course does not address that at all. > > I think their model is somewhat incremental, trying to win a bit at a time > but I'm quite convinced that they won't just let the opponent consolidate > like MCTS does. With dynamic komi the program will STILL just try to > consolidate and not care about what his opponent does. But strong players > will know that letting your opponent consolidate is not going to work. So > they will keep things complicated and challenge their weaker opponents > everywhere that is important. > It's difficult to make hard claims about this. I don't agree at all that the stronger player constantly needs to keep things complicated. Personally I tend to play solidly when giving a handicap. Because most damage is self-inflicted. You can either make a guess what the weaker player doesn't know, or you can give him the initiative and he'll show you. I prefer the latter approach. When done properly, I don't see how an MCTS program would consolidate all the time. Doing so would keep the position stable while the komi declines. As soon as he gets behind the komi degradation curve play will automatically get more dynamic in an attempt to catch up. The problem is: we're speculating. The proof is in the pudding. Agreed. - Don 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] Dynamic komi at high handicaps
Maybe I should ask first, for clarity sake, is MCTS performance in handicap games currently a problem? Mark Yes, it's a big problem. And thats not a matter of opinion. MC bots, leading a game by a large margin, will give away their advantage lighly except for the last half point. Even on a 9*9 board, even if the bot wins more games on even with 7.5 komi, that doesn't mean that it's impossible for the human to win, giving a 2 stone handicap. All it needs is a single bot missjudgement after the game got close. Granted, bots are really excellent at defending the last half point advantage tooth and claw. I'm just saying that it should be impossible for the human to win on 2 stones, and it isn't. If they are behind by a large margin they will play either random or ko threat type moves. So there is a kind of symmetry here. Beeing too far ahead or behind ruins the bots plays. The biggest practical problem right now is poor play against pros on a 19*19 board, taking a large handicap. Special fuseki patterns are only a patch. When, after a decent opening, the regular patterns take over, they usually immediately start to work against the bots own previous moves. Looking into the horses mouth, instead of invoking Aristotle, is really the only way to find out. I had hoped that programmers would find the idea interesting enough to try it out. Instead, I found myself in a hand waving contest. Granted, I started it, so I can't complain. Thanks to Ingo for simulating dynamic komi by hand to give programmers something less speculative. Btw, I played 2 games (as gogonuts) on KGS against goIngo(really ManyFaces). I won both on 5 stones. But in the first one, with komi adjusted by Ingo, I had to make a very critical invasion that should not really have worked. In the second game I won without problems. At the time, Ingo adjusted the win rate for w to 50%. Since then, with his limited trials, Ingo found out that adjusting the komi to give each side a 50% win rate isn't optimal. His current rule is to adjust to 42% for w. This is ofcourse only a crude start, but sophistication can only be introduced by programmers. Stefan ___ 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
Modeling the opponents mistakes is indeed an alternative to introducing komi. But it would have to be a lot more exact than simply rolling the dice or skipping a move here and there. Successful opponent modeling would implement the overplay school of thought - playing tactically refutable combinations that are beyond the opponents skill to punish them. Introducing komi at the 50% win rate level would implement the honte school of thought - play as if against yourself. At a win rate of less than 50% it implements the "almost honte" school of thought. :-) I'm not trying to moralize. In love and go anything is fair. I'm just saying that while both approaches are legitimate, adjusting the komi is much easier to do. Different subject, suggestion for a komi adjustment scheme: 1. Make a regular evaluation(no extra komi) 2. If the win rate of the best move is within certain bounds you're done (Say between 30 and 70 percent.Just a guess ofcourse.Also, this might shift as the game progresses) 3. If not, make a komi adjustment dependant on how far out of bounds the win rate is. (No numerical suggestion here. Please experiment.) 4. Make a new search with this komi. 5. If the new result is "in bounds" calculate winrate_nokomi * factor + winrate_komi for each candidate and choose the highest one. (factor around 10 maybe) 6. If not, go back to 3 The idea is to choose a move that doesnt contradict the long term goal(no komi search) while trying for a short term goal(komi search) if no long term goal is available.( Or if every move satisfies the long term goal in case of taking handicap) Stefan - Original Message - From: Don Dailey To: tapani.ra...@tkk.fi ; computer-go Sent: Thursday, August 13, 2009 4:02 PM Subject: Re: [computer-go] Dynamic komi at high handicaps This idea makes much more sense to me than adjusting komi does.At least it's an attempt at opponent modeling, which is the actual problem that should be addressed. Whether it will actually work is something that could be tested. Another similar idea is not to pass but to play some percentage of random moves - which probably would work in programs with strong playout strategies. Of course this would be meaningless for bots that have weak (and already random) playout strategies. - Don On Thu, Aug 13, 2009 at 6:17 AM, Tapani Raiko wrote: I don't think the komi should be adjusted. Instead: Wouldn't random passing by black during the playouts model black making mistakes much more accurately? The number of random passes should be adjusted such that the playouts are close to 50/50. Adjusting the komi would make black play greedily, while random passing during playouts would make black play safe (rich men don't pick fights). Tapani Raiko Christoph Birk wrote: > > I think you got it the wrong way round. > Without dynamic komi (in high ha > ndicap games) even trillions of simulations > with _not_ find a move that creates a winning line, because the is none, > if the opponet has the same strength as you. > WHITE has to assume that BLACK will make mistakes, otherwise there > would be no handicap. > > Christoph > ___ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ > > -- Tapani Raiko, , +358 50 5225750 http://www.iki.fi/raiko/ ___ 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] MoGo - ManyFaces
13 games were played and the total score was 8-5 for CzechBot. I wonder how would they play if on even grounds. The general game pattern was the usual wild middlegame wrestling typical of MC, with CzechBot usually getting large edge initially (70% winning probability and seemingly unshakeable position), but then in the lost games making a careless blunder or two when it got too much ahead, and panicking subsequently. Overlooking ladders seemed to happen to it several times. So maybe CzechBot should put a komi burden on itself when it gets too optimistic. Stefan ___ 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
One last rumination on dynamic komi: The main objection against introducing dynamic komi is that it ignores the true goal of winning by half a point. The power of the win/loss step function as scoring function underscores the validity of this critique. And yet, the current behaviour of mc bots, when either leading or trailing by a large margin, resembles random play. The simple reason for this is that either every move is a win or every move is a loss. So from the perspective of securing a win, every move is as good as any other move. Humans know how to handle these situations. They try to catch up from behind, or try to play safely while defending enough of a winning margin. For a bot, there are some numerical clues when it is missbehaving. When the calculated win rate is either very high or low and many move candidates have almost identical win rates, the bot is in coin toss country. A simple rule would be this: define a minimum value that has to separate the win rate of the 2 best move candidates. Do a "normal" search without komi. If the minimum difference is not reached, do a new a new search with some komi, but only allow the moves within the minimum value range from the best candidate. Repeat this with progressively higher komi until the two best candidates are sufficiently separated.(Or until the win rate is in a defined middle region) There can be some traps here, a group of moves can all accomplish the same critical goal. But I'm sure this can be handled. The main idea is to look for a less ambitious gloal when the true goal cannot be reached. (Or a more ambitious goal when it is allready satisfied). By only allowing moves that are in a statistical tie in the 0 komi search, it can be assured that short term gain doesn't compromise the long term goal. Stefan___ 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
Good work Ingo. But why should it be near 50%? If it is, the komi is too large.(if giving handicap) You just have to reserve some thinking time for reruns, in case the komi estimate from the last move doesn't fit anymore. Stefan (ii) Also on 13x13 board dynamic komi seems to help, although the "consolidation problem" (bot becomes to conservative when too near at 50 % for wrong komi levels) is more serious there. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] two won semiais = lost game?
I have a general question: how good are the current information gathering mechanisms in the mc tree to insure that advantagous semiais are actually won? Random playouts will surely give the side with more libs the advantage, but to what degree? Lets say the leading side wins the semiai in 2/3 of all playouts. This seems comfortable. But except for turnarounds through ko, the leading side should allways win the semiai. What if one side has 2 winning semiais on the board, with winning both needed to win the game? If both have a 2/3 chance of winning in playouts they combine to 4/9 - a losing evaluation for a won game. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] two won semiais = lost game?
It is obvious that the current mechanism is bad. And another problem on the wrong evaluation is the amplification of the error. When there are unresolved life/death or semeais on the board, typical MC programs become weak because of the instability of the simulations. I think that we need a new algorithm to combine the UCT information into the playout policy. I have already done a lot of experiments in this area, but not yet succeed. However I believe this idea will be the next breakthrough. -- Yamato Remember quiescence search in chess programing. There, captures are executed before the evaluation function is invoked. Maybe a kind of quiescence search is needed here too. In the case of go, semiais could be played out(allways trading an equivalent number of moves locally), before the actual search for a move begins. There are problems with this: finding the local battles, trading moves realistically, compensating for lost ko threats, attempting to playout a "hot" fight, ect. But getting rid of useless combinatorial explosions would be worth a lot. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] two won semiais = lost game?
Ah. A "single path to victory" bottleneck. That makes it even worse than I thought. This is probably also the problem when mc bots judge an invadable to be safe. Stefan One problem is approach moves. Say W has a group with 3 liberties, but they must be played in order (perhaps one is an eye, and one needs an approach move). B has a group with 5 liberties, but they are all equivalent and can be filled in any order. W has only one random move that wins the semeai. B has 5 random moves that improve its chance to win the semeai. Most playouts will end with B winning this semeai even though W is one move ahead. The other problem is local patterns. Often a 3x3 pattern will cause one side to fill its own liberty. David ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] (two won semiais = lost game?) semiais - expulsion from mc paradise
The basic mc paradigm is refusing to differentiate structures for the purpose evaluation - ontological bliss if you will. But semiais are now throwing go programers out of paradise. They must be found and evaluated (The semiais, not the programers) So maybe the first question to answer is what would constitute a solved semiai. Maybe it will take separate tactical analysers, but a formulation within the mc framework would be preferable. In Davids example below, with B winning although W is ahead because the W moves must be in order, the first step would be to identify the B moves as belonging together in a group.(hard enough) This information could then be used to somehow nullify the B permutation advantage through the playout policy. A fully solved semiai would be an ordered list of groups of moves for both sides, with group members being permutable. Good luck with this. Stefan - Original Message - From: "David Fotland" To: "'computer-go'" Sent: Monday, September 07, 2009 6:18 PM Subject: RE: [computer-go] two won semiais = lost game? The playouts often give the side with fewer liberties the advantage in a semeai. This causes a large fraction of Many Faces' lost games to strong players on KGS. One problem is approach moves. Say W has a group with 3 liberties, but they must be played in order (perhaps one is an eye, and one needs an approach move). B has a group with 5 liberties, but they are all equivalent and can be filled in any order. W has only one random move that wins the semeai. B has 5 random moves that improve its chance to win the semeai. Most playouts will end with B winning this semeai even though W is one move ahead. The other problem is local patterns. Often a 3x3 pattern will cause one side to fill its own liberty. David -Original Message- From: computer-go-boun...@computer-go.org [mailto:computer-go- boun...@computer-go.org] On Behalf Of Stefan Kaitschick Sent: Monday, September 07, 2009 2:36 AM To: computer-go Subject: [computer-go] two won semiais = lost game? I have a general question: how good are the current information gathering mechanisms in the mc tree to insure that advantagous semiais are actually won? Random playouts will surely give the side with more libs the advantage, but to what degree? Lets say the leading side wins the semiai in 2/3 of all playouts. This seems comfortable. But except for turnarounds through ko, the leading side should allways win the semiai. What if one side has 2 winning semiais on the board, with winning both needed to win the game? If both have a 2/3 chance of winning in playouts they combine to 4/9 - a losing evaluation for a won game. Stefan ___ 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/
[computer-go] string criticality?
Rémi Coulom offers a formula for the "criticality" of point x. ("Criticality: a Monte-Carlo Heuristic for Go Programs") Criticality being a measure of how important holding x is for winning. c(x) = v(x)/N - (w(x)/N * W/N + b(x)/N * B/N) N: number of playouts W/B: playouts won by white/black w(x)/b(x): playouts where x is owned by white/black v(x): playouts where x is owned by playout winner I'm prepared to believe that this formula is a meaningful measure of covariance. The way I understand it, moves with a high criticality value are given a better chance of being tried. Seems logical to me. I just wonder if something similiar couldn't also be used to identify the importance of strings allready played. There would be 2 levels of criticality: 1. How important is the string for winning the game? 2. How important are points in the vicinity for attacking/defending this string? (possibly with ordering information) I'm not sure if the above formula should be used or if it should be something asymmetric. Unlike point criticality there is a preestablished owner for a string. There will be a tendency that losing a string will be more harmful for the defender than not capturing will be for the attacker. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] string criticality?
Few months ago I tested it without success. String criticality seems a nice idea, but how should it be implemented? Just giving high priority to the liberties does not work, because that cannot be distinguished from the simple dame-filling. Can you suggest a concrete formula? -- Yamato a shot in the dark: 1. How important is the string for winning the game? Using Rémi Couloms' formula c(s) = v(s)/N - (w(s)/N * W/N + b(s)/N * B/N) N: number of playouts W/B: playouts won by white/black w(s)/b(s): playouts where s is owned by white/black v(s): playouts where s is owned by playout winner 2. How important are points for winning the string? In a semiai situation there are no critical points(ignoring eye making/destroying) Each side has its own valuable points, playing the opponents move is usually catastrophic. This should actually make it easier to find these points. They should be as good for one side as they are bad for the other. (Or worse, consider making your own large eye smaller) something like this(a little Bayes): P(C|X) = P(X|C) * P(C) / P(X) P(C|X): chance that the string will be captured if x is played by any side P(C): string_captured_count / N P(X): x_not_empty_count / N P(X|C): x_not_empty_when_string_captured / string_captured_count value 0: perfect defense value 1: perfect offense The moves of one side can be dependant on each other because they might have to be played in a certain order. This interdependence could be quite expensive/difficult to find. But ignoring it will indeed reduce string criticality to normal dame filling. So my suggestion is this: completely order the moves for both sides. This way interdependencies don't have to be explicitly analysed. A move that needs to be played earlier should get a higher rating naturally. The trick would be to allways impose this order, even if it doesn't actually exist. If the criticality of a string is high, it would try to suppress these moves in any other order. My hope is that this would alleviate an "unfair" permutation advantage by the losing side. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] string criticality?
Maybe it would be good enough to only update the string criticality first. More expensive calculations for the found critical strings could kick in later. You asked for a formula, and I tried to comply, but its really only conceptual. Also there will still be points that are good for both, taking a liberty or extending by 2 liberties for example. The central idea would be to discourage permutations of dame-filling moves. The ordering criterea might not have to be so precise. Stefan - Original Message - From: "Yamato" To: "computer-go" Sent: Monday, September 14, 2009 5:08 PM Subject: Re: [computer-go] string criticality? Stefan Kaitschick wrote: something like this(a little Bayes): P(C|X) = P(X|C) * P(C) / P(X) P(C|X): chance that the string will be captured if x is played by any side P(C): string_captured_count / N P(X): x_not_empty_count / N P(X|C): x_not_empty_when_string_captured / string_captured_count value 0: perfect defense value 1: perfect offense Well, it should work theoretically but seems very expensive for the processor. When we have this information, do we have to update every node value for every string every time? -- Yamato ___ 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] Stone-Age
Stone-Age - spooky concept :-) I suppose it has some relationship to generally lighter playouts deeper in the tree. Have you experimented some more with this? Perhaps the cutoff point should be somewhere in the future though, moving towards the present as the game progesses. Otherwise you completely disable patterns for the first move, which doesn't seem right. Stefan I feel ungrateful for saying this, but a search in the archive would be great. - Original Message - From: "Mark Boon" To: "computer-go" Sent: Monday, September 14, 2009 8:49 PM Subject: Re: [computer-go] string criticality? Maybe from a different angle, but maybe you remember me writing about 'stone-age'. Basically what it did was assuming strings created during the playout are less critical than existing strings. I used this to limit my tactical search by a great deal by not doing any search on 'new' strings. This didn't affect strength in any way I could measure, but it reduced the overhead of tactics ( I don't remember exactly, but I think it cut in half). I think the single most useful information about strings or groups would be whether it has two eyes. Unfortunately I haven't been able to think of a cost-effective way to compute that yet :) 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] Stone-Age
My mistake. I misstook "start of the playout" for the board position. Stefan - Original Message - From: "Mark Boon" To: "computer-go" Sent: Monday, September 14, 2009 11:42 PM Subject: Re: [computer-go] Stone-Age On Mon, Sep 14, 2009 at 10:55 AM, Stefan Kaitschick wrote: Stone-Age - spooky concept :-) I suppose it has some relationship to generally lighter playouts deeper in the tree. Have you experimented some more with this? No, I didn't have time to explore this further. Perhaps the cutoff point should be somewhere in the future though, moving towards the present as the game progesses. Otherwise you completely disable patterns for the first move, which doesn't seem right. I'm not sure. I used as cut-off the start of the playout, which being partly down the tree by a few moves (at least) seems to work fine. My main 'requirement' was that it didn't lose strength with equal number of playouts. Since that requirement was met I didn't look any further. I'd be surprised if pushing it further out into the future would actually *gain* strength, whereas it would certainly lose speed. Stefan I feel ungrateful for saying this, but a search in the archive would be great. You mean you don't keep your mail? My post about this was on Feb 2nd. GMail is your friend ;-) 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] Re: Congratulations to MoGoTW!
wow. great report. Thanks. Stefan - Original Message - From: "Hideki Kato" To: "computer-go" Sent: Tuesday, September 22, 2009 3:45 AM Subject: [computer-go] Re: Congratulations to MoGoTW! Nick Wedd: : Congratulations to MoGoTW, winner of yesterday's KGS bot tournament. My report is at http://www.weddslist.com/kgs/past/51/index.html. It is longer than usual - perhaps because I found this event, with a very strong entry and a fast format, particularly interesting. As usual, I am sure there are errors, and I look forward to receiving your corrections. Thank you for the tournament, Nick. It's quite interesting and exciting with many strong programs. Correction: In the picture of round 14 (bottom left of the page), it's not White turn but Black. Hideki -- g...@nue.ci.i.u-tokyo.ac.jp (Kato) ___ 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] Generalizing RAVE
It is exactly the same as my thought. I also have tried CRAVE, but the results were worse than normal RAVE. While RAVE is a very efficient algorithm, it strongly limits scalability of the program. It typically makes a fatal mistake in the position that the order of moves are important. We definitely need to improve RAVE, but it is a very tough job. -- Yamato I have a question about RAVE: it seems a little strange to me that all outcomes below the current position are just added up. Positions further down the tree are less similiar to the current position than those further up. So shouldn't there be some kind of attenuation factor from level to level? About the move order problem: I'm skeptical about finding an efficient full board algorithm that detects the consequences of move order. There is so much random noise, that finding a needle in a haystack seems inviting by comparison. Imo, move order will somehow have to be linked to the satisfaction of subgoals, i.e. defending/killing strings/groups. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Generalizing RAVE
Stefan Kaitschick wrote: About the move order problem: I'm skeptical about finding an efficient full board algorithm that detects the consequences of move order. In this context, "the order of moves" does not mean a long sequence. It means something like "If I already played A, B is preferable for me. otherwise it is not." -- Yamato I have David Fotlands' comments in mind: The playouts often give the side with fewer liberties the advantage in a semeai. This causes a large fraction of Many Faces' lost games to strong players on KGS. One problem is approach moves. Say W has a group with 3 liberties, but they must be played in order (perhaps one is an eye, and one needs an approach move). B has a group with 5 liberties, but they are all equivalent and can be filled in any order. W has only one random move that wins the semeai. B has 5 random moves that improve its chance to win the semeai. Most playouts will end with B winning this semeai even though W is one move ahead. The other problem is local patterns. Often a 3x3 pattern will cause one side to fill its own liberty. David There are two distinct problems here. One is that because of a permutation advantage for the "losing" side, the correct answer is never found. A similiar problem probably exists for corner invasions: because the invading side has to play more precisely than the defending side, the corner is incorrectly evaluated as safe. I don't have an inkling what could be done about this. The other problem is probably a little more tractable: a semeai that should be won safely by one side is unstable in the evaluation. Is a move at A more successful if B has allready been played by the same side? If very much so, they may be part of a set of moves required to win a semeai. And if this relationship is asymmetrical then one needs to be played before the other. The problem with this is that the costs are very high. In the full board 19*19 case, instead of 1 value there would be 360 * 2 values for every possible move. One possibility would be to predefine a local area for every point and only distinguish for this area. Another way to go might be to only calculate string or point criticalities. If and when a threshhold is reached, define a local area dynamically and only then start to split up the results. Sorry for beeing a little wishy washy here. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Generalizing RAVE
MCTS, even though it walks to the end of the earth, has it's own horizon effect. The name is more fitting for depth-limited alpha-beta search ofcourse. It's a kind of procrastination. Finding a lot of useless things to do before admitting an undesirable, but unavoidable consequence. Even if a fight is important, there will usually exist interposable ko threat type moves. These will trigger am entirely new search on the same subject. And if there are n ko threats, there will be n! ways of trying them out. Also, these n! attempts can be interposed every 2 half moves by the side that is losing the fight. In some esoteric way, standard RAVE probably ameliorates this problem, or it wouldn't work as well as it does. Here's a suggestion to extend RAVE to better handle it: There are 20 points within keima distance of any point not close to the edge.(5*5 without the corners) When RAVE values are backed up, they are put into the category defined by the previous opponents move. (21 categories, 20 + other. All added up yield the normal RAVE value) This amounts to accumulating a killer heuristic for local points. It can used in 2 ways: 1. prefer the best local response 2. if there is a good local response for the opponent, penalize a candidate move This could be combined with a hash table for high level nodes to catch transpositions. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Generalizing RAVE
> Stefan Kaitschick wrote: > >Here's a suggestion to extend RAVE to better handle it: > >There are 20 points within keima distance of any point not close to the > >edge.(5*5 without the corners) > >When RAVE values are backed up, they are put into the category defined by > >the previous opponents move. > >(21 categories, 20 + other. All added up yield the normal RAVE value) > >This amounts to accumulating a killer heuristic for local points. > >It can used in 2 ways: > >1. prefer the best local response > >2. if there is a good local response for the opponent, penalize a candidate > >move > > I don't understand what it is useful for. I think that the near points > from the previous move are already preferred by proximity heuristics. > Could you give us an example? > > -- > Yamato I guess you are right that the proximity heuristic is very helpful in reducing the thrashing I described above. But it can't do everything. After failing locally, the move generator will at some point stumble over non-local ko threats. And these moves will immediately improve the win rate, in part by not beeing correctly answered and in part by moving the local focus away from the original problem. So refuting a non-local threat comes at a fairly high price. I don't see how this can be avoided. But once a successful answer is found it would be nice to rember it as a specific answer to the threat. Not only for answering a threat - the proximity heuristic can again do a large part of the work here. A ko threat will typically have a great win rate against all moves except one. That might give the move a decent RAVE value even after it has been refuted. But a non-local move against which a single strong refutation has been found, should be tried less often than if the win rates of attempted refutations were more balanced. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Generalizing RAVE
Here's a suggestion to extend RAVE to better handle it: There are 20 points within keima distance of any point not close to the edge.(5*5 without the corners) When RAVE values are backed up, they are put into the category defined by the previous opponents move. (21 categories, 20 + other. All added up yield the normal RAVE value) One more thought. I think the proximity heuristic should actually make this more effective, not less. Because many moves are close to the last one, the uninformative "other" category gets less hits. And an ordering of the close points in order of previous effectiveness should help guide the search more effectively. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] public test suite
Every now and then somebody submits an interesting 9*9 problem, usually rendered in X and O. Wouldn't it be great to have a public suite, lets say a directory with "black to play and win" sgf problems. For quick testing there should be only one correct first move. There could also be subdirectories for problem types. Maybe CGOS could be expanded to send bots through the test batch. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Pattern matching
Very Cool. The mysterious part was "more interesting than programming go". That seemed almost impossible. Stefan - Original Message - From: "Mark Boon" To: "computer-go" Sent: Wednesday, October 14, 2009 11:23 PM Subject: Re: [computer-go] Pattern matching On Sat, Oct 10, 2009 at 5:32 PM, Álvaro Begué wrote: Are you not going to tell us what this new job is about? I almost forgot to answer this, I had no intention to sound mysterious. My job is to make autonomous avatars (also called NPCs or 'bots') for a new MMO platform called Blue Mars. The immediate goal is to make them more interesting, intelligent and interactive than the zombie bots currently populating such worlds. That is a pretty easy target. The ultimate goal is to make them actually seem intelligent and indistinguishable from real players or even replace a real player when he/she is not online. I've been given a practically free hand in how I think this is accomplished best. I've only just started laying the groundwork, but already there are some results that people are excited about. So far so good. 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] First ever win of a computer against a pro 9P asblack (game of Go, 9x9).
c) There was one non-blitz game (45 minutes per side). MoGo was unlucky as it was black, but it nonetheless won the game. This game is enclosed. All games can be found on KGS (account nutngo) Congratulations. b) MoGo already won a game as black, against Catalin Taranu, but I guess the pro, at that time, had played an original opening somehow for fun (I'm not sure of that, however). c) My feeling is that blitz games are not favorable to computers... Statistics are in accordance with this I guess. Humans are stronger for short time settings. I just can't believe the general statement that computers scale better than humans on time. Tripling the number of playouts surely won't do much for the program. So if it's supposed to help, it means that the extra time will do practically nothing(or worse) for the human. I'm willing to concede, that that might have exactly been the case. The pro had allready won the shorter games and was probably inflicted by the same momentary imbalance as Catalin. That's actually very human. The bots have to earn their respect. Also, in serious future showdowns, there will have to be regenerative pauses between the games. Stefan___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MC hard positions for MCTS
I would add invasions. This is especially obvious when the position cries for a san-san invasion. Nakade may be a part of it. But the biggest problem is that the path to life/ko is very narrow. The defender has many useful moves and the invader has few. So MCTS will falsely judge invadable areas to be safe. Stefan - Original Message - From: Petri Pitkanen To: computer-go Sent: Tuesday, October 27, 2009 11:05 AM Subject: [computer-go] MC hard positions for MCTS Hello, Are there more peculiar situation that will cause problems for MCTS apart from the three I know. 1. Nakade (this is partuially solved in most of the programs) 2. Semeais 3. Double Ko. Last one was new to me. See http://files.gokgs.com/games/2009/10/26/ManyFaces-Hyoga.sgf In that game manyfaces wastes ko-threats in hopeless ko in lower left corner. And wins game by human weakness of pushing with stones taht are short of liberties. Is there any nice way to solve this or shouldd all of these solved in expanding the node using "classical" go-AI-engine. Petri -- Petri Pitkänen e-mail: petri.t.pitka...@gmail.com -- ___ 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] MC hard positions for MCTS
But, has anyone gathered stats on positions, from real games, that require precise play by the defender/attacker/both/neither? Is defending really easier than attacking? Darren Who is the defender? One side is defending his territory, the other side is defending his group. I think the general bias is towards overestimating the chance of killing. Thats what makes MCTS programs such an aggressive lot :-) Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MC hard positions for MCTS
This causes what I call the "horizon effect" which prevents the tree exploration to work properly - the moment the tree finds a sequence that unbiases the simulations, it is horrified by the bad results [*] and switches to a different branch, until it finds the same; thus, the bot pushes the resolution (unbiasing) of the situation over the tree horizon for as long as possible. This shows in actual games as the bot playing random throwins and obviously pass moves before resigning. I don't know how much hidden ongoing research is being done about dealing with the bias in the tree, the only result so far I'm aware of is Remi Coulom's criticality heuristic, and it wasn't that effective; I personally have some clear ideas I want to start experimenting with as soon as possible - I think we need a top-down counterpart for the bottom-up propagation function of RAVE. IMHO a substantial progress in this direction is the next big thing to happen in computer go. Petr "Pasky" Baudis I like the criticality heuristic. It certainly points to an important problem. One trick might be to identify "hot spots" with something akin to criticality and then penalize jumping between them. Because permutating moves between separate important areas is exactly what leads to the consequence evading horizon effect. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] First ever win of a computer against a pro 9P asblack (game of Go, 9x9).
29, turning into a won ko, really is a great way to play. It would be interesting to know if MoGo perceived itself to be on the home stretch here. So it would be great to have the bots win rate estimations as sgf comments. Stefan - Original Message - From: Olivier Teytaud To: computer-go Sent: Tuesday, October 27, 2009 5:38 PM Subject: [computer-go] First ever win of a computer against a pro 9P asblack (game of Go, 9x9). Dear all, some comments by my Taiwanese colleagues about the game played by MoGo against the 9p pro: 1) mogoTW finally ran on the 16*8 system on Oct. 26, 2009. 2) Contributors for which I did not know their real name: "Hsien-Der Huang" and "Cheng-Wei Chou" (sorry for them!) 3) Some comments by the pro, translated by people from Taiwan: === He told the jounalists that he made a mistake on move 26, which is a move that it is hard to find such kind an error (move 26) even for a professional Go player. However, he was so surprised that MoGoTW found this mistake that he made during the game. That means the level of MoGoTW in 9x9 game has made an improvement than last time (08/2009). In addition, he also told the journalists that MoGoTW made a good move at Move 29. He thought that the main reason that MoGoTW won the game was Move 29 and MoGoTW didn't make any mistake after Move 29. == -- ___ 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] Joseki Book
True, but at the moment we're just interested in getting Orego to play ANY joseki, i.e., a reasonable move in some corner, rather than a disastrous tenuki. Finding the "right" joseki will be future work. (Orego also has a small fuseki book, which we're working to expand.) On an intermediate level, a joseki that is good for a professional is not necessarily so good for a kyu player. Professionals are better than weak players at using thickness, whereas solid territory is worth much the same to both. So if your objective is for Orego to become 1-dan, you should tend to prefer josekis which give low solid territorial positions, leaving the hard-to-use outer influence for its opponents. Good advice! Peter Drake By playing/watching bots on kgs I've noticed a bot specific weakness in applying OB on 19*19. There is a consistency gap from OB to post-OB. And ironically it's worse for simple and safe joseki than for more extravagant, influence-oriented ones. When "pure" MCTS kicks in, the bot will go for what remains of center influence, trampling on his own low positions. Alleviating this problem is even more important than direction of play or than the local quality of the move. For example, MFoG likes to play keima boshi on a low hoshi kakari, even when it doesn't have any extensions. This is a wise choice, considering current post-OB play. One day, when MCTS becomes more refined, bots will stop overestimating the value of influence. But until then, it is better to use an OB that puts the bot in a position that it likes, than in a position that is "objectively" good. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Joseki Book
Ofcourse I can't say what a "correct" opening is. What I can say though, is that if bots are onto something with their strange openings, at this point it's by accident. They really do underestimate the chances of an invader. That goes for moyo "parachute" invasions as well as corner invasions. I think that's because the likelyhood of randomly playing killing moves is greater than the chance of randomly playing shinogi moves. Disproving the initial hypothesis about such an invasion is an unsolved task. David Fotland made a similar comment about semeais that are incorrectly evaluated because the losing side can play its moves in any order while the winning side cannot. Stefan - Original Message - From: "Robert Jasiek" To: "computer-go" Sent: Tuesday, November 10, 2009 2:52 PM Subject: Re: [computer-go] Re: Joseki Book > Ingo Althöfer wrote: > > So, do you believe that the human problem of overestimating early > > territory is more severe than the MCTS-bot problem of overestimating > > influence? > > Of course, I was exaggerating as much as Stefan:) The truth is: We > simply don't know the perfect play's degree of territory vs. influence > balance. > > One thing is clear though: Traditional opening theory "ends" on the 4th > line. Not because that line would be the end of the world but because > traditional go theory is ignorant about trying to evaluate higher stones > in comparison to lower stones well. > > Needless to say, I have always been happy that MC programs have been > ("accidentally" of course) copying my opening style as Black:) IMO, > their 19x19 opening strength is at least 3d level. It might be higher > but I cannot prove or disprove it. They tend to play a bit more > unrelated stones that those in my games. > > > PS: Can you give us a comment on Fuego's influence-oriented Joseki's > > in the KGS bot tournament on Sunday ? > > I am not sure which game that is; please send it to me / the list as SGF > inline or attachment. Or do you mean all games of Fuego played on 11-08? > > -- > 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: [SPAM] Re: [computer-go] First ever win of a computer against apro 9P as black (game of Go, 9x9).
MCTS avoids evaluation. That is its main trick. It also avoids subproblems like the plague. Atleast sofar. I think you are absolutely right that in the end a program will need to be able to define subproblems, their local status, and the conditions that will change that status. The current switching behavior, that results when more than one critical area exists, can only be described as thrashing. Computing power alone will not solve this. But local results don't stay local. And a winning move is often a winning move because it influences several critcal areas at the same time, effectively merging them. How to apply divide and conquer to the protean and holistic game of go will remain a headache for a long time. Stefan This may be useful in computer Go. One of the reasons human pros do well is that they compute certain sub-problems once, and don't repeat the effort until something important changes. They know in an instant that certain positions are live or dead or seki; they know when a move ( reducing a liberty, for example ) disturbs that result. This could probably be emulated with theorem-proving ability. Presently, search algorithms have to rediscover these results many times over; this is (in my opinion) why computer programs get significantly weaker when starved for time; they cannot think deeply enough to solve problems which may be solved in an eyeblink by a pro. Terry McIntyre terrymcint...@yahoo.com___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Joseki Book
Ofcourse I can't say what a "correct" opening is. What I can say though, is that if bots are onto something with their strange openings, at this point it's by accident. It is not by accident, it is consistent with what the bot can read. What I mean is that it may well be legitimate to play "strange" looking opening moves at the highest level. But that the current generation of bots is so biased by certain blind spots that it is impossible to tell at this point if their "style" stems in part from global evaluation or solely from their biases. You are right ofcourse that this reflects their reading, but that reading will be seriously off when one side sytematically has a better chance of guessing good moves than the other.(With "side" I don't mean human vs. bot but invader vs defender) They really do underestimate the chances of an invader. Maybe it is obvious for a player stronger than the bot, but i am 1 stone weaker than zen19 and i have hard time to beat it, even if i know it will play cosmic style. And i find it is very strong at sacrifying something to go back to its beloved center Yes. Zen would not be 1-2d on kgs if it couldn't hold it's own against opponents that allready knew what it was up to. That goes for moyo "parachute" invasions as well as corner invasions. I think that's because the likelyhood of randomly playing killing moves is greater than the chance of randomly playing shinogi moves. Disproving the initial hypothesis about such an invasion is an unsolved task. David Fotland made a similar comment about semeais that are incorrectly evaluated because the losing side can play its moves in any order while the winning side cannot. I have the same problem during my games against humans :) It seems 1d bots have more or less the same problems as 'cosmic 1d' players. Alain. I don't quite agree here. For example, a human 1d is much better than zen at judging 3-3 invasions. Zen has serious deficits in judging the prospects of an invasion in a fairly unstructured area.(compared to humans, not to other bots) Otoh, there are areas were Zen is clearly superior to most human 1ds. It is surprisingly good at hand to hand fighting. And it's exagerated optimism when it comes to killing groups has left many opponents stunned in disbelief when Zen actually killed an almost impregnable group. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Go Programming Language
Has anyone tried programming Go in the "Go" Programming Language? http://golang.org/ And the result would be a gogo? hurray! go gogo! ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Joseki Book
> Characterising the style quickly, it can start the first few moves at almost any intersections 3rd line and above ... Ignorants call the early moves "random" but it is only because they lack an understanding of their reasoning ... The first statement is a pretty good definition of random. Can't resist a flame war here :-) Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Joseki Book
I admit that I was narrowly parsing words. I do like your "bermuda triangle" :-) Stefan - Original Message - From: "Robert Jasiek" To: "computer-go" Sent: Wednesday, November 11, 2009 2:57 PM Subject: Re: [computer-go] Re: Joseki Book Stefan Kaitschick wrote: almost any intersections 3rd line and above ... The first statement is a pretty good definition of random. In contrast to random play, nobi, kosumi (except in the corner), empty triangles and the like must be avoided and the opposing stones' position should be taken into account as well. Furthermore the generation of the moves creates a difference from random because it is (or should be) embedded in a context of reasoning, planning or (MC programs) statistics. -- 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] Hahn system tournament and MC bots
If scoring matters, then instead of just estimating the winrate for a certain move, a bot has to estimate a komi/winrate function. As a shortcut, maybe a simoid scoring function will suddenly start to shine. But that really folds winrate and winning score into a single dimension. If that is too much of a simplification only testing can tell. For humans it just means don't resign, don't try anything too funny to catch up, and don't take it too easy in a winning position. Put even more shortly it means "don't bother counting" for humans, which is ironic because for bots it means exactly the opposite. Stefan - Original Message - From: Don Dailey To: computer-go Sent: Monday, November 23, 2009 1:22 AM Subject: Re: [computer-go] Hahn system tournament and MC bots I'm pretty sure that this simplification of the rules would favor computers. Of course that would require some program modifications, primarily counting points on the board instead of wins and losses. These rules basically takes out some (or at least reduces) elements of the game that humans are better at, such as knowing how to judge risk, knowing when to go for it, etc. Go is still way too complex for computers to process well so any simplification like this is going to help computers. - Don On Sun, Nov 22, 2009 at 6:23 PM, Alain Baeckeroot wrote: A Go tounrmaent with Hahn system has been retransmeted on kgs/eurogo TV With these rules, the actual count makes a difference (as opposed to just win/lose) Winning by >40.5gets 100 points ...... Losing by >40.5gets 0 point see http://senseis.xmp.net/?Bangneki http://www.suomigo.net/wiki/HahnSystem How current MCx bots can handle this kind of rules ? The traditional safe way would ensure 60 points, but trying crazy things (when losing) would cost a lot if the result ends by losing by resignation or -40.5 What is the impact for chosing the best move ? (choose the greediest amongst several with highest winning rate ?) Alain. ___ 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] Re: Hahn system tournament and MC bots
No professional gambler, if he had the numbers laid out for him, would ever choose unoptimal play, not when he's playing for the long term. The computer, in the same way, would have to be modeled to maximize expected value. Nothing else makes sense. In a single game with high stakes, yes mindset (risk aversion, your finances, etc) might come into it. But that is exactly why I specified the long term scenario. -Jeff A professional gambler has a 2 step task. 1. Find a weaker player (aka "fish") 2. capture the fish('s bankroll) Luckily for the gambler, there is usually an adequate supply of fish. But capturing the fish is a bigger problem. Fish are shy and need to fed worms to make them feel comfortable. So step 2 is really a 3 step process: 2a. let the fish win at the relatively small starting stakes. 2b. Act angry and astounded, offer a raise of the stakes. Now start winning. 2c. The angry and astounded fish will offer another raise of the stakes if step 2b was artful enough. Now capture the fish. So the whole idea of "optimizing" the score it totally besides the point. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] KCC won the 3rd UEC Cup
Crazy Stone (CS) lost the first game due to a wrong ko setting. The opponent of CS played a superko violation which was legal under Japanese rules, and CS lost the game by a faul. The most devastating indictment against japanese rules I've seen so far. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] KCC won the 3rd UEC Cup
I guess your right. It's just that the "innocent" side losing on the spot rubs it in. Accepting any move surely has to be a "bot vs.bot" mode. Against a human opponent the bot can't very well accept suicide or immediate ko takeback. Stefan - Original Message - From: "Mark Boon" To: "computer-go" Sent: Monday, November 30, 2009 9:26 PM Subject: Re: [computer-go] KCC won the 3rd UEC Cup Well, I suppose this is a lesson that every computer-Go programmer learns one day or another: always have a way to accept any move, no matter whether your bot thinks it's legal or not. I don't see how this is an indictment, the rules are what they are. For every player. It's not as if this was a little-known issue with Japanese rules. Mark On Sun, Nov 29, 2009 at 10:57 PM, Stefan Kaitschick wrote: Crazy Stone (CS) lost the first game due to a wrong ko setting. The opponent of CS played a superko violation which was legal under Japanese rules, and CS lost the game by a faul. The most devastating indictment against japanese rules I've seen so far. Stefan ___ 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] Live broadcasting at UEC Cup
Another option would be double elimination. Drawbacks are that you first need to trim the field down to 16 contestants, and that it takes more rounds than single elimination. (aka ko) The advantage is that it retains the ko characteristic of "everybody still in it can win it" while lessening the impact of chance. Stefan - Original Message - From: "Rémi Coulom" To: "computer-go" Sent: Tuesday, December 01, 2009 9:47 PM Subject: Re: [computer-go] Live broadcasting at UEC Cup David Fotland wrote: I'd like to thank all of the people who organized the UEC tournament for providing machines and operators to allow Many Faces and others to participate. I'd like to suggest that the UEC organizers consider using a Swiss tournament system in the future since it gives a more accurate assessment of program strength. Regards, David Fotland Hi, I have just come back from Japan. I would like to also thank the UEC Cup organizers. I enjoyed the tournament very much, despite my stupid superko-setting mistake. Crazy Stone would probably have had no chance against KCC or Zen, anyways. I have really stopped working on Crazy Stone, so this version was almost identical to the version of last year. The only change is that I added more pattern shapes, which improves strength a little. I like the direct-elimination system, because it determines a clear winner in a deterministic number of rounds. I don't like the KGS system, where the winner is determined by SOS. I believe the direct-elimination system would work better without seeds. With seeds, very strong newcomers such as Zen or KCC this year, or Many Faces last year, risk meeting the winner of the previous year too early. I believe that without seeds, the pairings of the second day would have been much better. Also, playing in the first day allows to detect technical problems early. There would have been less problems with MoGo last year, had it played in the first day. And I would have liked to play in the first day too, rather than watch everybody have fun. Unlike human tournaments, computers don't get tired from playing so many games. Anyway, the organization of the UEC Cup is really great. I thank again the organizers and participants, in particular those who guided us around Tokyo on Monday. Bye, Rémi ___ 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] one more look at the scoring function
Looking at the games on kgs, both ManyFaces and Zen are pretty decent at giving handicap, but still fairly weak at taking handicap. I think the problem remains, that they allow the opponent to close the gap too easily. Once the game is close they get much stronger, but by then they are in a real danger of losing. I feel the problem is still with the scoring function. Watching them give away points with both hands, I have advocated a dynamic negative komi, thereby almost starting a flamewar on this list. So as not to start it again, let me state here that I now think that it's a remedy of dubious value, making the bots play more "positive" moves that look better, but might hurt the bots chances of winning by going head to head with a stronger opponent. Here's my new suggestion: how about trying to map the score to the chances of winning? In the later endgame, a putative 0.5 point win might be something like 90%, a putative 1.5 point win 95%. Early in the game that would be maybe 51% and 53%. I'm not sure of what the most useful numbers would be ofcourse, or how quickly they would change, or if there should be other factors than the move number. Stefan___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] problem which current programs have difficulty solving
I wouldn't consider not solving this pathological. I think it's a pretty difficult problem. Without a "problem warning" most amateur players would miss it too. You can't force life and you can't force connection. The either-or is easy to miss. Stefan - Original Message - From: terry mcintyre To: computer go Sent: Sunday, December 20, 2009 7:03 PM Subject: [computer-go] problem which current programs have difficulty solving This gem is from one of Yilun Yang's little pocket-sized books - I think it is called Recovery And Connections. Neither Gnugo, Fuego, nor Many Faces of Go is able to solve it. Fuego came closest, recognizing the best black move, but a few moves later, it lost interest and played elsewhere. GnuGo rejects the winning move as "unsafe". Btw, GoGui/Gnugo have a method to "find dragon status"; is there something comparable with Fuego/GoGui? Terry McIntyre “Politics should be limited in scope to war, protection of property, and the occasional precautionary beheading of a member of the ruling class.” P.J. O'Rourke -- ___ 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] Zen beats a 5-dan on KGS
Very nice. You just can't be cavalier tactically when you play a bot. Even though this was an even game, the human started playing "handicap style" after a few obviously weak bot moves. But the kind of tactical handicap play that w tried completely backfired against Zens strong tactical counterattacks. Before this, Zen won against 2-dans on even, and even won a game against a shodan, giving 3 stones. So it's not a fluke. Beating a 5-dan on even isn't Zens real current strength, but as we see, if the opponent is not used to bot play, it can allready happen. Congrats Zen. Stefan - Original Message - From: ""Ingo Althöfer"" <3-hirn-ver...@gmx.de> To: Sent: Saturday, January 02, 2010 1:30 PM Subject: [computer-go] Zen beats a 5-dan on KGS The old year 2009 ended with a true cracker onm KGS: In the computer room "Mosa", a Japanese player with rank 5-dan, had five games with Zen running on a mini-cluster (4x4 cernels). One of these games was won by Zen, at chinese rules, komi 7.5 and handicap 0. Zen was black in that game. Thinking time was 30 minutes sudden death. You can download all five games from here: http://www.gokgs.com/gameArchives.jsp?user=mosa&year=2009&month=12 Mosas rating curve on KGS is shown here: http://www.gokgs.com/graphPage.jsp?user=mosa Best wishes for 2010 to all of you! Ingo. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 13x13 human vs computer
9*9: 6 dan 19*19 :1 kyu 13*13 1 dan? not the expected interpolation :-) Looks like programing for a specific board size is important. Stefan - Original Message - From: "David Fotland" To: "'computer-go'" Sent: Monday, January 11, 2010 2:23 AM Subject: RE: [computer-go] 13x13 human vs computer On 13x13, Many Faces is probably 1 Dan on KGS. I don't know how that translates to German ranks, but probably 2 stones is fair, or 3 stones if you want the computer to likely win. David -Original Message- From: computer-go-boun...@computer-go.org [mailto:computer-go- boun...@computer-go.org] On Behalf Of "Ingo Althöfer" Sent: Sunday, January 10, 2010 11:17 AM To: computer-go@computer-go.org Subject: [computer-go] 13x13 human vs computer Hello, at a public event (during an exhibition on Claude Shannon; in Nixdorf museum in Paderborn) I want to arrange an exhibition game "human vs computer" go on 13x13 board. (Thinking time about 45 minutes for both sides.) Does someone here know about "human vs computer" games on 13x13? The human opponents will be around 3-dan or 2-dan (German amateur level). What would be an appropriate handicap when they play against, for instance, Many Faces of Go on a "standard" dual core notebook? Ingo. -- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02 ___ 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] Re: Open source real time Go server
>As for other things we'd like to see improved, we could build a list. My pet >peeve is the KGS "score estimator", which is often wildly wrong. I've heard >>complaints about the implementation of the rules, and some have argued that >it is not terribly bot-friendly. A good SE is a terribly difficult problem. It more or less amounts to creating a good evaluation function. As the long pre-MC misery has shown, a good evaluation function is very hard to come by. MC in a nutshell is really "avoid evaluation". If resources were no problem, the best way to estimate the score would probably be to have an MC program find the komi that results in a 50% winrate. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Open source real time Go server
2010/1/19 terry mcintyre : ( I recall a pro making such an observation; I was willing to accept his expertise on the matter. ) Any pro making such a comment at move 10 is just grand-standing. I have experienced pros making such comments too. You can let such a remark pass out of politeness of course, but accepting it because of his presumed expertise is extremely naive IMO. I would even be suspicious of pros making such comments at move 150. Mark If a pro predicts a half-point win early in the game, that is obviously bs. But maybe we are just taking his words too literally. I think it's actually a bigger problem at move 150. Because at that point he is making a (very shaky) claim to truth. I just hate the Go-World commentaries where the narrative has one side making 3 catastrophic mistakes and the other side coasting to an unshakable 1.5 point win. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [Computer-go] Teaching Deep Convolutional Neural Networks to Play Go
A move generator, that always plays it's first choice, that can win games against Fuego? That smells like a possible game changer.(pardon the pun). Surely, programmers will take this workhorse, and put it before the MC cart. Stefan ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Teaching Deep Convolutional Neural Networks to Play Go
> > Finally, I am not a fan of NN in the MCTS architecture. The NN > architecture imposes a high CPU burden (e.g., compared to decision trees), > and this study didn't produce such a breakthrough in accuracy that I would > give away performance. > > > Is it really such a burden? Supporting the move generator with the NN result high up in the decision tree can't be that expensive. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Teaching Deep Convolutional Neural Networks to Play Go
That's pretty good looking for a pure predictor. Considering it has no specific knowledge about semeais, ladders, or ko threat situations... Switching out the pattern matcher (not the whole move generator) in an existing mc program, should be pretty straightforward. Even if the nn is a lot slower than the orig. pattern matcher, it could still make sense high up in the tree. If this does prove fruitful, the question of what transforms of the raw position should be fed to the nn could be the next big thing. After the almost annoying success of general purpose mc, this would be a more poetic line of research. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Move Evaluation in Go Using Deep Convolutional Neural Networks
Great work. Looks like the age of nn is here. How does this compare in computation time to a heavy MC move generator? One very minor quibble, I feel like a nag for even mentioning it: You write "The most frequently cited reason for the difficulty of Go, compared to games such as Chess, Scrabble or Shogi, is the difficulty of constructing an evaluation function that can differentiate good moves from bad in a given position." If MC has shown anything, it's that computationally, it's much easier to suggest a good move, than to evaluate the position. This is still true with your paper, it's just that the move suggestion has become even better. Stefan ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Move Evaluation in Go Using Deep Convolutional Neural Networks
Last move info is a strange beast, isn't it? I mean, except for ko captures, it doesn't really add information to the position. The correct prediction rate is such an obvious metric, but maybe prediction shouldn't be improved at any price. To a certain degree, last move info is a kind of self-delusion. A predictor that does well without it should be a lot more robust, even if the percentages are poorer. Stefan ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Evaluation function through Deep Convolutional Neural Networks
To me, that's the core lesson of MCTS - take your hands off that evaluation button. On Sat, Jan 10, 2015 at 12:00 AM, Darren Cook wrote: > > The discussion on move evaluation via CNNs got me wondering: has anyone > > tried to make an evaluation function with CNNs ? > > My first thought was a human can find good moves with a glance at a > board position, but even the best pros need to both count and use search > to work out the score. So NNs good for move candidate generation, MCTS > good for scoring? > > Darren > > > ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Move Evaluation in Go Using Deep Convolutional Neural Networks
> > Let's be pragmatic - humans heavily use the information about the last > move too. If they take a while, they don't need to know the last move > of the opponent when reviewing a position, but when reading a tactical > sequence the previous move in the sequence is essential piece of > information. > > -- > Petr Baudis So maybe there is a greater justification for using last move info in the playout than in the tree? Stefan ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Teaching Deep Convolutional Neural Networks to Play Go
> But, I imagine this is more fuss than it is worth; the NN will be > integrated into MCTS search, and I think the strong programs already > have ways to generate ko threat candidates. > > Darren > Do they? What would look like? Playing 2 moves in a row for the same side? I thought the programs naively "discovered" ko threats. Stefan ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] UEC Cup
What an unfortunate game against the human opponent. The trouble started early with the tight low pincer at move 12. The way black could press down on that move is what created the incentive for CS to play the totally unreasonable invasion on the right a little later. Stefan On Mon, Mar 16, 2015 at 2:37 AM, Rémi Coulom wrote: > Here is a partial game record I saved during the game. I am sorry I did > not save the full game as sgf. It is on the nngs server of the UEC, so I > might be able to get it tomorrow. > > Crazy Stone invaded too deeply, and died. > > Tomorrow, the handicap will be 4 stones for DolBaram, and 3 stones for > Crazy Stone. > > Rémi > > ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] UEC Cup
> > DolBaram won the 4-handicap game against Cho Chikun 9p! > > ..but unfortunately, CrazyStone lost the 3-handicap game against > Cho Chikun. It made a dubious choice in the opening, but my guess > is that more importantly, a corner semeai with approach liberty was > left in one corner throughout the game. > Unresolved important stuff. The (not so) secret weapon against bots. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] OT (maybe): Arimaa bot notably stronger
The funny thing is, that in computer go there are no goals, except winning. And therefore, the reason for a win cannot be determined. One crude measure might be to use "stronger" attacking moves in the playouts, when the winrate is low. unrelated: Does anyone know if the successful Arimaa bot "responds" to the gold setup when it's silver, or if it just ignores how gold deployed? Just wondering. Stefan ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Arimaa bot notably stronger
> On > http://arimaa.com/arimaa/challenge/2015/showGames.cgi > the games can be replayed. > > That's nice. Arimaa looks like a rather tedious game to actually play > though. > I have never played it, but the idea seems to be to take the opponents camel hostage at a sinkhole, and then go bossing around with your own camel while the opponents elephant is occupied.(ok, that's at the level of a 30k telling you how smart a ponnuki is) > > So, this is the second game (after Havannah) where programmers > caught prize money for beating a strong/the strongest human player. > Probably, game inventors will understand better now how risky such > challenges are. > > > It wasn't a million dollar challenge. Given the programming effort, 12k$ is not a huge amount of money. I think this prize was offered with the idea of paying it out. > > PS. Perhaps, some tricks of bot_sharp may be applied to bots > in "Connect6". > It's probably pretty confined to Arimaa. The whole game was designed to confound bot tree search with the huge number of possible moves. So it stands to reason, that good forward pruning is the key to the kingdom here. Funny, how the really powerful techniques are so often disappointing, when you look behind the curtain. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Programme NAO to play Go and talk about it
The quantum leap in go computing was to discard all structures, to plan nothing, to evaluate nothing except final score. That has it's own limits - programmers wish they could get some separation of concerns implemented. But we're talking about going from beating pros with 4 stones to beating them with 3 - that's lamenting at a very high level. Plans, evaluation functions, ect failed for over 20 years to produce true (amateur) dan level programs. Also, you cannot give reasons for moves "after the fact" if reason wasn't used to obtain the selected move in the first place. Stefan ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] re comments on Life and Death
Robert, David Fotland has paid his dues on "truly intelligent" go programs. Maybe more than anybody else. I find your critique a little painful. Don't blame David, that the "stupid" monte carlo works so much better. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] what do you (or does your computer) see?
When I click on a youtube video, I don't expect much. But I do expect to be at least marginally entertained. One more video of this "quality", and you will have lost me as a potential viewer. On Fri, Sep 4, 2015 at 5:31 AM, djhbrown . wrote: > > > https://www.youtube.com/watch?v=IoO7Nhlf_k4&list=PL4y5WtsvtduqNW0AKlSsOdea3Hl1X_v-S&index=10 > > Please reply by posting a comment on YouTube > > > > > > > > > ___ > Computer-go mailing list > Computer-go@computer-go.org > http://computer-go.org/mailman/listinfo/computer-go > ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Dynamic komi - VBSC
The best contenders may be best for entirely different reasons. How do you compare a line that tries to bring down a huge group with a line that cautiously tries to optimize safe points. It's really hard to do. And whereever the dynamic komi lands, pedestrian variations may look great or totally uninteresting. The idea of dynamic komi is to give enterprising variations short of kamikaze a chance of prevailing in poor positions, and humdrum variations better than passing a chance in comfortable positions. So what you need is some estimate of the overall state of the game, and averaging out from all variations seems like a sensible way to do this. Stefan ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] re comments on Life and Death
So far I have not criticised but asked questions. I am a great fan of the expert system approach because a) I have studied go knowledge a lot and see, in principle, light at the end of the tunnel, b) I think that "MC + expert system" or "only expert system" can be better than MC if the expert system is well designed, c) an expert system can, in principle, provide more meaningful insight for us human duffers than an MC because the expert system can express itself in terms of reasoning. (Disclaimer: There is a good chance that I will criticise anybody presenting his definitions for use in an expert system. But who does not dare to be criticised does not learn!) MC is currently stagnating, so looking at new (or old discarded) approaches has become more attractive again. But I don't think that a "classic" rules based system will be of much use from here. It is just too far removed from MC concepts to be productively integrated into an MC system. And no matter what, MC has to be the starting point, because it is so much more effective than anything else that has been tried.What you are left to work with, is the trail of statistics that MC leaves behind. That is the only tunnel with a possible end to it that I see. And who knows, maybe someone will find statistical properties that can be usefully mapped back to human concepts of go. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] maybe interesting Youtube video
Ok, he's no go expert. Blaming the difficulties on the board size, and lack of clever (chess) programming. But it's still enjoyable to watch, thx. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] KGS bot tournaments - what are your opinions?
> > 1. I do not see a way to do this but running on same hardware (e.g. > Amazon EC2 with graphic card). Even this is unfair, as programs might > be optimized to other configurations (cluster) > > First, there is the question is fairness is even desirable. But also, as you say, it is really impossible to make an event "fair", even with identical hardware, because this will give the reverse advantage to programs that put a premium on resource conservation in their design. And with the new CNN developments, it would be a shame to put resource limits to the top of the agenda. As a Kibitz, I would have an added trivial wish: force a minimum time consumption on the first moves of 9*9 games. It's annoying as a spectator to have the first 8 moves or so just spit out on the board, forcing you to go back to see what happened there. It would also slightly lessen the advantage of bots with books. Stefan ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] KGS bot tournaments - what are your opinions?
On Wed, Oct 7, 2015 at 7:21 PM, Dave Dyer wrote: > > How about handicapping the hardware based on time. Programs running > on more powerful hardware would get less time. > > I think that's a good idea. Programs could even aquire a time ranking, depending on their success in previous tournaments. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] CGF Open 2015 result
A thought about that impressive article: Move prediction has become the bot workhorse. But I have a question: how can those predictions work, without having a goal? The predictions are obviously purely shape based, so a 41% success rate is really pretty awesome. But that means that some positions, like running battles, the percentages will be a lot better than in others, like non eye-stealing eye filling. How about giving the learning algorithms a "hint" about the solution? Not about the area, but the type of move. So when, for example, in the tree, certain stones end up captured a lot, a different move predictor, that prefers taking libs, filling eyes ect might try to avoid that fate. I know this is pure handwaving, but some kind of feedback from search results to predictor used seems needed. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] codecentric Challenge 2015, Round 2
What Semeai is that? Do you mean the useless attack on the b center group? It looked to me simply like an aimless long endgame by Zen. But I would be interested to know, what Zen's specific problem was. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] AMAF/RAVE + heavy playouts - is it save?
The name "Monte Carlo" strongly seems to suggest, that randomness it at the core of the method. And randomness does play a role. But what really happend in the shift to MC, was that bots didn't try to evaluate intermediate positions anymore. Instead, all game knowledge was put into selecting candidate moves. It turns out, that, for bots, it's much easier to suggest promising moves, than to say who is ahead in an ongoing game. The tree of possible go games is so vast, that trying to explore it with pure randomness fails. Even with statistical feedback. It's already a minor miracle, that it works as well as it does with good move generators. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Komi 6.5/7.5
I agree with Robert. 7 is still a hot candidate for all board sizes. Stefan ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Facebook Go AI
> I understand the idea, that long term prediction might lead to a > different optimum (but it should not lead to one with a higher one > step prediction rate: it might result in a stronger player with the > same prediction rate...), and might increase training speed, but hard > facts would be great before spending a GPU month into this :) > > > > Detlef > I wouldn't be too sure, that this cannot improve the 1 step prediction rate. In a way, multi-step prediction is like peeking around the corner. :-) Stefan ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] NHK News "Bots will be admitted to pro tournaments"
According to a post in this forum it's 13*13. http://lifein19x19.com/forum/viewtopic.php?f=18&t=12553 ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Number of Go positions computed at last
Good joke to render the solution as a board position. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Mastering the Game of Go with Deep Neural Networks and Tree Search
I always thought the same. But I don't think they tackled the decomposition problem directly. Achieving good(non-terminal) board evaluations must have reduced the problem. If you don't do full playouts, you get much less thrashing between independent problems. It also implies a useful static L&D evaluation. That "value network" is just amazing to me. It does what computer go failed at for over 20 years, and what MCTS was designed to sidestep. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Mastering the Game of Go with Deep Neural Networks and Tree Search (value network)
The evaluation is always at least as deep as leaves of the tree. Still, you're right that the earlier in the game, the bigger the inherent uncertainty. One thing I don't understand: if the network does a thumbs up or down, instead of answering with a probability, what is the use of MSE? Why not just prediction rate? On Thu, Feb 4, 2016 at 8:34 PM, Álvaro Begué wrote: > I am not sure how exactly they define MSE. If you look at the plot in > figure 2b, the MSE at the very beginning of the game (where you can't > possibly know anything about the result) is 0.50. That suggests it's > something else than your [very sensible] interpretation. > > Álvaro. > > ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] new challenge for Go programmers
Your lack of respect for task performance is misguided imo. Your preconceived notions of what intelligence is, will lead you astray. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] Creating the playout NN
If I understood it right, the playout NN in AlphaGo was created by using the same training set as the one used for the large NN that is used in the tree. There would be an alternative though. I don't know if this is the best source, but here is one example: https://arxiv.org/pdf/1312.6184.pdf The idea is to teach a shallow NN to mimic the outputs of a deeper net. For one thing, this seems to give better results than direct training on the same set. But also, more importantly, this could be done after the large NN has been improved with selfplay. And after that, the selfplay could be restarted with the new playout NN. So it seems to me, there is real room for improvement here. Stefan ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Creating the playout NN
I don't know how the added training compares to direct training of the shallow network. It's prob. not so important, because both should be much faster than the training of the deep NN. Accuracy should be slightly improved. Together, that might not justify the effort. But I think the fact that you can create the mimicking NN, after the deep NN has been refined with self play, is important. On Sun, Jun 12, 2016 at 9:51 AM, Petri Pitkanen wrote: > Would the expected improvement be reduced training time or improved > accuracy? > > > 2016-06-11 23:06 GMT+03:00 Stefan Kaitschick >: > >> If I understood it right, the playout NN in AlphaGo was created by using >> the same training set as the one used for the large NN that is used in the >> tree. There would be an alternative though. I don't know if this is the >> best source, but here is one example: https://arxiv.org/pdf/1312.6184.pdf >> The idea is to teach a shallow NN to mimic the outputs of a deeper net. >> For one thing, this seems to give better results than direct training on >> the same set. But also, more importantly, this could be done after the >> large NN has been improved with selfplay. >> And after that, the selfplay could be restarted with the new playout NN. >> So it seems to me, there is real room for improvement here. >> >> Stefan >> >> ___ >> Computer-go mailing list >> Computer-go@computer-go.org >> http://computer-go.org/mailman/listinfo/computer-go >> > > > ___ > Computer-go mailing list > Computer-go@computer-go.org > http://computer-go.org/mailman/listinfo/computer-go > ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Creating the playout NN
> > BTW, by improvement, I don't mean higher Go playing skill...I mean > appearing close to the same level of Go playing skill _per_ _move_ with far > less computational cost. It's the total game outcomes that will fall. > > For the playouts, you always need a relatively inexpensive computation. Because for every invocation of the main NN in the tree, you need several hundred cheaper calls in the playout. So it will have to be orders of magnitude faster. Surely, replacing a crude fast NN with a slightly less crude fast NN would be beneficial. I don't know if other bots besides AlphaGo are already utilizing the selfplay improvement. But when they do, it will be helpful there too. Because the added knowledge of the main NN can be transferred down to the playout NN. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Creating the playout NN
> > The purpose is to see if there is some sort of "simplification" available > to the emerged complex functions encoded in the weights. It is a typical > reductionist strategy, especially where there is an attempt to converge on > human conceptualization. > > That's an interesting way to look at it. If you do this with several different smaller NN of varying complexity, and see how good they are, you would get some kind of numeric estimate of the complexity of the encoded concepts. Of course. there is the slight problem, that we also would need to map those "simple" NN to concepts somehow. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] Scoring Network
Has anyone ever tried to build a value network that is trained on finished positions? I admit that would be less awesome than what AlphaGo's value network has achieved. But reducing the task to status and scoring might help in endgame play. Generalizing this, there could be several value networks, each specialized on a different stage of the game. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Chun-Hsun Chou 9p vs Yi-Min Hsieh 6p and DarkForest on ICIRA 2016 Tokyo
It's hard to tell, because bots don't really play outrageous moves anymore, especially not it good positions. My guess would be the shoulderhit at 41. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] it's alphago
> Honestly I got a little frustrated that many people didn't think that > was AlphaGo. It was almost clear to me because I know the difficulty of > developing AlphaGo-like bots. > I feel with you. People seem to think that the Nature paper gave away the full recipe. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] AlphaGo rollout nakade patterns?
Finally, somebody asks about the nature of those 8192 patterns.(pardon the Nature pun) ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Patterns and bad shape
On Mon, Apr 17, 2017 at 3:04 PM, David Wu wrote: > To some degree this maybe means Leela is insufficiently explorative in > cases like this, but still, why does the policy net not put H5 more than > 1.03%. After all, it's vastly more likely than 1% that that a good player > will see the ladder works here and try escaping in this position. I think it's likely that the ladder is actually the first thing that Leela considered. My guess is that it put a penalty on the move after misreading the ladder. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go