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
