[ACT-R-users] stopping pm

[db30 at andrew.cmu.edu]

--On Wednesday, October 08, 2003 9:22 AM +0100 Richard M Young 
<r.m.young at herts.ac.uk> wrote:
>
> It can be fairly confusing for beginners as things stand.  The first
> model (count) finishes by setting the STATE attribute of the goal to
> STOP.  So of course the model stops.  Well, no, it's not that simple. I
> asked the class to see what happens if the rule is changed to set the
> STATE to FLUMMOX or virtually anything else, and of course it still
> stops.  In the second model (addition), considerable ingenuity is used to
> choose a stopping condition.  I don't have the model in front of me as I
> write, but it's something like setting the COUNT attribute to nil while
> leaving the SUM attribute non-nil, and it turns out that particular
> combination prevents any rule from firing.
>
> Aside from being opaque and confusing to beginners, one of the problems
> with using this kind of ingenuity to stop the model is that it isn't
> stable over changes or additions to the model.  Make certain changes, and
> the model will no longer halt cleanly, or perhaps at all.


For reference, the production mentioned is this one:

(P terminate-addition
   =goal>
      ISA         add
      count       =num
      arg2        =num
      sum         =answer
==>
   =goal>
      count nil
)


Which indeed is unclear as to why it terminates the addition. I think 
that's the
only model remaining in the tutorial that doesn't have a state slot in the 
goal.

There are a couple of issues with that, and I think it gets at what is in my
observation the most difficult concept for new modelers - state management, 
or
writing the productions so that they operate in a desired sequence, not 
just
how to stop it at the end.

The production above shows how things use to be in all the tutorial models. 
The
"state" was implicitly determined by the contents (or lack thereof) in the 
slots
of the goal.  That was extremely opaque and confusing as you point out, and 
not
only for beginners either.  To make that easier for teaching we moved to 
the
explicit state slot in the goals for the tutorial (why that model wasn't 
changed
I don't know).  That does make it easier to read the given models. 
However, it
doesn't seem to have helped a lot when it comes time for students to build 
their
own models, and, in addition to feeling artificial, it can be problematic 
when
using spreading activation because the extra slot has an impact that takes 
some
extra care to handle.  Also, by having it in all the tutorial models it 
sort of
promotes a particular style of modeling which isn't what one is likely to 
find
when looking at published models.

So it seems to me that neither extreme seems to be ideal, and both are still
lacking with respect to the issue of teaching new modelers.  I don't know 
what
the right solution is, and comments from others, especially those who have
taught the material, would definitely be appreciated.



> I didn't know that the !stop! command still existed.  If it were renamed
> to be more suggestive of a "that's all for now folks" -- maybe
> !end-experiment!, or !resume-your-life! -- I would prefer it in the
> tutorial examples, despite the theoretical objections to the !syntax!.
>

It's a little tricky actually once RPM gets thrown into the mix, and that's
shown by the way that the "goal clearing stop" works now.  By default, it 
prompts
to ask whether you want to complete the pending actions first or just stop
immediately.  Just stopping immediately after the production isn't always a 
good
thing because there may be actions that were initiated by the production 
(like a
key press) which take additional time that presumably should also be 
allowed to
complete before stopping.

Generally, it is just the production system that one wants to stop, and I
actually like the feel of the goal clearing mechanism, though not it's
current implementation.  When the task is done, one clears the goal that
was trying to accomplish the task.  It seems to fit nicely with the models
that perform repeated trials by creating a new goal at the end of one to
prepare for the next.  It also avoids the need for a special operator to
stop things which I think would help reinforce the notion of model "state"
for beginners. Thus, I would propose that, particularly for the tutorial,
the way to stop a model is with "-goal>" on the RHS.

There is still the issue that productions don't need to test the goal,
and thus it wouldn't always stop things.  So there should still be some
programmatic mechanism(s) (and there are such things being designed into
ACT-R 6), but from a teaching standpoint -goal> feels good to me.

Again, comments and suggestions are welcome.



> Any chance of getting agreement on this, and getting the tutorial code
> changed?

It's not likely that the ACT-R 5 tutorial will be change at this point, but
discussion of these issues will be beneficial when it comes time to update
things for ACT-R 6.

Dan