[Computer-go] Mastering the Game of Go with Deep Neural Networks and Tree Search

Robert Jasiek jasiek at snafu.de
Tue Feb 2 00:35:14 PST 2016


On 01.02.2016 23:01, Brian Cloutier wrote:> I had to search a lot of 
papers on MCTS which
 > mentioned "terminal states" before finding one which defined them.
 > [...] they defined it as a position where there are no more legal
 > moves.

On 01.02.2016 23:15, Brian Sheppard wrote:
> You play until neither player wishes to make a move. The players
 > are willing to move on any point that is not self-atari, and they
> are willing to make self-atari plays if capture would result in a
> Nakade (http://senseis.xmp.net/?Nakade)

Defining "terminal state" as no more legal moves is probably 
inappropriate. The phrase "willing to move" is undefined, unless they 
exactly define it as "to make self-atari plays iff capture would result 
in a Nakade". This requires a proof that this is the only exception. 
Where is that proof? It also requires a definition of nakade. Where is 
that definition?

In my book Capturing Races 1, I have outlined a definition of 
"[semeai-]eye" and, in Life and Death Problems 1, of "nakade". Such are 
more complicated by far than naive descriptions online suggest. In 
particular, such outlined definitions depend on the still undefined 
"essential [string]", "seki" [sic, undefined as a strategic object 
because the Japanese 2003 Rules' definition does not distinguish good 
from bad strategy!] and "lake" [connected part of the potential 
eyespace..., which in turn is still undefined as a strategic object]. 
They also depend on "ko", but at least this I have defined: 
http://home.snafu.de/jasiek/ko.pdf Needless to say, determining the 
objects that are essential, seki, lake, ko is a hard task in itself.

So where is the mathematically strict "definition" of nakade? Has 
anybody proceeded beyond my definition attempts? I suspect the standard 
problem of research again: definition by reference to a different paper 
with an ambiguous description. If ambiguous terms are presumed for 
pragmatic reasons, this must be stated! My mentioned terms are ambiguous 
but less so than every other attempt - or where are the better attempts?

-- 
robert jasiek



More information about the Computer-go mailing list