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
