Theoretical functionality in jACT-R is defined and extended through the use of modules. As modules are developed and refined, their specification and details will be added here.
The declarative module interface defines the methods necessary to asynchronously create and encode chunktypes and chunks. It also includes methods for disposing of temporary chunks (or cleaning up chunks during model disposal), and both partial and exact search methods.
An abstract implementation is provided that handles all of the basics (including event firing) requiring implementations of the actual create, add, copy, dispose and search methods.
There are specific extension interfaces for theory revisions four and five.
The default implementation conforms to theory revision six.
The AbstractDeclarativeModule provides most of the nitty-gritty implementation details that are required for the IDeclarativeModule. However, it leaves the theoretically relevant components (creating, encoding, searching of chunks/types) to the client.
The DefaultDeclarativeModule is the general starting point for any theory specific implementation. It is thread safe, provides all the required functionality, and also provides access to the three most commonly required extension points. Specifically, you can provide it with:
Default declarative module for ACT-R 6. Carries with it some reminents from ACT-R 5. (namely support for similarities). This module uses the IDeclarativeConfigurator to set the various activation equations used by the chunks (i.e., IBaseLevelActivationEquation, ISpreadingActivationEquation, IRandomActivationEquation)
Associations in jACT-R are handled by IAssociativeLinkageSystem, which is handled by the Declarative module (often pulling the linkage system from a declarative learning module).
The linkage system provides methods for creating links, accessing their respective equations (for updating values) and a parameter handler to transform strings into lists of associative links. In conjunction with their declarative learning module, they will often install event listeners in order to install and update the links correctly.
Declarative learning is generally accomplished by an IDeclarativeLearningModule. Since the learning theories evolve faster than the rest of the architecture, there are significant differences between the various implementations and their expectations.
DefaultDeclarativeLearningModule4 provides the ACT-R 4 style of base-level learning and associative learning. It expects that the chunks created by the installed declarative module support the ISubsymbolicChunk4 interface, as well the associative linkage system to be the DefaultAssociativeLinkageSystem (which creates Link4 associative links).
Note: Theoretically outdated. Limited support available.
DefaultDeclarativeLearningModule6 extends the version for 4 by replacing the associative linkage system and providing an additional parameter for the MaximumAssociativeStrength.
The imaginal system is used to store intermediate problem state representations. Typically used in conjunction with the goal module which retains the goal state.
The imaginal system is time dependent (unlike the goal module), so all imaginal buffer operations take some (configurable) amount of time.
DefaultImaginalModule6 is the default implementation of the imaginal system.
It provides the imaginal buffer, and has parameters to manipulate the amount of time add and modify requests take.
The DefaultGoalModule6 provides a simple immediate buffer and little else.
DefaultMotorModule6 provides the functionality of the manual module in the lisp, but generalizes it over all possible muscles.
(exists, documentation pending)
DefaultVisualModule6 provides most of the visual functionality found within the lisp equivalent. It provides a fully extensible system for adding new feature maps (for visual searches), visual encoders (for converting percepts into chunks), and filters (for search time prioritizing). The time it takes to find or encode visual objects is also configurable.
Those wishing to add new functionality to the system will typically implement the following delegate interfaces or their abstract implementations:
To add any of these, merely provide the full class name of the implementor as a parameter name, and set its value to true. Setting the value to false will remove the named class.
(from the lisp)
The procedural module is the second primary module that all models must have (the other being declarative). It is responsible for managing all productions in the model.
DefaultProceduralModule6 provides the primary procedural functionality. The most common points of extension are in conflict set assembly, production instantiation and selection. Each has its own delegate interface (IConflictSetAssembler, IProductionSelector, IProductionInstantiator). This implementation is also responsible for enforcing strict harvesting. For any buffer that has strict harvesting enabled (IActivationBuffer.isStrictHarvestingEnabled()), the module checks to see if the production matching on that buffer also includes a remove. If not, one is added automatically.
The default production selector will choose the production with the highest 'ExpectedUtility', if that is not defined (i.e. no procedural learning module is installed or enabled), it will use 'Utility'.
Procedural learning has undergone much evolution since the early days of ACT-R.
DefaultProceduralLearningModule6 provides access to production compilation and utility learning. Utility learning utilizes the IExpectedUtilityEquation. Production compilation delegates to the IProductionCompiler. The module is responsible for propagating rewards backward in time. Utility learning is fully functional, and can even support the learning of utility noises (UtilityNoiseLearningExtension). The 'Reward' parameter determines how a production participates in the utility learning. A numeric value will result in that production starting a chain of rewards back propogating after it fires. A value of 'default' or NaN, will mark the production as participating the utilty learning, but not starting it. 'skip' or -Infinity will result in the production being skipped, but utility learning continues to propogate. Finally, you can mark a production with 'stop' or Infinity to halt reward processing at this production (not giving any credit to it or prior productions).
Production compilation, while implemented, is based directly on the lisp version and is not as extensible as desired. The long term goal is to get it using the ICompilableContext which describes buffers in terms of their critical properties for production compilation.
This implementation also has the ability reward productions selectively based upon what buffers they act upon. Obviously, we want to reward productions that act on the goal and imaginal buffers, but there exist a class of productions where rewards are less relevant. Goal-free or reflexive productions are often used for basic model behavior that exists below the intentional level. By limiting the productions to be rewarded to those that access the "IncludeBuffers" parameter, you can exclude some productions from rewards, without effecting the rest of the reward chain.
IRandomModule provides a centralized location for the generation of random numbers. Any module that relies upon randomness should check for the existence of a random module (e.g. (IRandomModule) model.getModule(IRandomModule.class)) and use the returned instance. If no random module is installed, random behavior should not be enabled. This allows one to easily enable/disable random behavior. By centralizing the random generation, you can more easily guarantee repeatable behavior for a given random seed.
There is a single default implementation.
The basic retrieval module template. All retrieval module implementations must support the parameter RetrievalThreshold, which defines the minimum chunk activation value that a chunk must have to be accessible.
This module class also provides access to the model-wide retrieval time equation. And an asynchronous retrieval method. Note: the retrieval method need not actually be asynchronous, but support is provided at this level since retrofitting is such a pain.
There is currently a single default implementation of this module.
The default implementation provides access to the basic retrieval functionality, as well as exposes the parameters defined in 4.0 (LatencyFactor,LatencyExponent) and permits partial matching (if the declarative module's PartialMatchingEnabled is true).
Since it can be so useful for those that aren't completely concerned with retrieval behavior, the module also permits the use of indexed retrievals. If you already have a reference to a specific chunk (say as a slot value), you can insert it directly into the retrieval buffer to access it on the next cycle. To enable this, set the EnableIndexedRetrievals to true. Otherwise, +retrieval> =chunkRef will merely create a pattern based on that chunk and search for it, as is the canonical behavior.
Unlike most other buffers, the retrieval buffer provided by this module does not copy the chunk on insertion. It won't permit you to make modifications (=retrieval> slot newValue) will always fail. This was done to prevent unnecessary copying. Reference counts/access times are still consistent.
Actual retrievals are merely delegated to the declarative module. If the declarative module is asynchronous, so too shall the retrievals.
The module now supports parameter overrides when specifying a retrieval. These overrides hold for the duration of that single retrieval only. See below for options.
The retrieval module only resets declarative finsts with a clear request.
In Lisp parlance:
+retrieval>
isa clear
all true