ACT-R 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 • I’ll be at the Saturday Demo session

4. 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!

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 doesn’t run all ACT-R 4 models now • Models can be updated often trivially • Big reason • =retreival>

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

11. 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

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

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. A buffer is the interface through which the central production system interacts with other modules in the system. Definition of a Buffer

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. =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

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. -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

22. +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

23. 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

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 isn’t • 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. 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) ) Only change

32. 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 INITIALIZE-ADDITION 0.000: ADDITION PRODUCTION BUFFER-TEST GOAL 0.050: ADDITION PROCEDURAL FIRE-PRODUCTION INITIALIZE-ADDITION 0.050: ADDITION PRODUCTION MODIFY-BUFFER-CHUNK GOAL 0.050: ADDITION PRODUCTION SEND-MODULE-REQUEST RETRIEVAL 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 INCREMENT-SUM 0.100: ADDITION PRODUCTION BUFFER-TEST GOAL 0.100: ADDITION PRODUCTION BUFFER-TEST RETRIEVAL 0.150: ADDITION PROCEDURAL FIRE-PRODUCTION INCREMENT-SUM 0.150: ADDITION PRODUCTION MODIFY-BUFFER-CHUNK GOAL 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 RETRIEVAL 0.150: ADDITION PROCEDURAL CONFLICT-RESOLUTION 0.200: ADDITION DECLARATIVE RETRIEVING-CHUNK A 0.200: ADDITION DECLARATIVE SET-BUFFER-CHUNK RETRIEVAL A 0.200: ADDITION PROCEDURAL CONFLICT-RESOLUTION 0.200: ADDITION PROCEDURAL SELECT-PRODUCTION INCREMENT-COUNT 0.200: ADDITION PRODUCTION BUFFER-TEST GOAL 0.200: ADDITION PRODUCTION BUFFER-TEST RETRIEVAL 0.250: ADDITION PROCEDURAL FIRE-PRODUCTION INCREMENT-COUNT 0.250: ADDITION PRODUCTION MODIFY-BUFFER-CHUNK GOAL 0.250: ADDITION PRODUCTION CLEAR-BUFFER RETRIEVAL 0.250: ADDITION DECLARATIVE ADD-CHUNK-TO-DM A from buffer RETRIEVAL 0.250: ADDITION PRODUCTION SEND-MODULE-REQUEST RETRIEVAL 0.250: ADDITION PROCEDURAL CONFLICT-RESOLUTION … The traces

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 production’s 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 +eval> 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 don’t 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