[Computer-go] Programme NAO to play Go and talk about it
djhbrown at gmail.com
Mon Aug 31 17:37:15 PDT 2015
there are already some Go programs around that can beat most people - but
not one (yet) than can explain what it is thinking about in natural
one reason is that the current crop of Go programs don't "think" like
people - the best they could do is walk a few moves through a few branches
of the move tree that they envisage, but then they can't say what they
"see" at any stage, because they do not "see" structured objects like
groups of stones.
does. It builds a hierarchically-structured conceptual model "mental image
of the state of the game, which is readily expressed in natural language,
because its conceptual model builds structures that are identical to those
of natural language .
Or rather, it will, once someone turns my pie in the sky better mousetrap
design into software. It would require a team of several programmers, each
with special expertise in a particular domain, such as computer vision (to
be able to see the stones on the board), hand/arm manipulation (to be able
to place a stone - possibly using magnets to hold and release a stone as
high precision is required for placement), improved proprioception (so it
doesn't overbalance when it leans over the board), and two more modules
(the hardest parts to program):
A: the *thinker*, comprising:
1. conceptual structure recogniser, which creates conceptual constructs
such as stone groups and their strength (probability of life), potential
territories (which requires an "edge detector" to identify empty regions
bounded by stones belonging to probably strong groups; hence edge detection
is a recursive procedure), weak (cutting) points, and urgent or big points
identified by heuristic search.
2. plan generator, to identify strategic objectives such as 'strengthen
this group', 'invade (or reduce) that moyo', etc
3. tactics generator, which would perform brute-force monte-carlo search
within the "fovea" - a small subarea of the board delimited by edges
perceived by (1), to create move candidates.
4. chooser, which would decide between move candidates that satisfice 
identified strategic objectives using a simple static evaluation function
to assess the balance of power in the game based on counting potential
territories and a scoring function for evaluating group "vulnerability".
B: the *talker*, comprising a chatbot-style  sentence fragment
expresser of conceptual structure fragments. the talker would be able to
explain HALy's thinking, but unable to sensibly answer arbitrary questions
as that would require many years of r&d to bring it to market. It could,
however, say what HALy thinks about move suggestions.
C: the *emoter*. This is the killer-app, the one that will attract the
attention of the media and the public, and start a chain reaction in
people's attitudes towards themselves and to machines, and turn over the
tables of hubristic armchair philosopher-priests who ignorantly witter on
about qualia and consciousness based on what they see when they gaze up
their own anae . Yet, ironically, it is the easiest one to program!
The emoter uses KISMET-style  routines to express its feelings through
body language, voice tone and facial gesture - oh no, sorry, NAO doesn't
have a movable face... yet. HALy's emotions are very simple, based on
changes in the value of the static evaluation function from one move to the
big swing up = happy .. arms up
big swing down = sad .. head down
win = content .. polite bow "arigato gozaimashita"
lose = angry .. smashes its hand onto the board and yells "stupid game!!"
It may be possible to implement HALy in NAO SDK  plus a few specialised
modules written in raw code. It is likely that HALy would require more
computing power than will fit into NAO's head  so most of the work would
be done by a processor cluster connected to NAO by wifi.
 The Natural Topology of English by David Brown :: SSRN
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Computer-go