Re: An AI program that doesn't learn

["P.J.Leonard" <P.J.Leonard@xxxxxxxxxx>]

Heikki Levanto wrote:
> 
> 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.

 You would never try to change past plans just see if they worked.
Keeping a record
of plans is not so hard ?).  At each move you would  reformulate your
plans if the opponents
reply is not in your search tree. You could also intensify the search
because the response
elimates so many alterantives. 

> 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.

 Aggreed you should not get stuck in a plan and each move should start
fresh
to make sure that the plan is still valid.

 I would argue that the switches of objective are very interesting and
should
ultimately become part of a learning proceedure. A program that
maintains objects
and has plans can detect these switches ( an objective that was
formulated in the past
haws failed ! WHY ?  alert the programmer that the reasoning is
incorrect !)
 For example a program that thinks a group is alive and a later point
that group is invaded
and destroyed. It makes plenty of sense to detect this type of thing and
fix the bugs.


> 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.


 Agreed. I don't think a program should assume how a player will play
(although
I suspect real players do so all the time).


> 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.

 Just to reiterate I say reformulate plans on each move. See when the
plans change
and work out why they had to change and you will find some interesting
feature that
you probably should take into account.


-- 
 Cheers Paul (P.J.Leonard)