[ACT-R-users] stopping pm

[db30 at andrew.cmu.edu]

--On Tuesday, October 07, 2003 4:43 PM +0200 Wolfgang Schoppek 
<Wolfgang.Schoppek at uni-bayreuth.de> wrote:

> Hi Dan,
> it's just a matter of program clarity. I would like to keep the code that
> controls the flow of the experiment as separate from ACT-R as possible.
> With your solutions (sort of which I've used in the past), ACT-R and
> experiment-control-code call each other mutually. I'd like to have a
> solution where calling experiment-control-code from ACT-R is reduced to a
> minimum. This could be easily done by a function like (pm-stop) called
> from the production that gives the answer. With such a solution, the
> function that runs a complete test block with open ended trials would
> look very clear:
>
> (defun recognize (ili)
>     (setf *stimulus* ili)
>     (pm-run)  ; until it is stopped from the rhs of some production
>     (do-after-trial-stuff)
> )
>
> (defun do-test (stimuluslist &optional (fun #'recognize))
>    (dolist (ele stimuluslist)
>      (funcall fun ele))
> )
>

I agree that experiment code and the model should be kept as separate as
possible.  It seems thought that we differ on our views of the system.
Here's my opinion on the matter.  First and foremost, I'll say that I
consider the ACT-R implementation as a very powerful and very general
tool that can be used in many different ways for many different purposes,
and as such there really isn't a right and wrong. So please don't feel
that I'm trying to say there's anything wrong with how you're trying
to use it, and your question just seemed like a good way to start a
discussion of these types of issues that seem to come up occasionally.

What I proposed does not have any mutual calling as I see it.  By using
the device interface abstraction, the origin of the responses doesn't
matter.  It could be a person or a model, and that seems to be a complete
separation of the model from the experiment code in my view.  That's what
I see as one of the important modeling issues - having the model do the
same task as a person.

The only source of mutual calling would be if do-after-trial-stuff did
things to modify the model, and in my view that's no different from a
!eval! call in the productions directly.  Granted, it may look cleaner,
but from a modeling perspective I'd say they're equivalent.  I also
realize that it's often much easier and sometimes necessary to abstract 
away
some of the details of a trial like that, and for ACT-R 4 that was the
standard operating procedure.  However, with ACT-R/PM being a part of
ACT-R 5 it is possible to model a lot more of the trial and experiment
structure.  In a sense, one doesn't have to "stop" the human participants
between trials, so it shouldn't be necessary to do so with a model either.
Again, when it comes to really writing models I know that can be time
consuming and not relevant to the purpose of the model, and I'm not trying
to say that I think every model needs to account for every detail of the
experiment.  It's just that with ACT-R/PM attached I think it's now more
possible and that may be worth some investigation in general.



Back to the question at hand.  As Mike and Christian point out, clearing the
goal buffer will stop ACT-R/PM.  Implementation wise, I'd suggest -goal> 
instead
of !pop! in ACT-R 5 because that's "kosher" ACT-R 5 syntax.  One thing that 
you
will need to do however is make sure that you set the ACT-R/PM parameter
:auto-dequeue to t because the default is nil, and in that situation it 
will
prompt you for a response before returning.  As Christian pointed out 
though,
that's an oddity of the current ACT-R/PM because indeed there can be 
productions
without goal buffer tests that should still be able to fire when the goal 
is clear.
At some level all that's really necessary is to just change the state so 
that none
of the productions will match and the call to pm-run will return.  So, 
there are
lots of other ways that can be accomplished, but without the details of 
your model
it's hard to make a good suggestion.

As for the issues about the future of things, I'm working on the 
specification of
the new scheduler at this point.  One of the things that's in there is the 
notion
of a breakpoint, so it will be possible to schedule "stops", at least as 
things are
starting to take shape with 6 for now.  How that will interact with 
productions is
still to be decided, so that's something for future discussions.

Dan