Goal Dependency Set Primer - EECS
Download
Report
Transcript Goal Dependency Set Primer - EECS
A
C
B
D
E
context (all superstates)
substate
1
3
2
4
GDS = {A, B, C, D}
A Goal Dependency Set Primer
Robert Wray
Soar 24
10 Jun 2004
2004 Soar Technology, Inc. 10 Jun 2004 Robert Wray Slide 1
5
A
C
B
D
E
context (all superstates)
substate
Why a Primer? Why now?
1
3
2
4
5
GDS = {A, B, C, D}
Covered in 1996/1997/1998/2001 Soar workshops
Soar community changed a lot since GDS 1st conceived
No Soar-specific documentation other than Soar 8 release
notes
Frustrated users
(draft) Soar GDS documentation now available
Motivation for Goal Dependency Set (GDS)
What the GDS does
Constraints on agent design
Memory management
Operator elaborations
Reentrancy
Kernel level view
Introduces other new (Soar 8) mechanisms
2004 Soar Technology, Inc. 10 Jun 2004 Robert Wray Slide 2
Terminology
I(nstantiation)-support
Justification-based truth maintenance system
Assertion persists only as long as it justified
I-support: Production instantiation provides
justification
Applies to
State elaborations
Operator proposals (Soar 8)
Operator elaborations (Soar 8, o-support-mode 4)
Preference productions
2004 Soar Technology, Inc. 10 Jun 2004 Robert Wray Slide 3
A
A
i-supported WME
Terminology
O(perator)-support
1
o-supported WME
2004 Soar Technology, Inc. 10 Jun 2004 Robert Wray Slide 4
dependency
(LHSRHS)
A
Operator applications
remain in memory
regardless of
As
justification/instantiation
New preferences are required
to change an O-supported WME
(e.g., reject)
Applies to
State elaborations
Operator proposals (Soar 8)
Preference productions
retracted WME
context (all superstates)
substate
1
A
context (all superstates)
substate
As
1
A
A
i-supported WME
Motivation for GDS
1
o-supported WME
Problem space/state
interactions with
persistence
context (all superstates)
substate
1
As
A
Previous assertions can
become inconsistent with
newer information
context (all superstates)
substate
Learn a rule that has conditions
that can never be simultaneously
satisfied
1
As
Non-contemporaneous constraints
in chunks
A
B
context (all superstates)
substate
1
As
Both problems require lots of low-level
knowledge design, possibly incomplete
2004 Soar Technology, Inc. 10 Jun 2004 Robert Wray Slide 5
dependency
(LHSRHS)
# A&B are mutually exclusive
sp {non-contemporaneous*chunk
(state <s> ^attribute A
^attribute B)
(<s> ^result 3)
A
Symbol level “quirks”
in Soar 7
retracted WME
A
2
B
3
context (all superstates)
substate
As
1
2
3
GDS Solution
GDS ensures persistent WMEs within a
substate are sensitive to superstate
context(s)
State, not individual element justification
GDS := “I-support for states”
Justification is updated dynamically as new
persistent WMEs are asserted
GDS misnomers
States, not “goals”
GDS is the data structure, not the process
Process: Dynamic Hierarchical Justification
2004 Soar Technology, Inc. 10 Jun 2004 Robert Wray Slide 6
A
A
i-supported WME
GDS Solution
A
1
o-supported WME
dependency
(LHSRHS)
GDS is NIL until/unless o-supported
elements have been asserted in the local state
C
B
retracted WME
context (all superstates)
substate
1
A
C
B
GDS = { }
GDS uses an algorithm comparable
to chunking’s backtrace to establish
dependencies for persistent WME
D
context (all superstates)
substate
1
3
2
A
C
B
GDS = {A, D}
D
E
context (all superstates)
substate
GDS is updated dynamically as
new persistent assertions are
created in the substate
1
3
2
4
A
C
B
substate
1
3
2
GDS = {A, B, C, D}
2004 Soar Technology, Inc. 10 Jun 2004 Robert Wray Slide 7
E
context (all superstates)
GDS = {A, B, C, D}
Not every new persistent WME
requires a backtrace
D
4
5
A
A
i-supported WME
GDS Solution
Soar monitors WME
changes for WMEs that
appear in a state’s
GDS…
A
1
o-supported WME
C
B
retracted WME
dependency
(LHSRHS)
D
context (all superstates)
substate
1
3
2
GDS = {A, B, C, D}
When a GDS WME is retracted, Soar
immediately removes the impasse state
(retraction of the GDS state)
2004 Soar Technology, Inc. 10 Jun 2004 Robert Wray Slide 8
5
4
A
B
C
D
context (all superstates)
no substate
Alternative Solution
GDS assumes it is cheaper to regenerate
dependent assertions than to compute which WME
changes should be associated with which
persistent WMEs.
A
C
B
D
context (all superstates)
substate
1
3
2
4
A
S-support retracted only dependent o-supported
WMEs, rather than the entire state
5
C
B
D
context (all superstates)
substate
1
3
2
4
2004 Soar Technology, Inc. 10 Jun 2004 Robert Wray Slide 9
5
S-support was potentially
expensive and led to a number
of technical problems
Impact of the GDS on
agent design
Where to store o-supported assertions
Depends on reason persistence was used
Operator elaborations
Operator elaborations now receive I-support
O-support-mode 4 (Soar 8.5.1)
I-support ensures no effect on GDS
Reentrant problem spaces
Any substate problem space can be interrupted
at any time
2004 Soar Technology, Inc. 10 Jun 2004 Robert Wray Slide 10
Where to assert
o-supported WMEs
Soar 21
Recurrent questions
Why shouldn’t I just put all o-supported WMEs
in the top state?
Shouldn’t everything have global persistence?
When should I return something to the top
state?
When should something have global persistence?
Answer:
Reason for creating o-supported structures will
tell you where they should be asserted
2004 Soar Technology, Inc. 10 Jun 2004 Robert Wray Slide 11
Soar 21
Categories of Persistence
Different reasons for using an operator to
assert a WME:
Non-monotonic reasoning
Hypothetical reasoning
Remembering
Avoiding expensive computations
(see Soar 21 for specific examples of each)
2004 Soar Technology, Inc. 10 Jun 2004 Robert Wray Slide 12
Soar 21
Guidelines
If your o-supported WME
is being created for:
It should be located in:
Non-monotonic R.
Hypothetical R.
Local state
- Want changes in context/situation to
be communicated to the local state
Remembering
Avoiding Recalculation
Top state
- Want to be able to remember these
things independent of any justification
Some combination of
first group with second
group
Top state
Replacing an old value to be remembered
(e.g., current-desired-speed) with a new one
requires global persistence
Conclusions:
• For most plan execution applications, all o-supported WMEs should
be asserted in the top state
• Inconvenient when o-support provided but not needed
2004 Soar Technology, Inc. 10 Jun 2004 Robert Wray Slide 13
Augmenting the
GDS Solution
Soar 7 has other persistent WMEs
context support (persistent operator selections)
Eliminated in Soar 8/operator selections are Isupported
“elaboration persistence” (interaction between isupport and o-support)
Soar 8 decision cycle
“Waterfall” (parallelism limited to prod firings w/i a goal)
O
U
TP
U
T
SELECT
INP
UT
ELABORATE
& COMPARE
Soar
Agent
PERSISTENT ELABORATION
PERSISTENT
STEP
INPUT PHASE
ELABORATION
ELABORATION
Soar 8 Decision Cycle
P
AP
LY
2004 Soar Technology, Inc. 10 Jun 2004 Robert Wray Slide 14
OUTPUT
PHASE
DECISION
PHASE
A
C
B
D
E
context (all superstates)
substate
Conclusions
1
3
2
4
5
GDS = {A, B, C, D}
GDS
+ Encourages reentrancy in design/simple, compact operator reps.
(more “Soar”-like implementations)
+ Provides a complete, architectural (reusable) solution to hierarchical
inconsistencies
+ Makes it much easier to use chunking in dynamic domains
- Breaks locality assumptions for most o-supported WMEs
- Not well documented/understood by Soar community at-large
- Not well implemented (“gradware”)
- Management of top-state WMEs not well codified/explored
For Soar systems focused on plan execution in dynamic
domains, most o-supported elements should be stored in the
top state.
GDS seems to provide little utility and lots of frustration for nonlearning systems (run-time flag?)
Function of documentation/understanding or a fundamental flaw?
2004 Soar Technology, Inc. 10 Jun 2004 Robert Wray Slide 15
A
C
B
D
E
context (all superstates)
substate
Additional Information
1
3
2
4
5
GDS = {A, B, C, D}
GDS Primer
http://www.speakeasy.org/~wrayre/soar/gds-primer.pdf
Thanks to Brian Magerko, Bob Mariner, Andy Nuxoll, and Glenn
Taylor for suggestions/comments on current draft
More feedback needed/appreciated
Papers describing motivations for Soar 8 & solution specifics
Wray, R.E. and J.E. Laird, An architectural approach to consistency in hierarchical
execution. Journal of Artificial Intelligence Research, 2003. 19: p. 355-398.
Wray, R.E. and R.M. Jones. Resolving Contentions between Initial and Learned
Knowledge. in Proceedings of the 2001 International Conference on Artificial
Intelligence. 2001. Las Vegas, NV.
Wray, R.E. and J.E. Laird. Maintaining consistency in hierarchical reasoning. in
Fifteenth National Conference on Artificial Intelligence. 1998. Madison, Wisconsin.
Wray, R., Ensuring Consistency in Hierarchical Architectures, PhD Thesis in
Computer Science & Engineering. 1998, University of Michigan: Ann Arbor.
Wray, R.E., J.E. Laird, and R.M. Jones. Compilation of Non-Contemporaneous
Constraints. in Proceedings of the Thirteenth National Conference on Artificial
Intelligence. 1996. Portland, Oregon: AAAI Press.
2004 Soar Technology, Inc. 10 Jun 2004 Robert Wray Slide 16