[ACT-R-users] Towers of Hanoi in ACT-R 6?

[Dan Bothell]

--On Tuesday, May 09, 2006 11:43 AM +0200 Leon Urbas 
<leon.urbas at zmms.tu-berlin.de> wrote:

> Hi Rob,
>
> As far as I understand the tower of hanoi examples heavily rely on
> manipulation of a perfect goal stack via push and pop. This
> psychologically unplausible assumption was given up with ACT-R 6,
> unfortunately without an equivalent architectural replacement.
>
> Since development of a central executive seems to be still at an early
> stage, we had to develop a quick hack to force our ACT-R 6 models to
> reliably "jump" back to a previous goal: as soon as we want to switch to a
> subgoal we label the current goal with an unique id and remember this id
> in a slot of the new goal. This was necessary because relying on
> activation-decay of the previous goal gave us unacceptable high error
> rates in goal/sub-goal control in our dynamic environments.
>
> (P branch-to-subgoal
> 	...
>  ==>
>  	!bind! =id (get-time)
>     	=goal>
>  		id		=id
>    	+goal>
> 		isa		...
> 		state		start
>     		last-goal-id 	=id
> )
>
> This allows us to retrieve exactly this goal later on when sub-goal
> processing has come to an end (iff retrievable)
>
> (P retrieve-previous-goal
> 	=goal>
> 		isa		...
> 		state		finished
> 		last-goal-id	=last-goal-id
> 	?retrieval>
> 		- state		busy
> ==>
> 	+retrieval>
> 		...
> 		id		=last-goal-id
> )
> (P copy-retrieved-goal-to-goal-buffer
> 	...
>    	=retrieval>
> 		...
>         	slot1		=value1
> 		...
>         	slotn		=valuen
> ==>
> 	+goal>
> 		...
>         	slot1		=value1
> 		...
>         	slotn		=valuen
> )
>


There are other ways to do that which don't require the generation of
a unique id because you can use the goal chunk as its own "id".

One way to do that is essentially a direct mapping onto the old
perfect goal stack mechanism.  You can store the current goal directly
in a slot of the subgoal and then restore that afterwards:

(P new-branch-to-subgoal
        =goal>
        ...
  ==>
    	+goal>
 		isa		...
 		state		start
     		last-goal   =goal
)

Then you can restore that goal directly later in one of two ways
(which do the same thing with respect to the goal buffer):

(P return-to-old-goal-directly
    	=goal>
            ...
 		last-goal =old-goal
        ...
 ==>
       ;; This copies that chunk directly into the buffer

       =goal> =old-goal

   OR

      ;; This sends a request to the goal module
      ;; to create a chunk that looks like =old-goal,
      ;; and since goal actions take no time is
      ;; the same as just copying it there.

      +goal> =old-goal

 )

The RHS syntax in ACT-R 6 generalizes the "direct request" mechanism of
ACT-R 5 so that any request can be specified indirectly with a chunk.
Effectively, "+goal> =old-goal" is equivalent to specifying all of the
slots and values of the chunk =old-goal as the request (as you did in
your production above).  That can be used for a request to any buffer.

Of course that still has all the issues that a perfect goal stack does.

However, one can use a retrieval (similar to what you've done) to
get things like errors in goal switching, switch times based on
activation, etc.  Assuming that we still use new-branch-to-subgoal
we can do something like this:


(P retrieve-previous-goal
 	=goal>
 		isa		...
 		state		finished
 		last-goal	=last-goal
 	?retrieval>
 		state		free
 ==>
 	+retrieval>     =last-goal
 )

which doesn't rely on having a unique id or on knowing what all of
the slots and values of the chunk are.  Unlike the "direct request"
mechanism of ACT-R 5 this is just like any other retrieval request
and subject to partial matching (if enabled) because it is effectively
the same as specifying all the slots and values from the chunk =last-goal.

One thing to note is that unlike the goal module the action "+retrieval>
=last-goal" is not the same as "=retrieval> =last-goal" because a
request to the declarative module is not just a copy action.

Then to put the retrieved chunk into the goal buffer we just need to
use something like we did in return-to-old-goal-directly:


(P return-to-old-goal-indirectly
    	=retrieval>
            ...
 ==>
       =goal> =retrieval
 )


That gets around the need to specify all of the slots explicitly and
allows for partial matching to introduce errors which I think addresses
some of the issues you had with the mechanism you were using.

Hope that helps,
Dan