In the design and implementation of jACT-R we have attempted to maintain complete compatibility with the Lisp implementation. However, issues sometimes arise that forced us to diverge from ACT-R proper. Below is a listing of the divergences and the rationale behind them.
Core
retrieval-state buffer : ACT-R has no mechanism to determine if a retrieval is currently in progress. This can result in retrieval buffer jams if the modeler is not prolific with their state slots. To amend this, we added the retrieval-state buffer which behaves just like the other module-state buffers. If a retrieval is pending, the state & modality slots of the retrieval-buffer’s chunk will be set to busy, otherwise they are free.
referencing an unencoded chunk : A common mistake in ACT-R is the referencing of a chunk (typically a new goal about to be pushed) that has not been encoded. What can happen is that if the new chunk is encoded and then merged with a previously existing chunk, the new chunk handle (reference in some other chunk) will be invalid. This was a result of the Lisp implementation and is not actually part of the ACT-R theory per se. We implemented a wrapping mechanism that prevents this from happening. You can be sure that a chunk reference before encoding will be stable.
parameter names : I hate three letter parameter names!
PM
screen-x, screen-y ? Funny names for “visual angle” coordinates. I’ve recentered the visual angle coordinates such that the center of the screen is 0,0. [This of course, assumes a static head, which is not the case when you have the spatial extension installed.. but that’s another story]
visual-location search priorities : The only actual contract that Mike specifies is that the closest to the current visual location will be returned. jACT-R uses the order of the slots presented to the visual-location buffer for its priorities. If color is first, it will be the first constraint applied in the sorting of candidate visual locations
visual search along a vector : The visual-location chunk type now includes along which allows you to specify an orientation (angles, 0 is straight up and down), which in combination with the currently attended visual location gives you a visual attention search vector. It will return the first visual-location along this vector that matches all the provided parameters. Actually, this will just sort the candidates based on their distance from the search vector and then by their distance from the current visual location
visual-location attended slot : It is very common in jACT-R for there to be multiple visual chunks at the same location. So that they can all be attended at some point in time, the visual-location chunk’s attended slot is not set to true until all of the objects at that location have been attended to.
Two different visual searches in one : objects’ visual locations are centroid based. This can produce some problems. See the figure for an example. So, jACT-R has both the basic centroid based preattentive search, and then it performs a more accurate search of the immediate area within the fovea. This foveal search is dead accurate for returning objects at locations other than the centroid.
Lines & Points : Lines and points are now default visual-objects. Basic components can be broken down into them, and if a graphical interface uses the JshapeComponent, all the contained shapes will be encoded as well.
a. Separation of visual and symbolic representations of points and lines. Line-vis & line-sym, point-vis & point-sym
b. Linking chunks to show the relations between lines and points
c. Line component (point1, point2, line), Point-component (line1, line2, point)
d. These are generated automatically upon the successive encoding of lines and points. The line-component is generated when a line and two of its points (there are three, end points and center) are attended to successively. Likewise, a point-component is generated when a point and any one or two lines that it lies on are attended to successively.
PM Notes.doc
PM Notes
jACT-R is able to see Swing GUI interfaces by listening to all the GUI events from the AWTEventThread. As events are processed, the system checks to see if the GUI component in question is a descendent of any classes in the ignore list (typically just containing the classes used by the IDE). If it isn’t in the ignore list, the component is passed through a series of filters that make it visible to the model. However, there are a few caveats:
This scheme only works with Swing and AWT interfaces. GUI’s using the SWT (http://eclipse.org) are invisible to the model
Custom components, ones that are specialized hybrids or that have custom rendering, are not accessible without developing a customized gui processing delegate. An example of this can bee seen in the actr.interfaces.swing.component.ShapeComponentDelegate class which processes our custom JshapeComponent
Basic rendering of figures can be done using the JshapeComponent which allows you to add points and lines to the component for rendering. These points and lines are then visible to the model. Further shapes will be added in the future as the need arises
Components must exist within a valid component tree. Components have many children and only one parent, except for Windows which have no parent. If a component is processed that is not a window and has no parent, it will be ignored.
GUI components are processed asynchronously. This means that there may be a delay of up to 500 msecs before the model is actually able to see the interface changes. This only occurs with really large GUIs. Productions should be designed accordingly. However, a hack has been implemented which will allow the model to always see things immediately, but it comes at a cost of visual searches taking more realtime [much more]
RealityInterface.doc
jACT-R & RealityInterface
jACT-R has an abstraction layer between the model (including its perceptual/motor extensions) and the real world. This is accomplished by the RealityInterface and its supporting classes. The RealityInterface is responsible for routing afferent and efferent events between the model and the real world. More specifically, the RealityInterface (RI) passes events between the model and a set of RealityInterfaceComponents (RIC).
The RIC is meant to be the element that interfaces with the real world, or a simulation, and converts that data into a form specified by some other element within the model. This is clearer with an example:
jACT-R is able to “view” the screen because of the SwingRealityInterfaceComponent. The Swing-RIC listens to the AWTEventThread (standard GUI event thread in Java) for GUI events. It then translates the GUI widgets into a format that is specified by the VisualExtension. The VisualExtension is then able to manage this information so that visual searches and visual chunk encoding works correctly. Without changing any of the visual interface, we can swap out the Swing-RIC with the Java3D-RIC (which translates a Java3D simulation into spatial and visual information) and the model can see in the 3D simulation world.
The RealityInterfaceComponents allow you to swap out how the model deals with the world, without changing any of the model code.
The RICs, since they deal with the real world, are responsible for the creation and deletion of elements that the RI and the rest of the model can interact with. These elements represent real objects, and are dubbed RealObjects. RealObjects have a series of key-value pairs to set their properties.
The VisualExtension specifies a set of properties that RealObjects must have if they are to be visible to it. In the above example, the Swing-RIC translates the GUI widgets into these key-value pairs for each widget.
Visual Extension Properties
Key: Value
“visual.visible”: Boolean : is this component visible
“visual.location”: java.awt.geom.Point2D
“visual.foreground”: Java.awt.Color
“visual.background”: Java.awt.Color
“visual.size”: Double
“visual.width”: Double
“visual.height”: Double
“visual.depth”: Double : depth of the object
“visual.last.location”:
“visual.last.foreground”:
“visual.last.background”:
“visual.last.size”:
“visual.last.width”:
“visual.last.height”:
“visual.last.depth”:
How to created a new RIC:
Implement actr.reality.interfaces.RealityInterfaceComponent
a. RICs can provide numerous services. A service is signal that the RIC will set the properties of the RealObjects for a specific unit. I.e. anything wanting to process visual information for the VisualExtension should provide RealityInterface.VISUAL
b. refreshAll will iterate over all the RealObjects that it is aware of, process the properties, and pass the appropriate AfferentEvents to the RealityInterface.
c. realObjectRemoved will do what it says
Connect the RIC with the sensors, or simulation that it is being made for. The Swing-RIC has its own processing thread so that it can process AWTEvents off of the AWTEventThread, which would slow the graphical system down significantly.
If the RIC can take signals from the model, specifically EfferentEvents, the RIC should implement EfferentEventListener. Likewise, it is often a good idea to have the RIC operate in its own thread. This way, the EfferentEvent can be asynchronous with the model thread. This will reduce the processing load of the model thread if events are frequent.
Attach the RIC to the RealityInterface. Currently you can only do this programmatically. Sorry.
To Do.jpage
ModifyAction & RemoveAction do not support chunkNames, variableNames, or slots
updating.txt
XML format:
.. must now be formatted as
must now be formatted as
As part of https://github.com/amharrison/jactr-eclipse/issues/15, I'm removing old documents from org.jactr. Those contents that are still relevant should be added to the wiki.
divergence.doc
jACT-R Divergences
In the design and implementation of jACT-R we have attempted to maintain complete compatibility with the Lisp implementation. However, issues sometimes arise that forced us to diverge from ACT-R proper. Below is a listing of the divergences and the rationale behind them.
Core
PM
PM Notes.doc
PM Notes
jACT-R is able to see Swing GUI interfaces by listening to all the GUI events from the AWTEventThread. As events are processed, the system checks to see if the GUI component in question is a descendent of any classes in the ignore list (typically just containing the classes used by the IDE). If it isn’t in the ignore list, the component is passed through a series of filters that make it visible to the model. However, there are a few caveats:
RealityInterface.doc
jACT-R & RealityInterface
jACT-R has an abstraction layer between the model (including its perceptual/motor extensions) and the real world. This is accomplished by the RealityInterface and its supporting classes. The RealityInterface is responsible for routing afferent and efferent events between the model and the real world. More specifically, the RealityInterface (RI) passes events between the model and a set of RealityInterfaceComponents (RIC). The RIC is meant to be the element that interfaces with the real world, or a simulation, and converts that data into a form specified by some other element within the model. This is clearer with an example: jACT-R is able to “view” the screen because of the SwingRealityInterfaceComponent. The Swing-RIC listens to the AWTEventThread (standard GUI event thread in Java) for GUI events. It then translates the GUI widgets into a format that is specified by the VisualExtension. The VisualExtension is then able to manage this information so that visual searches and visual chunk encoding works correctly. Without changing any of the visual interface, we can swap out the Swing-RIC with the Java3D-RIC (which translates a Java3D simulation into spatial and visual information) and the model can see in the 3D simulation world. The RealityInterfaceComponents allow you to swap out how the model deals with the world, without changing any of the model code. The RICs, since they deal with the real world, are responsible for the creation and deletion of elements that the RI and the rest of the model can interact with. These elements represent real objects, and are dubbed RealObjects. RealObjects have a series of key-value pairs to set their properties. The VisualExtension specifies a set of properties that RealObjects must have if they are to be visible to it. In the above example, the Swing-RIC translates the GUI widgets into these key-value pairs for each widget. Visual Extension Properties Key: Value “visual.visible”: Boolean : is this component visible “visual.location”: java.awt.geom.Point2D “visual.foreground”: Java.awt.Color “visual.background”: Java.awt.Color “visual.size”: Double “visual.width”: Double “visual.height”: Double “visual.depth”: Double : depth of the object “visual.last.location”: “visual.last.foreground”: “visual.last.background”: “visual.last.size”: “visual.last.width”: “visual.last.height”: “visual.last.depth”:
How to created a new RIC:
To Do.jpage
updating.txt