You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
General idea is to facilitate the creation of planning-like logical theories. Propositions are defined for states and actions (latter are assumed to be (and should be enforced) mutually exclusive, for now). Constraints dictate when a fluent is deleted or added (as a function of the previous state and action), and also the conditions under which an action may be executed. The update rule for fluent F:
S2.F <-> F+ \/ (S1.F /\ ~F-)
where we have,
S2.F: The updated fluent in successor state S2
S1.F: The previous value of the fluent
F+: Formula that dictates when the fluent is added
F-: Formula that dictate when the fluent is deleted
In other words, S2.F holds when it's made true, or when it's already true and not made false. The formulae F- and F+ must be defined for every class defining state fluent propositions.
Example Usage
Here is a simple theory that keeps track of an agent
Every new instance of @stateprop and @actionprop propositions can be logged as they are created. The .compile(...) will create a single version of all props, and these need to be cloned for every state in the horizon (and actions in between them). Prop names can be the original with @Si added for each layer i. Then all of the constraints need to be created for each state/action in the horizon (using the class-defined procedures).
Unclear if the use of bauhaus.And and bauhaus.Or inside those methods will work, as they likely need to be nnf variables by the time those constraints start to be formed. Flattening is also something that should probably be done automagically, as chains of conjunctions or disjunctions may be quite common.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Proposal Summary
General idea is to facilitate the creation of planning-like logical theories. Propositions are defined for states and actions (latter are assumed to be (and should be enforced) mutually exclusive, for now). Constraints dictate when a fluent is deleted or added (as a function of the previous state and action), and also the conditions under which an action may be executed. The update rule for fluent F:
where we have,
In other words, S2.F holds when it's made true, or when it's already true and not made false. The formulae F- and F+ must be defined for every class defining state fluent propositions.
Example Usage
Here is a simple theory that keeps track of an agent
Implementation Details
Every new instance of
@statepropand@actionproppropositions can be logged as they are created. The.compile(...)will create a single version of all props, and these need to be cloned for every state in the horizon (and actions in between them). Prop names can be the original with@Siadded for each layeri. Then all of the constraints need to be created for each state/action in the horizon (using the class-defined procedures).Unclear if the use of
bauhaus.Andandbauhaus.Orinside those methods will work, as they likely need to bennfvariables by the time those constraints start to be formed. Flattening is also something that should probably be done automagically, as chains of conjunctions or disjunctions may be quite common.Beta Was this translation helpful? Give feedback.
All reactions