Competing "retrieval" rule vs compiled "habit" rule?

[Mike Byrne]

the whole list:

--------------------------------------------------

First, let me say I'm honored that my old master's thesis causes
consideration of deep architectural issues.  Please keep those
citations coming!

Second, I am also teaching an ACT-R class this semester which
requires projects.  One student will be doing his project on goal
management in general (that is, without a stack) and one student
will be modeling PCEs in particular.  So I'm about to run into the
same kinds of issues.

Now, let me say that I believe that 5.0 is more appropriate than
4.0 for this kind of thing if for no other reason than because
we've done away with the goal stack (at least in priciple).  I've
always thought of PCE's as being a good piece of evidence against
goal stacks.

Anyway, more recent work on PCEs in my lab suggests that doing a
task containing a potential PCE over and over does reduce the error
rate, but that there's a cost--subjects never get faster at the PCE
step.  This suggests deliberation, probably retrieval-based, about
what to do at that point.  WM load would obviously interfere with
such deliberations.

Under one 5.0 view of goal management, the completion of any goal
not explicitly tied to some other goal (i.e. any goal that does not
lead automatically to a new goal when it completes) will result in
an attempt or attempts to retrive unsatisfied goals from
declarative memory, so that the system knows what to do next.

Combine this with something like display-based (or
environment-based) problem-solving strategies, and you should* get
an account of habit-capture errors and PCEs.  My idea goes like
this:  

[1] The system completes some goal, and attempts to retrive an
unsatisfied goal (of which "get bread" might be one) because it
needs to know what to do next.  
[2] This retrieval fails (due, perhaps, to high WM load), so the
system tries to (re)construct a current goal based on the present
display (or environment).  
[3] The environment contains all the cues for "drive home", so
that's the goal that gets (re)constructed.  

Note that if WM load is low, however, then there's a better chance
that the "get bread" goal will be retrieved, and thus no goal
(re)construction attempted.  So you get WM-driven error.  (* I say
"should" because I have no built model--yet--that does this.)

Notice there's not even a mention of conflict resolution in that
story--I don't think it's a necessary part of the account.

On a more general note, I think the removal of the goal stack will
cause us as a community to have to think a lot harder about goal
management as a general problem and this will lead to interesting
results on a number of fronts, especially with respect to error
behavior.

> I'm also struck by the fact that there are no "retrieval"
> productions in 5.0, as I understand it.  Does this make a
> difference to the problem?

I'm not sure exactly what you mean by "retrieval" production
here--productions in 5.0 can both harvest and initiate retrievals,
but the same production cannot both initiate and harvest the same
retrieval (as in 4.0).  

However, I do think 5.0's asynchronous, buffer-based retrievals
will change how conflict resolution effectively works for some
models.  One can now attempt a retrieval with very little real
cost.  Let's say you have two strategies for solving a problem, A,
which requires a lengthy and expensive retrieval, and B, which
requires a bunch of production-based computation or
perceptual-motor activity (e.g. reading off a display).

In ACT-R 4, productions which implement A & B will compete, with
only one winner.  Learning over this will be *highly* sensitive to
the success rate and duration of the retrieval, because merely
attempting the retrieval can cost the system all kinds of time--you
get the double-whammy for retrieval failure because it hurts
success rate as well as costing a lot of time.

Now, enter 5.0 world.  Instead of conflict, you have one production
which both initiates the A's retreival and starts the ball rolling
on B's processing.  B gets going while the retrieval is being
attempted.  If the retrieval eventually comes back as a failure, no
worries, just continue with B.  If it's successful, great, stop
doing B and just proceed with the A-based strategy.  

This completely changes the nature of the conflict resolution
problem--essentially the only time you'll really even enter CR here
is when the retrieval completes--you want the production that
checks the retrieval buffer to be guaranteed to win in CR so the
buffer actually gets checked.  

Of course, A could be your general-purpose kind "retrieve an
intention" and B could be "keep driving".  If A fails, no problem,
just keep driving.  This is an alternative account to the previous
one, but it doesn't cover PCEs so I favor the other one--but this
should illustrate my point about how the more parallel world of 5.0
can dramatically change things like CR and strategy selection.

I'd be interested to hear other people's thoughts on this,
especially Marsha, who's done a lot of work on both WM and CR.
Marsha?

-Mike


===========================================================
Mike Byrne, Ph.D.                             byrne at acm.org
Assistant Professor, Psychology Department
Rice University, MS-25          http://chil.rice.edu/byrne/
6100 Main Street                      +1 713-348-3770 voice
Houston, TX  77005-1892                 +1 713-348-5221 fax