[ACT-R-users] puzzled by act-r 5.0.6 behavior

[Dan Bothell]

--On Saturday, November 30, 2002 1:36 PM -0500 Bruno Emond <bruno.emond at nrc.ca> wrote:

> Dan,
>
> Thanks for the explanation. I guess this is a good example of
> parallel processing between modules.
>
> Now is there a way to force act-r to wait for the retrieval to be
> finished or do I need to add a third production (see below)?
>
> (p ret1
>     =goal>
>     isa goal
>     status retrieve
>     ==>
>     +retrieval>
>     isa c
>     =goal>
>     status retrieving
>     )
> (p ret2
>     =goal>
>     isa goal
>     status retrieving
>     =retrieval>
>     isa c
>     ==>
>     -goal>
>     )
> (p ret3
>     =goal>
>     isa goal
>     status retrieving
>     ==>
>     !output! "Just waiting for my memory to catch up"
>     )
>
>

If none of the productions can fire, then nothing will happen until something changes the state (like a retrival completing) and then another attempt will be made to fire a production.  Thus, it's not necessary to have a null or spinning production most of the time (there are some circumstances where it could be necessary, but those are atypical in my experience).  In fact, in this case it's going to potentially extend the time before ret2 can fire because there'll be the full 50ms of firing ret3 even if the retrieval would have completed in less than that.  What you probably do need however is a production similar to ret2 that can handle a retrieval failure so that the system doesn't just stop when that occurs.

If the retrieval buffer had a state indicator, like the perceptual/motor buffers do, then one could check that the retreival state was free to wait, but that's not available* in ACT-R 5.  Though, a "unified" state mechanism for 
the buffers is something we're considering for ACT-R 6.

Dan

* There's actually an !eval! call that could be put on the LHS that would have 
that effect, but that's not really kosher ACT-R 5.