ACT-R 6

The Proposals and The Prototype

What is ACT-R 6?

• A reimplementation of ACT-R 5

• No major theory changes– Minor clean-up– Updates to production compilation from

ongoing research

• New programming level components

• Projected arrival is Workshop 2005

Overview

• Background information on ACT-R 6• Discuss proposals and open issues with ACT-R 6

at this point– Main objective– feel free to interrupt or ask questions

• Describe the prototype ACT-R 6 system – Not likely in the time available

• Show concrete examples of some of the proposals– Almost definitely not– I’ll be at the Saturday Demo session

Last year’s Workshop

• Start fresh with ACT-R 6– Not a patching up of ACT-R 5

• Go from a specification to implementation– Good software engineering

• I have the task of specification– Be careful what you suggest!

Where do things stand?

• Several versions of the proposals discussed

• Not a lot of specification yet– A few UML diagrams of the overall breakdown– Some interfacing specification of internals

• An initial prototype created

The Major Proposals

• A lot like ACT-R 5

• Clearly specify the buffer mechanism– What is a buffer

– How does it work

• Unify the scheduler with ACT-R/PM– One source of time

• Make the whole system “Modular” – Internally and externally

Other Issues

• Buffers and sources of activation

• Support for multiple models– Several requests over the past year

• Minor programming concerns– Gentemp

– Clear-all

One Big Change

• Not backward compatible– Will not run ACT-R 5 or older models unchanged

• Not as big a change as it seems– ACT-R 5 doesn’t run all ACT-R 4 models now

• Models can be updated often trivially

• Big reason– =retreival>

System Overview

• Based on ACT-R/PM

• A central scheduler – the meta-process

• All the components are modules which may have buffers associated with them

• A model consists of a set of modules, chunks, and productions

The meta-process

• The system’s scheduler– Maintains the clock– Controls the flow of events

• Based on ACT-R/PM’s master-process

• A simple discrete event sequencer

• Not a component of the theory

A model

• New system level abstraction – old concept

• Basically the same as a model was before

• A little more flexible in configuration– Can essentially pick and choose modules

• A little more rigid in specification– Examples later

Chunks

• Still the units of declarative knowledge• The ACT-R 5 theory claimed they enter

DM from the buffers– Implementation didn’t quite correspond

• New system truer to the theory• DM is a separate module• Holds only the chunks from the buffers

– Or those initially placed there

Modules

• Generalization of the module class from ACT-R/PM

• A specification of a subsystem– All pieces now individual modules

• Procedural, declarative, visual, etc

• Interact with central production system through buffers

• Mechanism for defining new ones that does not force an implementation – Not discussed at this time

Open issues with Modules

• Can they interact outside of the buffers/productions?

• Can one module have multiple buffers?

Definition of a Buffer

A buffer is the interface through which the central production system interacts with other modules in the system.

Buffers and Productions

• Change the production syntax to better interact with the buffers

• Restrict it to only buffer accesses and requests– No LHS retrievals– No !eval!, !bind!, !send-command!, etc.

• Provide a cleaner mechanism for accessing a modules state than the *–state buffers

New Production Syntax

• Extend the ACT-R 5 RHS specifications of - and + to the LHS

• Explicitly state what each does

• Treat all buffers equally

• Generalize the “direct request” mechanism– See proposal for specific details

=buffer>

• Relates to the chunk in the buffer

• LHS– Harvest the chunk

• Same as it always was

• RHS– Modify the chunk in buffer

• Again same as before

Strict Harvesting

• Speculative proposal• A LHS =buffer harvesting takes the chunk out of

the buffer • A RHS modification would reseed it• Avoids some initial learning confusion (maybe)• Addresses a problem for production compilation• How often is a buffer tested, not modified, and

then needed again later?– Easy to keep it around if necessary

-buffer>

• Relates to the buffer

• LHS– Tests that the buffer is empty

• New operation

• RHS– Clears the chunk from the buffer (only)

• Cleaner than with ACT-R 5, which, depending on the buffer, would also reset the module as well

+buffer>

• Relates to the buffer’s module • LHS

– Requests the module’s state• Replaces the *–state buffers

• Adds some new flexibility for modules

• RHS– Send a request to the module

• Same as current system

• Includes an implicit clearing of the buffer first

Back to Buffers

• Because all are treated the same they will be internal to the system

• Module writers only need to specify a buffer’s name

• The implementation handles the details

Buffers and Declarative Memory

• Chunks cleared from buffers will merge into DM

• Similar to the existing goal merging mechanism– No duplicate chunks in DM

• Open issue – what about an unharvested chunk?

Buffers and Base-Level Learning

• Generalization of current mechanism across buffers

• Any LHS reference regardless of buffer counted

• Merged chunks have references added

The Prototype

• Objective is still a specification

• Investigate the feasibility of proposals before investing in a full specification

• Some of the open issues easier to discuss in a concrete form

• OR Dan reverts to the old ways…

What is it?

• A very simple mock up of the proposed system organization

• It demonstrates the meta-process and model abstractions• Contains 5 modules implementing the system

– Procedural, declarative, goal, eval, and parameters

• Includes an improved naming system– “New” names start at 0 after every reset– Uninterns names on reset if unused – Recent idea (not even in prototype) may even avoid interning…

• Sufficient to run the unit 1 models and some other examples

What it isn’t

• Fast

• Robust

• Well documented (other than the meta-process)

• Useful for actual modeling

• Likely to outlive the specification

The examples

• 10 example models plus the 3 ACT-R 5 unit 1 models for comparison

• Demonstrate various pieces of the proposal

• General note– Can all be compiled before loading if desired

Addition.v1

• Shows the minimum change necessary to convert an existing ACT-R 5 model– Of course not all would be that easy

• First encounter with the very detailed trace– No switches to simplify that in the prototype

• No mention of the meta-process necessary

Only change

• From this:

(clear-all)(pm-reset)(sgp :LF 0.05 :Esc T)…

(goal-focus second-goal)

• To this:

(clear-all)(define-model addition(sgp :LF 0.05 :Esc T)…

(goal-focus second-goal))

The traces Time 0.000: Initialize-Addition Selected Time 0.050: Initialize-Addition Fired Time 0.100: F Retrieved Time 0.100: Increment-Sum Selected Time 0.150: Increment-Sum Fired Time 0.200: A Retrieved Time 0.200: Increment-Count Selected Time 0.250: Increment-Count Fired Time 0.300: G Retrieved Time 0.300: Increment-Sum Selected Time 0.350: Increment-Sum Fired Time 0.400: B Retrieved Time 0.400: Increment-Count Selected Time 0.450: Increment-Count Fired Time 0.450: Terminate-Addition Selected Time 0.500: H Retrieved Time 0.500: Terminate-Addition Fired Time 0.500: Checking for silent events. Time 0.500: * Nothing to run: No productions, no events.

0.000: ADDITION GOAL SET-BUFFER-CHUNK GOAL SECOND-GOAL0.000: ADDITION PROCEDURAL CONFLICT-RESOLUTION0.000: ADDITION PROCEDURAL SELECT-PRODUCTION INITIALIZE-ADDITION0.000: ADDITION PRODUCTION BUFFER-TEST GOAL0.050: ADDITION PROCEDURAL FIRE-PRODUCTION INITIALIZE-ADDITION0.050: ADDITION PRODUCTION MODIFY-BUFFER-CHUNK GOAL0.050: ADDITION PRODUCTION SEND-MODULE-REQUEST RETRIEVAL0.050: ADDITION PROCEDURAL CONFLICT-RESOLUTION0.100: ADDITION DECLARATIVE RETRIEVING-CHUNK F0.100: ADDITION DECLARATIVE SET-BUFFER-CHUNK RETRIEVAL F0.100: ADDITION PROCEDURAL CONFLICT-RESOLUTION0.100: ADDITION PROCEDURAL SELECT-PRODUCTION INCREMENT-SUM0.100: ADDITION PRODUCTION BUFFER-TEST GOAL0.100: ADDITION PRODUCTION BUFFER-TEST RETRIEVAL0.150: ADDITION PROCEDURAL FIRE-PRODUCTION INCREMENT-SUM0.150: ADDITION PRODUCTION MODIFY-BUFFER-CHUNK GOAL0.150: ADDITION PRODUCTION CLEAR-BUFFER RETRIEVAL0.150: ADDITION DECLARATIVE ADD-CHUNK-TO-DM F from buffer RETRIEVAL0.150: ADDITION PRODUCTION SEND-MODULE-REQUEST RETRIEVAL0.150: ADDITION PROCEDURAL CONFLICT-RESOLUTION0.200: ADDITION DECLARATIVE RETRIEVING-CHUNK A0.200: ADDITION DECLARATIVE SET-BUFFER-CHUNK RETRIEVAL A0.200: ADDITION PROCEDURAL CONFLICT-RESOLUTION0.200: ADDITION PROCEDURAL SELECT-PRODUCTION INCREMENT-COUNT0.200: ADDITION PRODUCTION BUFFER-TEST GOAL0.200: ADDITION PRODUCTION BUFFER-TEST RETRIEVAL0.250: ADDITION PROCEDURAL FIRE-PRODUCTION INCREMENT-COUNT0.250: ADDITION PRODUCTION MODIFY-BUFFER-CHUNK GOAL0.250: ADDITION PRODUCTION CLEAR-BUFFER RETRIEVAL0.250: ADDITION DECLARATIVE ADD-CHUNK-TO-DM A from buffer RETRIEVAL0.250: ADDITION PRODUCTION SEND-MODULE-REQUEST RETRIEVAL0.250: ADDITION PROCEDURAL CONFLICT-RESOLUTION…

Details of the trace

• Columns are:

Time: Model Module Action Details

Things to note from the trace

• All buffer changes are reported– Including at time 0 from the goal focus

• All of the selected production’s tests are reported

• The model does the “same thing” as the original

Addition.v2

• Shows how to create initial chunks without putting them in DM– The goal is only in DM after completion– Trivial for this model, but can be an issue for

other tasks where retrieval of past goals is important

• Terminate-addition shows strict harvesting clearing the goal chunk

Count.v1

• Minimal change to ACT-R 5 version

• Shows the eval buffer being used instead of !output! in increment and stop productions

+eval>

isa output

message =num

Count.v2

• Demonstrates that by testing the state of the retrieval buffer and module one can remove the explicit step slot of the goal

• For this example, it may not actually be any clearer however

Semantic.v1

• Minimal change from the ACT-R 5 version

• Shows that chunk merging occurs for all chunks entering DM even initial ones

• Still runs because the names are still valid

Semantic.v2

• Declares the “tag” chunks outside of DM to avoid the merging since they don’t have any meaningful differences

• As with count.v2 tests retrieval state to avoid using an explicit start marker

All-three-together

• Contains the v2 version of each of the unit 1 models

• Runs them all in parallel– In the same meta-process

• All of the traces match the originals

Test1

• Shows creation of a new meta-process • Creates two models one in each meta-

process (the default and the new one)• Can run either model without impacting the

time of the other• Demonstrates that new chunk names start at

0 and identical names can occur in different models

Test2

• Shows that different models can have different settings for the parameters

• Also shows a use of the generalized direct request syntax

Eval-test

• Runs the eval buffer through some tests

• Shows the equivalent of a LHS !eval!

• Shows the equivalent of a RHS !eval!

• Shows how to bind a variable to a result