Basically, my thesis is that yose is different than mid-game plays for life-and-death which are of uncertain probability. Yose moves - played at almost any stage of the game - are very predictable to a pro player. They'll even split a third of a point here, a third of a point there.
Are these distinctions not easily detected in playouts? Then there is information on the board which is not being captured by playouts, but which is very accessible to pro players, and moderately accessible even to the high-dan amateurs who are your next targets. Perhaps a synthesis at the tree level? Perhaps an extension of the playouts, making them still smarter? More broadly, if playouts come up with indeterminate values for simple deterministic situations - previously nakade, then certain corner positions, now semeai and yose - then the playouts are not yet doing their job; they are still quite inexact and exploitable. Terry McIntyre <[email protected]> Unix/Linux Systems Administration Taking time to do it right saves having to do it twice. ________________________________ From: Don Dailey <[email protected]> To: [email protected] Sent: Mon, July 4, 2011 11:36:00 AM Subject: Re: [Computer-go] Go is not much different from chess Terry, The issue that you are seeing is that the program sometimes makes mistakes. You cannot address this by making the program weaker in some other area in the hopes it will make up for it's other stupid mistakes such as not reading a ladder correctly. You can try to make the program win as much as possible in the hopes that it will make up for some unrelated stupid mistake elsewhere, but that is far from a robust solution. You create a very fragile program when you solve problems with hacks. Chess is not inherently binary any more than GO is. In Go you either win or lose and similar in chess. The amount of "points" on the board is not relevant except to define what a win and loss is. You can win very quickly or very slowly in chess and you can "crush" the opponent or beat him gradually and barely. I think your statement about this makes no sense. On KGS I have never heard of the number of points won being considered as part of your ranking. You said, "Don repeatedly claims that retaining yose points would reduce the winning probability." This is a gross misrepresentation of what I'm saying. I really detest it when people restate my position so that they have something that is more comfortable for them to attack. They do this is in politics (the left are communists who despise their own country, the right are gun wielding racists who hate everyone not like them.) Each side paints the other to the extreme and then attacks THAT, instead of what is actually there. The problem is that it's very difficult to determine what a yose play is in the context of playouts. You could count points instead of wins, but that is not yose. A point counter will still give up a small group of 10 stones to have a 60% chance of winning a 20 stone group. That is not yose, that is risk taking and if the 10 point group already wins it's an incredibly foolish play. That is why the notions of folding in point count is misguided and makes the program weaker. Do you really want the program to make a serious of these kinds of stupid decisions in order to "get a big lead" to compensate for a bad decision it might play later? Playing for points is NOT playing for yose and maybe that's explains your lack of understanding about this. If you can figure out how to play for yose without taking undo risk, then I will agree with you. On Mon, Jul 4, 2011 at 9:56 AM, terry mcintyre <[email protected]> wrote: Chess is inherently binary - you checkmate the king or you don't. If you don't, there are a just few simple possibilities - your king is checkmated, or there is some form of draw. > > >Going back to the idea that MCTS is not perfect. It is by now well-established >that current MCTS bots - even top ones - struggle to handle capturing races >(semeai) properly. Many examples of "snatching defeat from the jaws of >victory" >by way of failing to properly defend a capturing race exist on KGS, and some >have been copied to this list. These are highly deterministic contests - exact >solutions are known; one player wins, often by exactly one move. > > >Imagine that the program is the winner of such a semeai, and the hypothetical >loss of the semeai would not be enough to give the human player the win. The >game, as judged by a perfect oracle, a professional player or even a high-dan >amateur, is "in the bag" for the computer. The MCTS evaluation agrees. Based >on >indifference to yose (end-game) moves which have no theoretical impact on the >win, the MCTS then gives away a few points to the human player. > > >After grabbing a few yose points, the balance favors the human, who then >exploits a known weakness of MCTS programs, takes one of the semeai liberties, >and the program - due to a known and exploitable weakness - plays some >meaningless move in the middle of its own territory. > > >At this instant, a divine oracle or human pro or even a human kyu-level player >would recognize that the computer has snatched defeat from the jaws of >victory. >The human wins the semeai; this, coupled with the free points yielded in yose, >gives the victory to the human. Several moves after, the MCTS program will >realize the change in fortune, and resign. > > >Rinse and repeat. Examine the losses on KGS, and you'll find more than a few >examples. Examine the cases where the human player loses on time, and you'll >find a few more. > > >Don repeatedly claims that retaining yose points would reduce the winning >probability. This is seldom correct. In most cases, the more points one >yields, >the closer the score is to zero, and the greater the risk of having made a >mistake in reading, or making a mistake in playing, and discovering oneself on >the losing side of zero. > >When we say "rich men don't pick fights," this isn't suggesting that rich men >( >people who are winning ) give away easy points. It means to not engage in >risky >fights with uncertain outcomes; look for simpler lines which are predictable >and >which still lead to a maximal win. > > >Static twiddle factors do not use information about risk versus stability. Do >current programs even know anything about risk versus stability? > >Terry McIntyre <[email protected]> > > >Unix/Linux Systems Administration >Taking time to do it right saves having to do it twice. > > > > > ________________________________ From: Don Dailey <[email protected]> >To: [email protected] >Sent: Mon, July 4, 2011 8:03:03 AM >Subject: Re: [Computer-go] Go is not much different from chess > > >I am definitely interested in your idea and will be happy to give you my >impressions. I am not a mathematician but I have a chess program that is >near >the top. > > >I have always believed that despite numerous differences, in the big picture >go >is more like chess than we think, especially chess endings. It's always >good >to get some feedback first before submitting a paper for review. > > >Don > > > >On Mon, Jul 4, 2011 at 6:00 AM, Leon Matoh <[email protected]> wrote: > > >>I tried to scratch my back yesterday >>so bots can play proper endgame. >> >>During this time I exchanged >>several emails with with certain people. >> >>When I started writing summary of >>my findings, that single idea showed how we >>can use all chess knowledge and apply >>it to game of go. >> >>I am writing short article and >>would appreciate some peer review >>from expert in chess programming >>or a mathematician. >> >>I have short summary and am writing >>through emails. >> >>I will not discuss it in this forum as I have no time >>to engage in debates. Idea is so simple that >>you would't believe and I have no time to >>engage in debates. >> >>All I ask is that you wait a little until I finish >>short article (day or two) and suspend your disbelief. >> >>It all started with one line changed in source code of pachi >>program to confirm the idea. >> >> >>Leon Matoh >> >>_______________________________________________ >>Computer-go mailing list >>[email protected] >>http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >> > >_______________________________________________ >Computer-go mailing list >[email protected] >http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >
_______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
