[ACT-R-users] Advice

[Dan Bothell]

--On Monday, January 09, 2006 9:58 AM -0500 Roy Wilson <rwilson+ at pitt.edu> 
wrote:

> Hi,
>
> I am interested in modeling a situation in which the problem solver P
> alternates between work on two unrelated types of task. P works on task A
> until given task B by supervisor S, returns a result to S,  and resumes
> work  on task B.
>
> I wish to do this where P is modeled using ACT-R, S is modeled using
> Java,  and each is run as an independent process. Is this any easier in
> ACT-R 6 than  in 4/5, and can someone point to a study where it has been
> done?
>

I can't really point you to any specific studies (at least not any with
available code), but I've worked on interfacing ACT-R with a bunch of
external (outside of Lisp) systems and can offer some general observations.

If you're using the perceptual/motor modules of ACT-R, then the "device
interface" which they use to interact with the "world" is essentially the
same in ACT-R 6 as it was in ACT-R 5.  So at that level, things are going
to be the same.  One thing that may make things a little easier in ACT-R 6
is that there is only one event queue for the model (whereas ACT-R 5 had
one for the perceptual/motor system and one for the cognitive system) and
there are more options available on how to progress through it that may
help.  [See the framework-API.doc included with ACT-R 6 for the run-*
functions and in particular, run-until-condition may be useful.]

Often, it's the constraints of the external system that determine how
easy/hard things will be.  Some things to consider:

- Is the model going to have to directly manipulate GUI elements?
- Is there already an existing interface to the system you must use
  (TCP/IP, UDP, RS232, etc)?
- Is there a fixed API for the communications that are sent/received?
- Is the system running in a real or virtual time scale?
- Do you have the ability to modify/extend the external code?
- Would it be possible to just reimplement/simulate the system on the Lisp
  side?

The answers to those can really lead to different solutions being
necessary to hook things up.  Thus, unless someone has a very
similar situation to yours, example code from existing systems may
not be of much use anyway.

Hope that helps,
Dan

PS
Something else to note, since you explicitly mention Java, is that
the features for Allegro Common Lisp list "Java Tool Suite: Package
applications as Java Beans or Servlets, directly call Java methods from
Lisp methods and vice versa, and dynamically generate Java byte codes to
run on JVMs".  I've never actually used those features, but if you have
source control over your Java supervisor, then using that may make
things easier to interface.  I don't know to what extent other Lisps offer
such features, so there may be equally good or better solutions in other
Lisp applications as well, but that's the only one I've seen mention
direct Lisp<->Java functionality.