ACTR 6

1
ACT-R 6

• The Proposals and The Prototype

2
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

3
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
• Ill be at the Saturday Demo session

4
Last years 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!

5
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

6
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

7
Other Issues

• Buffers and sources of activation
• Support for multiple models
• Several requests over the past year
• Minor programming concerns
• Gentemp
• Clear-all

8
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 doesnt run all ACT-R 4 models now
• Models can be updated often trivially
• Big reason
• retreivalgt

9
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

10
(No Transcript)
11
The meta-process

• The systems scheduler
• Maintains the clock
• Controls the flow of events
• Based on ACT-R/PMs master-process
• A simple discrete event sequencer
• Not a component of the theory

12
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

13
Chunks

• Still the units of declarative knowledge
• The ACT-R 5 theory claimed they enter DM from the
  buffers
• Implementation didnt 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

14
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

15
Open issues with Modules

• Can they interact outside of the
  buffers/productions?
• Can one module have multiple buffers?

16
Definition of a Buffer

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

17
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

18
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

19
buffergt

• 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

20
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

21
-buffergt

• 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

22
buffergt

• Relates to the buffers module
• LHS
• Requests the modules 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

23
Back to Buffers

• Because all are treated the same they will be
  internal to the system
• Module writers only need to specify a buffers
  name
• The implementation handles the details

24
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?

25
Buffers and Base-Level Learning

• Generalization of current mechanism across
  buffers
• Any LHS reference regardless of buffer counted
• Merged chunks have references added

26
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

27
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

28
What it isnt

• Fast
• Robust
• Well documented (other than the meta-process)
• Useful for actual modeling
• Likely to outlive the specification

29
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

30
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

31
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)
• )

32
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-GOAL
• 0.000 ADDITION PROCEDURAL CONFLICT-RESOLUTION
• 0.000 ADDITION PROCEDURAL SELECT-PRODUCTION INITI
  ALIZE-ADDITION
• 0.000 ADDITION PRODUCTION BUFFER-TEST GOAL
• 0.050 ADDITION PROCEDURAL FIRE-PRODUCTION INITIA
  LIZE-ADDITION
• 0.050 ADDITION PRODUCTION MODIFY-BUFFER-CHUNK GOA
  L
• 0.050 ADDITION PRODUCTION SEND-MODULE-REQUEST RET
  RIEVAL
• 0.050 ADDITION PROCEDURAL CONFLICT-RESOLUTION
• 0.100 ADDITION DECLARATIVE RETRIEVING-CHUNK F
• 0.100 ADDITION DECLARATIVE SET-BUFFER-CHUNK
  RETRIEVAL F
• 0.100 ADDITION PROCEDURAL CONFLICT-RESOLUTION
• 0.100 ADDITION PROCEDURAL SELECT-PRODUCTION INCRE
  MENT-SUM
• 0.100 ADDITION PRODUCTION BUFFER-TEST GOAL
• 0.100 ADDITION PRODUCTION BUFFER-TEST RETRIEVAL
• 0.150 ADDITION PROCEDURAL FIRE-PRODUCTION INCREM
  ENT-SUM
• 0.150 ADDITION PRODUCTION MODIFY-BUFFER-CHUNK GOA
  L
• 0.150 ADDITION PRODUCTION CLEAR-BUFFER RETRIEVAL
  
• 0.150 ADDITION DECLARATIVE ADD-CHUNK-TO-DM F
  from buffer RETRIEVAL
• 0.150 ADDITION PRODUCTION SEND-MODULE-REQUEST RET
  RIEVAL

33
Details of the trace

• Columns are
• Time Model Module Action Details

34
Things to note from the trace

• All buffer changes are reported
• Including at time 0 from the goal focus
• All of the selected productions tests are
  reported
• The model does the same thing as the original

35
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

36
Count.v1

• Minimal change to ACT-R 5 version
• Shows the eval buffer being used instead of
  !output! in increment and stop productions
• evalgt
• isa output
• message num

37
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

38
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

39
Semantic.v2

• Declares the tag chunks outside of DM to avoid
  the merging since they dont have any meaningful
  differences
• As with count.v2 tests retrieval state to avoid
  using an explicit start marker

40
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

41
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

42
Test2

• Shows that different models can have different
  settings for the parameters
• Also shows a use of the generalized direct
  request syntax

43
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