[ACT-R-users] stopping pm

[db30 at andrew.cmu.edu]

--On Wednesday, October 08, 2003 12:02 PM +0200 Wolfgang Schoppek 
<Wolfgang.Schoppek at uni-bayreuth.de> wrote:

> Acknowledging all the efforts of making ACT-R as veridical as possible, I
> think we should keep in mind that we don't simulate humans, but certain
> aspects of human cognitive processing. So discussing if a !stop! command
> would make ACT-R too artificial seems odd to me when I consider what high
> level of abstraction ACT-R models have (I'd even say, should have!). So
> what about motivation, emotion and the huge amount of experiential
> knowledge? I don't want to plead for a complete coverage of all these
> issues in ACT-R but rather to adjust the scale.   So I think a !stop!
> command pertaining to (pm-run) would be more useful than harmful (btw: it
> would make debugging much easier).   As for the !bang! syntax, I think we
> would reduce the sphere of possible ACT-R users (and uses) dramatically,
> when we eliminate it. Many models are explorative, (and sometimes a rough
> explorative model can be more informative than a model that was painfully
> tuned to one data set). In such models one needs the shortcuts permitted
> by !eval! and !bind!. -- Wolfgang


Absolutely. I'm not trying to say every model should account for everything,
and I wasn't trying to argue that a stop command was artificial in and of
itself.  I wanted to point out that there are other mechanisms in the 
system
that can accomplish what it appeared like you needed, and that it could be
considered in the context of the overall modeling objective instead of at
the "programming" level.  How one chooses to do so is still up to the user,
but just because code occurs in functions instead of the productions 
doesn't
necessarily mean it is not part of the "model".  Which is a distinction I
think gets blurred quite often because the assumptions and shortcuts used
do have an impact on the results of the model, but are often not discussed
in that context if at all.

As to the scope of the system, indeed, it's not at a point of simulating
humans.  But as a tool, one can apply it to essentially any level one is
interested in, and there actually are people working on issues like those
you mentioned (motivation, emotion, and experiential knowledge) within 
ACT-R.
So it's not out of the question to think that someday those could become
just another part of the system which one could use for modeling, and that
perhaps someday it could be applied as a much broader simulation of humans.

There is certainly a need for adequate debugging tools, and ACT-R 5's 
addition
of ACT-R/PM "out of the box" has definitely exposed some areas that could 
use
more work.  One thing I think we need to be careful of however is feature 
creep,
and instead of adding lots of little special case functions provide general 
and
robust tools with good documentation.  That's not to say there won't be 
special
case operations, but having too many commands can get in the way and lead 
to
confusion of the user.  For instance, I can thing of four "easy" ways (*) 
to find
out what chunk is in the goal buffer (not counting using the environment). 
They
all return something different, and none of them can be extrapolated to 
find
out what's in the visual buffer.  That doesn't seem like an ideal situation 
to
me.

Finally, nobody as far as I know has suggested that the functionality of 
!eval!
or !bind! be removed.  The issue is one of syntax - how are they going to 
be
represented in ACT-R 6 productions?  The proposal on the ACT-R 6 page
(http://act-r.psy.cmu.edu/act-r6) has one such mechanism which eliminates 
the
need for the special bang operators.  The response to that was mixed at the
Workshop, and there's still a lot of work to go in designing ACT-R 6.  So 
how
things will eventually look is still up in the air, but there is a definite
need for that type of functionality and it will be there one way or another.

Dan

* For those that are curious, I've listed the ones I thought of below, and
there are probably others.  I've put some space in for those that want to 
try
to think of them without looking.  :)

.
.
.
.
.
.
.
.
.
.
.
.
.
.

*wmfocus* holds the WME itself.

(goal-focus) will return the name of the chunk.

(buffers goal) will return a list containing the name of the chunk.

(dm) prints out all of the chunks, and one can look for the item with
    the ** marker to find the goal chunk.  The return value is the
    list of all chunk names, which with RPM loaded is always larger
    than just the goal chunk.