Re: An AI program that doesn't learn

[Heikki Levanto <heikki@xxxxxx>]

P.J.Leonard (P.J.Leonard@xxxxxxxxxxxxxxxxx) wrote in lsd.compgo:

:  For a program to decide stratergies it must search.
: To search you must focus. To focus you need to identify objects that
: are the subject and watch for changes of state.  In my opinion a GO
: program that does not try to understand the evolution of the GO game
: is at a serious disadvantage.


I am not too sure of this, for two reasons: 

Practical reason: If the program has to keep track of the whole game, and
all the plans it has made, it will need to expunge plans that are no longer
viable, and modify its behavior along the way. The housekeeping involved in
this can be quite tiresome and is prone to subtle errors in the program. It
is much easier (I presume) to wipe the slate clean after each move, and
start afresh.

Even beginner humans suffer this, either sticking too long to the defence of
a group, or aimlessly answering each and every move the opponent makes. It
takes some level of skill to be able to switch to the most important moves
on the board.

Philosophical reason: It can be argued that in each situation there is "the
best move", or at least a small number of equally good moves. The moves
ought to be the same, no matter how the situation was reached, unless you
involve some higher-level reasoning of the way the opponent is thinking ("he
tried to choose a territorial joseki in that corner, but I forced him to
take the variation that gives influence instead. So, he will be likely to
want to his territory in this corner, so I can play this joseki, and trust
that he will choose the easy variant that gets him the territory. That is
good because if I suspected that he would choose the fighting variant, I
would not dare to play that against him, seeing how good he is at
fighting...") I do not think that sort of reasoning will be seen in good go
programs for some time, if ever.


On the other hand, I can see how long-term plans might be useful. If I
decide to sacrifice that stone, and fatten it by adding a second stone to it
before the sacrifice, I do want to remember that those were sacrifical
stones, and not start some desperate resque operation at the next move. Then
again, this can lead into inflexible game, if the opponent refuses to take
the sacrifice, or offers a choice to turn the tables...


I do not wish to say that planning is no good, not at all. Only that (to me) 
it seems easier to discard all (or most) plans and start planning afresh
after each move. I would like to hear the opinions of experienced go
programmers on this matter.


- Heikki


--
Heikki Levanto  LSD - Levanto Software Development   <heikki@xxxxxxxxxxxxxxxxx>