filename: Pweak_info (version alpha-16) -- Created 20/Apr/94 -- Updated 12/Feb/98

This is an information file for the (simple) planning system "Pweak".  This 
file contains french accents and other special characters which may not be 
displayed nor printed correctly on non-apple Macintosh machines.  These 
characters are here below placed between " and ":

      Macintosh         LaTeX             HTML
        "¥"             \bullet           
  • "±" \pm "" \c{c} "ç" "ƒ" \'{E} "É" "Ž" \'{e} "é" "" \`{e} "è" "”" \^{\i} "î" "š" \"{o} "ö" "¯" \emptyset "Ø" "³" \geq "Ã" \sqrt{~} "Â" \neg "ª" author's name : ƒric Jacopin current e-mail : current fax number: +33 01 44 27 70 00 Acknowledgements :---------------------------------------------------------- Thanks to Mike Brady (Trinity College, Dublin, Ireland) for his great help on Open Prolog. Thanks to Claude Le Pape (Bouygues, Saint-Quentin en Yvelines, France) and Jean-Franois Puget (ILOG, Gentilly, France) for their help on Pweak and planning. Thanks to Mark Drummond (NASA Ames, USA), Bertram Fronhšfer (Technical University, Munich, Germany) and Subbarao Kambhampati (Arizona State University, Tempe, USA) for helpful discussions about planning. Special thanks to Philippe Morignot (Ilog, France), Pierre Regnier (IRIT, Toulouse, France) and Sylvie ThiŽbaux (IRISA, Rennes, France) for planning interactions. Thanks to FredŽric Bidaud and Brigitte Lamare (IRIT, Toulouse, France), first (forced) Pweak testers. Thanks to Jacqueline Zizi for her help on Mathematicaª. And thanks to Ramana Rao (Xerox PARC, USA) for making me aware that "there is so much need for development" and interacting with me about visualization. File contents :============================================================ ("¥" denotes a section while "¥¥" denotes a subsection) ¥ Introduction ¥ What is Pweak? ¥ Requirements ¥ Installation ¥¥ Contents of the Pweak folder ¥¥ Upgrading from an older version ¥ World language ¥ Action language ¥ Planning problem ¥ Plan language ¥ Plan existence problem ¥¥ Complexity of the plan existence problem ¥ Solution to the plan existence problem ¥ Plan modification operators (plan construction) ¥¥ Definition (what the plan modification operators are) ¥¥ Semantics (applicability of plan modification operators) ¥¥ Movements (how Pweak chooses to apply plan modification operators) ¥¥ Precondition achievement ¥ Running Pweak on examples ¥¥ Plan existence tuples ¥¥ Adding your examples ¥¥ What options for which planners? ¥ Tracing Pweak ¥ Pweak's user files ¥¥ The 'configurations' file ¥¥ The 'constraints' file ¥¥ The 'examples_list' file ¥¥ The 'preferences' file ¥ Known bugs References (books, published articles, internal technical reports, manuals, etc) can be found at the end of some sections. References begin with the three characters [*] (thus, searching for [*] in this document is searching for the references). ¥ What is Pweak? :========================================================= Pweak is a planning system written in Prolog which is designed to help testing classical non linear planning procedures (positive atomic formulas, Strips action description, a plan is a partial order, plan modification planning is in the partial plan space). Not only can you simulate the usual planning procedures of the literature (such as Tweak, SNLP, UA and others) but also you can degrade those procedures in selecting some parts of them, or else combine options in order to get new procedures. To simulate a non linear planning procedure, menus and dialog boxes are provided. Search can be selected for one, all or a certain number of solutions. Solutions can be automatically saved in a file together with some tracing informations. Options can be pre-selected from a preferences file. User-constraints are possible. A Mathematicaª package is provided to analyze and visualize the search space visited by the planning procedures that have been simulated. More than 30 examples (from the literature and others) are provided. Pweak is copyright ©1994Ñ1998, ƒric Jacopin. The Pweak planning system should be considered as a free research domain software. This 'free research domain software' here has the following meanings: 1. Pweak's code can contain programming and conceptual bugs, mistakes, errors, and is not to be considered as reliable. 2. Successive versions of code, examples and file formats are assumed to be incompatible. 3. Inclusion of a reference to Pweak is a must to any publication (e.g. paper, report, manual) of any work related to Pweak (e.g. research, course, programming project). 4 The Pweak software or any part of it cannot be used for commercial purposes (by the way, who would want of such a buggy code ;-). As long as you accept and respect the four previous points, you can do anything you like with the Pweak software. ¥ Introduction :=========================================================== This (simple) planning procedure simulator is written in Prolog. The dialect is Open Prolog, a nice freeware (Edinburgh-like) prolog for the Apple Macintosh, which provides menu and window predicates for this machine. I henceforth refer to the planning system as "Pweak". Pweak was originally designed in 1990 on an Acorn A310 machine running under Prolog_X with 4Mb, and fitted with a 35MHz ARM 3. Pweak ran during weeks (non-stop) on this machine. My A310 still is a fantastic machine; but Open Prolog is a great freeware prolog for the Mac. In this information document, I have tried to do my best so that no knowledge of prolog is needed; if you ever think this is not the case, please tell me. Anyway, you can refer to informations provided with Open Prolog. Some knowledge of artificial intelligence classical planning is needed. You will find some basics in this file, but don't hope too much. [References] Collection of articles about planning? [*] "Readings in Planning", Edited by James ALLEN, Jim HENDLER & Austin TATE, Morgan Kaufmann (1990), 754 pages. ISBN 1-55860-130-9 Beginning with Prolog for Artificial Intelligence? [*] Ivan BRATKO, "Prolog Programming for Artificial Intelligence", Addison-Wesley (1986). I use the french edition (1988), 445 pages, ISBN 2-7296-02321 and I like it. A second edition exists, apparently only in english. Gentle introduction to Artificial Intelligence through Prolog? Contains a description of Strips and means-ends analysis. [*] Peter SCOTT & Rod NICOLSON, "Cognitive Science Projects in Prolog", Lawrence Erlbaum Associates (1991), 277 pages. ISBN 0-86377-182-3 Nth steps in Prolog? [*] Richard O'KEEFE, "The Craft of Prolog", MIT Press (1990), 387 pages. ISBN 0-262-15039-5 ¥ Requirements :=========================================================== In order to use Pweak, you must have: An Apple Macintosh with system 7 or later and at least 4Mb of memory. Of course, the more powerful the processor, the better. Although really slow, a Macintosh LC is enough to begin. Since Open Prolog runs under system 6, this system should be enough to run Pweak; accordingly, since Open Prolog runs on PowerPC Macs in emulated mode, so does Pweak on these machines. However, I still have to test this. A copy of Open Prolog. Open Prolog is available from in ".hqx" format. Now that Pweak uses the dialog features of Open Prolog, the needed version is 1.0.3d38 (and later, I hope); I myself use Open Prolog 1.0.3d38 to develop Pweak. The Pweak server (address below) provides a version of Open-Prolog always compatible with Pweak. A copy of Pweak. Pweak is available from Actual Pweak version is 0.91d2 (i.e. it still is under development; however, it runs on all of the examples that can be loaded within Pweak). There, you can find Pweak's Releases_Notes file in HTML format, Pweak's Pweak_info file in ascii format and where to reach me; note you can get both Pweak and a compatible version of Open-Prolog from there. Note that the Pweak pages also contain numerous pointers related to artificial intelligence planning. ¥ Installation :=========================================================== Please, completely read this section before installing Pweak. Once ftp-retrieved, files must be transformed into usual Macintosh folders. Both Open Prolog and Pweak are compacted to a self-extractable archive and then converted to hexadecimal to facilitate network transfer. You must therefore convert back to binary and then decompact these files in order to use Open Prolog and Pweak. Freeware "Stuffit Expanderª" will do these conversion and decompaction automatically; just drag and drop the ".hqx" file on the "Stuffit Expander" icon. Freeware "BinHex 4.0" will convert the ".hqx" file into a binary self-extractable archive: to decompact it, just double-click on the file. "Stuffit Expanderª" and "BinHex 4.0" can be found on any classical anonymous ftp site ( and its mirrors). Pweak and Open Prolog do not fit together on the same 1.44Mb floppy. IF you wish to do so, you'll have to delete some files; for instance, you may wish to delete the Mathematica files of Pweak contained in the :Pweak:Tools folder. You can also delete the documentations files of both Pweak and Open-Prolog. To install Pweak on your hard disk, with at least 5Mb of free space, copy, where you wish it, both the Open Prolog folder and the Pweak folder. Reserve 2048 Kb of memory in the Apple-I info box of Open Prolog (to get this box, select the finder, click once on the Open Prolog icon and select 'Information' in the 'File' menu). Pweak shall not load into 1024Kb (i.e. 1Mb) of memory. Moreover, 2Mb is necessary to run Pweak on most examples. If you look for information about Open Prolog, open the Open Prolog folder. The "Beginners - look in here" folder contains a "Getting Started" file in Microsoft's Word format; and the "Documents" folder contains extra information. To load Pweak (and automatically load Open Prolog), open the Pweak folder and then double-click on the file named "Open Prolog Worksheet". This first loads Open Prolog and then Pweak. Once loaded, the righmost menu item in the menu bar should be "Pweak"; also, the version of Pweak and the date I packaged it should be written in the Open Prolog Worksheet. IF doucle-clicking on the file named "Open Prolog Worksheet" in the Pweak folder does not load Pweak but prompts a dialog box saying that the application that created this document is impossible to find (and then proposing to open it with TeachText) THEN you must rebuild your desktop so that Open Prolog documents are taken into account. To rebuild your desktop, press both the apple and option keys and restart your Macintosh; press apple-option until a dialog box asks you if you really want to rebuild your desktop; either click 'Ok' or hit the enter key. Once the desktop is rebuilt, doucle-clicking on the file named "Open Prolog Worksheet" in the Pweak folder should load Pweak correctly. When, in the window titled "Open Prolog Worksheet" one can read the following (or about): Pweak 0.90d12 (released on Monday, November 21st, 1997) is ready to go. You are then ready to use the planning system. IF you experience ANY problem THEN do not hesitate to contact me (email is ¥¥ Contents of the Pweak folder :------------------------------------------ The Pweak folder contains the following folders: "Configurations" contains files that configure Pweak so that it can simulate a particular planning procedure. "Documents" contains informations files about Pweak (this file and another about what I'd like to add to Pweak). "Problems" contains planning problem files as well as an example file template. "Solutions" shall contain auto-saved files. DO NOT remove this folder. "Sources" contains all the source files of Pweak. "Tools" contains Mathematicaª files to visualize the partial plan space of a problem. "User" contains user definitions; for instance, constraints, the examples_list file and the preferences file. The Pweak folder contains the following files: "Open Prolog Worksheet" where to double-click to load Pweak. "Open Prolog Startup" tells Open Prolog to load source file ":Sources:Pweak_mac_loader" at startup. "Read_Me" says where to double-click to load Pweak and Open Prolog. "Releases_Notes" tells you everything you should know about previous released versions of Pweak. ¥¥ Upgrading from an older version :--------------------------------------- If you did not customized Pweak's prolog code, THINK of the solutions files you may have saved in the :Solutions folder and would like to keep. Once you have placed your solutions files in a safe place, just trash the Pweak folder and copy the new version. THINK also of the Mathematicaª files you may wish to keep. Gee. If you customized Pweak's code, what can I tell you? Check the Releases_Notes file and see what has changed and try to update the files accordingly. Good luck! Anyway, if you have any problem or want to see your code incorporated, do not hesitate to contact me. ¥ World language :========================================================= For Pweak, the world is made of (a potentially infinite number of) states. Sets of formulas describe a state of the world. Formulas are positive first order logic atomic formulas: predicates whose parameters are terms; a term is either a constant symbol, a variable or a function term. A constant symbol is a string of characters (the first character cannot be a number and letters must be lower case). A variable is any string of characters (the first character must be a capital letter or else the underscore "_"); a variable can be attributed from a set of constants called its universe. We shall note U(X) the universe of the variable X. A symbol is any constant symbol. The number of parameters of a function symbol is its arity; a n-ary symbol is a symbol with n parameters. A function term is made of a n-ary function symbol and n terms (i.e. n arguments that can be terms again). Symbols with arity n are noted symbol/n. For instance, table is a constant whereas Table and _table both are variables. If succ/1 is a function symbol with arity 1 then succ(2), succ(X) and succ(succ(1)) are function terms. A predicate is made of a n-ary predicate symbol and n terms. For instance, if clear/1 is a predicate symbol of arity 1 then clear(table), clear(Block) both are predicates (note that in the first case, the argument is a constant whereas in the second case it is a variable). They also are non negated (i.e. positive) atomic formulas. The semantic attached with formulas is that of membership: if a formula is a member of a set describing a state of the world, then it is true; it is false otherwise. Assume that "a", "b" and "c" are three 0-ary predicate symbols. Then the set {a,b} makes both "a" and "b" true and "c" false in the state that this set desribes. The world is a set of sets of formulas. It also is a subset of the power set of the set of all possible sets of formulas. As before, consider the only three possible formulas "a", "b" and "c". Then there are eight different sets from the set {a,b,c}: {¯, {a}, {b}, {c}, {a,b}, {a,c}, {b,c}, {a,b,c}} where ¯ reads as the empty set. The world is a subset of this set in the sense that maybe the sets {a,b,c} and {a} describe an impossible state of the world; then, {¯, {b}, {c}, {a,b}, {a,c}, {b,c}} describe the world. Note that in the situation described by ¯, all the possible formulas are false. Later, I shall refer to lists. These are basic syntactic sugar: list ::= "[" element_enum "]" element_enum ::= element {"," element}* For instance, "[clear(X),next_to(robot,door),wired]" is a list. [References] A brilliant and pedagogical book on logic? [*] Dirk VAN DALEN, "Logic and Structure", Universitext Series, Springer Verlag (1983), 207 pages (ISBN 3-540-12831-X). Why "atomic formulas only" for classical planning? [*] Vladimir LIFSCHITZ, "On the Semantics of Strips", in: "Reasoning about Actions & Plans", Proceedings of the 1986 Workshop, Timberline, Oregon, Michael Georgeff and Amy Lansky (Eds), Morgan Kaufman (1987), pages 1--9. Can also be found in: "Readings in Planning", James Allen, James Hendler and Austin Tate (Eds), Morgan Kaufman (1990), pages 523--530. Atomic formulas? You mean that one can use functions symbols? [*] Eric JACOPIN, "A Look at Functions Symbols and Planning", AAAI Technical Report SS-93-01, AAAI Press (Palo Alto, 1993), pages 62--66. ¥ Action language :======================================================== An action allows to move from one state to another. Note that it is an assumption that this move is instantaneous. Since sets of formulas describe the states of the world, an action allows to move from a set of formulas to another; thus possibly making some formulas false (the deleted formulas, the ones which are not member of the set which is reached) and some true (the added formulas, the ones which are member of the set which is reached). Consequently, an action can be seen as the couple of sets where the first set is where an action is applied and the second is the result of the application of the action. The first set is called the preconditions set and the second set, the postconditions set. Assume that ({a,b},{b,c}) is a couple describing an action. Then to move from the set {a,b} to the set {b,c}, one must delete the element a from the set {a,b}, resulting in the set {b}, and then add the element c to the set {b}, resulting in the set {b,c}. Note that adding c first and only then deleting a does not change the resulting set. In order to be practical, an action description is a triple where the postconditions set is split into a deleted set and an added set. Thus the resulting situation {b,c} = ({a,b} \ {a}) U {c}. Where \ is the set difference and U is the set union and the action description triple is ({a,b},{a},{c}). So that either the set-union or the set-difference can be computed in any order, the intersection of the deleted set with the added set must be empty. Practically, this says that an action cannot make a formula both true and false at the same time. Although it indeed takes some time to compute set-union and set-difference, theoretically, these are timeless: in theory, it takes no time to compute those set operations. And a formula cannot be added and deleted at the same time. It is then considered that a formula cannot belong to both sets. Note that this corroborates the assumption of the instantaneous move from one world state to another. A last point about the preconditions set. Consider the triple ({a,b,c},{a},{c}) which allows to move from the set {a,b,c} to the set {b,c}: {b,c} = ({a,b,c} \ {a}) U {c}. Note that classical notion of set does not allow mutliple occurences of elements: {b,c} U {c} = {b,c} (and not {b,c,c}). This triple reaches the same set than ({a,b},{a},{c}). But they differ only from the preconditions set; both the deleted and added sets are the same. In fact, one considers that an action triple is applicable to any situation to which its preconditions set is included. Consequently, if the preconditions set of an action is empty then it is applicable to any situation of the world. If an action triple contains variables then one must assign a value before computing the union and difference. Thus, there exists an instantiation function attributing a constant of its universe to a variable: i : {X| X is a variable of the World language} --> U(X) X --> i(X) = c One can now begin to define a result function. Let s be a state description and ad = (P,D,A) be an action description (or, an operator) whose variables have been instantiated. The result function takes an operator and a situation as arguments and returns a situation: result : O x S --> S (ad,s) --> r = result((ad,s)) with the following rules to compute the resulting state r: result(ad,s) = (s \ D) U A if P is a subset of s. result(ad,s) = s if P is not a subset of s. An operator is always applicable in a situation description s. If its preconditions set is included in s then the result function above gives the application of the operator to the situation description s. If an operator is not applicable to a situation, it acts as an identity on s (i.e. s remains unchanged under the application of an unapplicable operator). Note this prevents from seeing the set of operators as a group acting on the set of states: indeed several actions could act as identity whereas a group structure requires the identity action to be unique... First, here is an example of an action description understandable for Pweak (/* and */ denote beginning and end of comments -- action description taken from example file 'Sussman anomaly'): define(action(chapman::newtower),domain(blocks_world), comment('Take a block off a tower atop the table'), body(parameters::(X,Z:box), constraints::[neq(X,Z)], precondition::[on(X,Z),clear(X)], positive_effect::[on(X,table),clear(Z)], negative_effect::[on(X,Z)])). All fields use :: to separate the field identifier from content. An action description thus is a structure with 3 fields in which action description data is stored. In particular, the third field contains the Strips action description usual fields: precondition, add and delete lists. The parameters field contains the list of the variables used in the action description and the universes in which they take their values. The Header field has the following syntactic form (recall that characters or strings between " and " below must be exactly typed in; expressions between [ and ] are optional; expressions between { and }* can be repeated as many times as desired, in the order specified in the parenthesis): identifier = constant_symbol variable_list = variable_symbol {"," variable_symbol}* variable_declaration = variable_list ":" identifier formal_variable_declaration = variable_declaration {";" variable_declaration}* Header_field = identifier ["::" "(" formal_variable_declaration ")"] Note that the form "::" formal_variable_list is optional: it may be the case that the action description contains no variable. In this case, this syntactic form is omitted (action description taken from example file 'Looping Pweak') and the Var_constraints field is empty: define(action(example::one),domain(this_info_file), comment('As an example, add q to the current state'), body(parameters::[], constraints::[], precondition::[p], positive_effect::[q], negative_effect::[])). As previously mentioned, variables possess a universe where they take their values. The variable declaration part of the header (e.g. (X,Z:box)) is here to say to what universe a variable refer to. This is the same as a procedure heading in a classical programming language such as PASCAL. The second field is a list of constraint predicates whose arguments are variables (and/or constants) of the formal_variable_declaration of the Header field of the action description (thus in the action description newtower above, the constraint predicate neq/2 means that its arguments should Not be EQual): parameter = variable_symbol | constant_symbol parameter_list = parameter {"," parameter}* constraint = predicate_symbol "(" parameter_list ")" constraint_enumeration = constraint {"," constraint}* Var_constraints_field = "[" constraint_enumeration "]" The user can define constraints. See the file 'Constraints' in the 'User' folder. The third, fourth and fifth fields are lists of positive atomic formulas. Note however, that function terms are not fully handled in Pweak. See example file 'Simulating a counter' for additional information on using a simplistic function term in Pweak. [References] On action execution (about the result function): [*] Vladimir LIFSCHITZ, "On the Semantics of Strips", in: "Reasoning about Actions & Plans", Proceedings of the 1986 Workshop, Timberline, Oregon, Michael Georgeff and Amy Lansky (Eds), Morgan Kaufman (1987), pages 1--9. Can also be found in: "Readings in Planning", James Allen, James Hendler and Austin Tate (Eds), Morgan Kaufman (1990), pages 523--530. ¥ Planning problem :======================================================= A planning problem is a 4-tuple (T,I,G,Ops) where T is declaration of the universes, I and G are state descriptions of the world and Ops is a set of action descriptions. I is the initial state of the problem and G is the Goal state. For Pweak, (T,I,G,Ops) is encoded into four syntactic forms: "define(constant_symbol_0;types(list_0))." "define(constant_symbol_1,initial_state(list_1))." "define(constant_symbol_2,final_state(list_2))." "define(action(operator_set_name::operator_name), domain(what_is_the_operator_usable_for), comment('this is an example'), body(parameters::list_31, constraints::list_32, precondition::list_33, positive_effect::list_34, negative_effect::list_35))." where constant_symbol_0, constant_symbol_1, constant_symbol_2 and constant_symbol_3 are any constant symbol of your choice. list_0 is a list of couple (constant_symbol,list_of_constant) which describes, in extension, the universes of the planning problem. list_1, list_2, list_31, list_32, list_33, list_34 and list_35 are lists of formulas (see section ¥ World language above and section ¥ Action language above). Here is an example. First let us begin with a type declaration: "define(jazz,types([(pianist,[bill_evans,oscar_peterson]), (guitarist,[wes_montgomery,pat_metheny])])). Then, an initial state: "define(rock,initial_state([roll])." A final state: "define(be,final_state([bop]))." Finally, at least one operator: "define(action(example::one),domain(this_info_file), comment('As an example, add q to the current state'), body(parameters::[], constraints::[], precondition::[p], positive_effect::[q], negative_effect::[]))." ¥ Plan language :========================================================== Let N be the infinite set of natural integers and x denotes the cartesian product of sets. Let L be a labelling function assigning an integer to a unique operator: L : N --> Ops n --> ad = L(n) L is a priori not surjective (some operators may not be related to any integer). L is certainly not injective (two distinct integers can relate to the same operator). For instance, it might be possible that: L(16) = L(15) = define(action(chapman::puton),domain(blocks_world), comment('Move a block from one stand to another'), body(parameters::(X,Y:box;Z:stand), constraints::[neq(X,Y),neq(Y,Z),neq(X,Z)], precondition::[on(X,Z),clear(X),clear(Y)], positive_effect::[on(X,Y),clear(Z)], negative_effect::[on(X,Z),clear(Y)])). Finally, some integers may not be related to any operators at all. Let F_L the family of all possible L as previously defined. Let Li be a element of F_L and O = {o such that o = (n,Li(n))} be a set of labelled operators. A plan is a couple (O,<) where < is a strict partial order on O (i.e. < is a binary relation over O which is not reflexive, antisymmetric and transitive; it is a subset of O x O). The length of a plan (O,<) refers to the cardinal of O, noted |O|. For Pweak, O is encoded into a list of action descriptions (see ¥ Action language above) where the identifier of the Header field of each action description is concatenated to the label of the action description; for instance, newtower_15 is such a labelled identifier. The partial order < is encoded as a list of t/2 predicates whose parameters are both headers of operators; for instance, t(newtower_15::(X,c),puton_22::(a,b,Z)) reads newtower_15::(X,c) < puton_22::(a,b,Z). One can now extend the definition of the previous result function to handle the result of a plan whose set of action descriptions contains two operators: {O1,O2}. The function result returns a situation according to the order relations between O1 and O2: (0) result({0},s) = result(O,s) (1) IF O1 < 02 THEN result({O1,O2},s) = result({02}, result(01, s)) (2) IF Â(O1 < O2) and Â(O2 < O1) THEN (2.1) result({O1,O2},s) = result({02}, result({01}, s)) (2.2) result({O1,O2},s) = result({01}, result({02}, s)) (0) is syntactic sugar. (1) says how to execute a sequence of ordered operators (i.e. apply the first one and then apply the second one). Whereas (2) says how to execute a sequence of unordered operators (i.e. arbitrarily first execute either one or else the other). This trivially is extended to the case of a plan containing more than two operators. A planning problem is encoded into an initial plan noted p_init; thus the planning system only manipulates plans from the beginning of its search. This initial plan possess two fake operators; an initial operator, noted begin, with the initial state as its add list; and a final operator, noted end, with the final state as its preconditions list (begin and end are not labelled): ({begin = (¯,¯,I), end = (G,¯,¯)},{(begin,end)}) which, for Pweak is (first comes the operators list and then the partial order) encoded as: [ad(begin, /* Header */ [], /* Var_constraints */ [], /* Preconditions */ list_1, /* Added set */ []), /* Deleted set */ ad(end, /* Header */ [], /* Var_constraints */ list_2, /* Preconditions */ [], /* Added set */ []) /* Deleted set */ ] [t(begin,end)] ¥ Plan existence problem :================================================= The plan existence problem is the following: "Let (T,I,G,Ops) be a planning problem. Is there a plan P = (O,<) such that its application to the initial state yields at least the goal state (G is included into result(O, I))?" Note that since unapplicable operators act as the identity, the length of a solution can be arbitrarily long. Also note that the answer to the plan existence problem is either "yes" or "no"; indeed the plan existence problem is a decision problem. Finally recall that an operator must be instantiated to be executable. Pweak attempts to build a plan in order to answer yes. ¥¥ Complexity of the plan existence problem :------------------------------ It is probably necessary to know a few about Turing machines and complexity classes to read this subsection. Let (T,I,G,Ops) be a plan existence problem. Looking at the format of the action descriptions, one can give the (worst case) size of the search space or the (worst case) time needed to solve the problem: the number of formulas, and the language used to compose them, in the preconditions set, added list and deleted list entail a complexity. Both TIME and SPACE complexity results have been found for planning problem; and both give upper bound results (i.e. worst case). TIME complexity gives an upper bound to the number of step unit needed to reach a solution; and SPACE complexity gives an upper bound to the number of storage unit needed to reach a solution. Encoded on a Turing machine, one step unit corresponds to the execution of one transition of the machine; one storage unit corresponds to one tape square; and reaching a solution corresponds to reaching a halt state of the machine. To obtain complexity results for a planning problem, the idea is to encode a Turing Machine as a planning problem: - First show that a the computation of a Turing machine can be encoded as a planning problem (and back). Therefore a storage unit corresponds to a formula used in the planning problem encoding the Turing machine. - Second, showing that the action description format can encode (up to a polynomial transformation) a given Turing machine (with its given complexity). Therefore, a step unit corresponds to the application of an action description of the planning problem encoding the Turing Machine. The consequence is that the solving of the planning problem is as complex as the halting problem of the Turing Machine (up to a polynomial transformation of an halting problem into a planning problem). Some complexity results are given in the table below. The first column refers to the language used in the description of the planning problem. The second refers to the format (number of preconditions, added and deleted formulae) of action descriptions. The third column gives the complexity of the problem of finding a plan. And the last (fourth) column gives the complexity of the problem of finding a plan of at most a certain length. For instance, assume the problem is described with a language which is propositional (formulae are only made of 0-ary predicates) and action descriptions of the problem are limited to one positive precondition, as many added formula as desired and no deleted formula; if x storing unit is used to encode the problem, the space needed to solve the problem is bounded by log(x+1). As you can see, log(x+1) is an upper bound: in the worst case, log(x+1) storage unit shall be used to solve the problem. ±, + and - respectively mean either positive or negative formulae, positive only and negative only; * means as many as desired. =========================================================================== | Language | AD format | Finding a plan...|...of length ² L | |-------------|----------------------|------------------|-----------------| | 0-ary | (1+,*,0) | NLOGSPACE | NP | | predicates |----------------------|------------------|-----------------| | only. | (1±,*,*) and g goals | Polynomial | Polynomial | | |----------------------|------------------|-----------------| | | (³2+,*,0) | Polynomial | NP | | |----------------------|------------------|-----------------| | | (0,i,j) and i+j=1 | Polynomial | Polynomial | | |----------------------|------------------|-----------------| | | (0,2,0) | Polynomial | Polynomial | | |----------------------|------------------|-----------------| | | (0,*,*) | Polynomial | NP | | |----------------------|------------------|-----------------| | | (*+,i,j) and i+j=1 | Polynomial | NP | | |----------------------|------------------|-----------------| | | (*+,0,*) or (*-,*,0) | Polynomial | NP | | | and g goals | | | | |----------------------|------------------|-----------------| | | (*+,0,*) or (*-,*,0) | NP | NP | | |----------------------|------------------|-----------------| | | (1±,*,0) | NP | NP | | |----------------------|------------------|-----------------| | | (*±,*,0) | NP | NP | | |----------------------|------------------|-----------------| | | (1±,*,*) | NP | PSPACE | | |----------------------|------------------|-----------------| | | (2+,i,j) and i+j³2 | PSPACE | PSPACE | | |----------------------|------------------|-----------------| | | (*±,i,j) and i+j=1 | PSPACE | PSPACE | | |----------------------|------------------|-----------------| | | (*±,*,*) | PSPACE | PSPACE | |-------------|----------------------|------------------|-----------------| | Predicates | (1+,*,0) | PSPACE | PSPACE | | and |----------------------|------------------|-----------------| | constants | (*+,*,0) | EXP-TIME | N-EXP-TIME | | |----------------------|------------------|-----------------| | | (*±,*,0) | N-EXPTIME | N-EXP-TIME | | |----------------------|------------------|-----------------| | | (*,*,*) | EXPSPACE | N-EXPTIME | |-------------|----------------------|------------------|-----------------| | Atomic | (*,*,*) | 1/2 D | 1/2 D | | formulas | | | | =========================================================================== Polynomial is a TIME complexity NP(-complete) is a TIME complexity PSPACE means Polynomial SPACE complexity EXP- means exponential N- means Non deterministic and corresponds to a problem complexity for a non-deterministic Turing machine. Recall these machines possess a "Choose" operator which creates as many copies of a deterministic Turing machine as there are possible choices. For instance, NP means that any of the created deterministic Turing machines solve or fail in Polynomial TIME -- but the number of the machines that have been created is exponential in the number of possible choices of the "Choose" function. 1/2 D means semi-decidable (i.e. the procedure shall only stop to say yes) [References] What is a Turing Machine? Mac Software to experiment with Turing Machines? [*] Jon BARWISE & John ETCHEMENDY, "Turing's World 3.0 (An Introduction to Computability Theory)", Center for the Study of Language and Information, Lecture Notes No. 35 (1993), 123 pages. ISBN 1-881526-10-0 What is a Turing machine? About problem complexity? [*] Michael GAREY & David JOHNSON, "Computers and Intractability (A guide to the Theory of NP-Completeness)", Freeman (1979), 340 pages. ISBN 0-7167-1045-5 Where can some of the results (and the proofs) in the above table be found? [*] Tom BYLANDER, "The Computational Complexity of Propositional STRIPS Planning, Artificial Intelligence 69 (1994)", pages 165--204. Where can some of the results (and the proofs) in the above table be found? [*] Kutluhan EROL, Dana NAU, V.S. SUBRAHMANIAN, "Complexity, Decidability and Undecidability Results for Domain-Independent Planning", Technical Report, Computer Science Department, University of Maryland (1992), 46 pages. Contact ¥ Solution to the plan existence problem :================================= Let (T,I,G,Ops) be a planning problem and P = (O,<) be a plan such that the initial oprator begin and the final operator end belong to O and all operators of O but begin are after begin, all operators of O but end are before end. P is a solution to (T,I,G,Ops) if and only if result(O, s = ¯) is a superset of G. "result(O, s = ¯) is a superset of G" is translated by the following: For all operators A of O and for all their preconditions p, there exists an operator T of O before A which adds p, such that all operators C of O deleting p are not in between T and A (i.e. all operators C are either before T or else after A). ¥ Plan modification operators (plan construction) :======================== Pweak starts with the initial plan ({begin = (¯,¯,I), end = (G,¯,¯)}, {(begin,end)}) and tries to modify this plan so that it becomes a solution to the planning problem it encodes. Modifications to the initial plan are made by the application of plan modification operators. ¥¥ Definition (what the plan modification operators are) :----------------- Let PP be the set of partial plans for a planning problem, i.e. the set of all possible couples (O,<) over N x Ops. Note that PP is infinite. A plan modification operator (PMO) is a mapping from PP into itself minus the initial plan p_init (\ stands for set-difference): PMO : PP --> PP \ {p_init} px --> py = PMO(px) PMO is an order preserving function: for all operators O1 and O2 of O_x such that O1 <_x O2 then PMO(O1) <_x PMO(O2). PMO is not supposed to act as identity (i.e. px = py = PMO(px)); it increases the number of operators or else the relation order. PMO never reduces the number of relations between the operators of a plan. The idea of a plan modification operator thus is to "add" a partial plan to another one so as the resulting plan is closer to a solution. This addition is made on the two set components of a plan using set-union. Recall that set-union is idempotent (in what follows, U stands for set-union): {a} U {a} = {a} (or, {a} cannot be distinguished from {a,...,a}; note that the concept of multiset allows to distinguish mutliple occurences of the same element of a set). When Pweak modifies the operators set, at most one new operator is added to this set, and always with an order related to this operator (O_x is the operators set of plan px, O1 and O2 are two operators; O1 is newly inserted and O2 already belong to px): "Operator insertion" : py = (O_x U {O1},<_x U {(Oi,O1),(O1,O2),(O1,Of)}) Note that because set union is idempotent, adding Oi, O2 and Of to px is a fake addition. Thus, for simplicity, Oi, O2 and Of are henceforth omitted in the addition to O_x. Pweak can also only modify the partial order by inserting at most one precendence constraint at a time (O_x is the operators set of plan px and O1 and O2 are operators already belonging to O_x such that (O2,O1) does not already belong to <_x): "Precedence insertion" : py = (O_x,<_x U {(O1,O2)}) "Operator insertion" and "Precedence insertion" are the only two plan modification operators used in Pweak. Surjectivity of PMO is desired: for all py of PP there exists a px such that py = PMO(px), which means in using PMO, Pweak is able to construct all plans of PP. This is clearly necessary for completeness reasons. To be injective, PMO(px) = PM0(py) implies that px = py, which means there is only one "way" to build a plan using PMO. Injectivity maps the partial plan space into a tree whereas non-injectivity maps it into a graph. "Operator insertion" and "Precedence insertion" do not to act as identity: when an operator is added to O_x, it does not already belong to it; it is a new operator. When an order is added to <_x this is a new precendence constraint which did not previously belong to <_x. ¥¥ Semantics (applicability of plan modification operators) :-------------- Let (T,I,G,Ops) be a planning problem. Let (O,<) be a partially ordered plan and let A, E and C be three elements of O. Let p be a precondition of A, added by E and deleted by C. "Operator insertion" is applied when there exists no establisher for the current precondition to be established: assume p of A has no establisher yet and, and moreover, no operator of O_x adds p. But E_new of Ops adds p. Then, E_new is added to O following "Operator insertion": "Operator insertion" : py = (O_x U {E_new},<_x U {(E_new,A)}) This is called establishment by a new operator. E_new is the establisher for p. E is new because it has been newly inserted to establish p. If an operator of O_x adds p (let E_old be this operator) then only "Precedence insertion" is applied, if and only if E_old is not already after A: "Precedence insertion" : py = (O_x,<_x U {(E_old,A)}) This is called establishment by an old operator. E_old is the establisher for p; E is written E_old because it was already in the plan. Assume now that p of A is established by E; then (E,A) is an element of <_x. For all C which are clobberers of p, "Precedence insertion" will be applied: "Precedence insertion" : py = (O_x,<_x U {(A,C)}) This is called promotion of C after A and is possible only if (C,A) does not already belong to <. And "Precedence insertion" : py = (O_x,<_x U {(C,E)}) This is called demotion of C before E and is possible only if (E,C) does not already belong to <_x. If C is not comparable neither to E nor A (i.e. the intersection of {(C,E),(E,C),(A,C),(C,A)} and <_x is empty), then both promotion and demotion of C are applicable. Pweak always tries demotion first (because demotion appears first in the source file "declobbering"). If there ever exists one C such that (E,C) and (C,A) belong to <_x then p is said to be incorrectly achieved. Let p_c the formula of the deleted set of C which unifies with p precondition of A. If p_c contains variables, it is possible to force future unifications of these variables so that p_c does not unify with p anymore. For instance, let us assume clear(a) is a precondition of A established by E. And C is an operator in-between E and A which possess clear(Z) in its deleted set. Then, by enforcing variable Z to unify to a value different from a, the plan can still be correct. Note that this can be applied even if C is not in-between E and C, thus protecting precondition p while avoiding to modify the partial order. This is called variable (Tweak) separation. As it is presented, separation acts as identity: neither an operator is inserted nor a precedence constraint is added. This has lead some researcher to include a third component to a plan: a list of unification constraints (usually called a binding set in the literature). Thus separation never acts as identity. However, one can decide to apply separation as a precedence insertion, enforcing the clobberer to always be in-between E and A: not only p_c shall not unify with p but C is both after E and before A. This is called SNLP separation and does not act as identity anymore. Note that if none of promotion, demotion or else separation (Tweak or SNLP) can be applied, then Pweak shall backtrack on previous choices --- either establishers or "Precedence insertion" for clobberers; if all previous choices have been tried, Pweak returns failure. An optional plan modification operator is provided. For instance, when there exists one C such that (E,C) and (C,A) belong to < then it is possible to look for an operator Old_WK already in the plan such that on can constraint Old_WK in-between C and A : "Precedence insertion" : py = (O_x,<_x U {(C,Old_WK)}) "Precedence insertion" : py = (O_x,<_x U {(Old_WK,A)}) This is called the demotion by an old white knight and is possible only if neither (Old_WK,C) nor (A,Old_WK) belong to <_x. ¥¥ Movements (how Pweak chooses to apply plan modification operators) :---- Constructing a plan amounts to move in the space of partial plans (PP). PP is a graph where vertices are partial plans and arcs are plan modification operators (PMO). In theory, PP is infinite and so is its graph. In practice, we shall now consider PP(n) = I x Ops with I a subset of N, containing consecutive integers, of cardinality n. PP(n) just represents (the space of partial) plans containing at most n operators, whatever these (labelled) operators are and whatever the partial order is, providing, hozever, it is always a lattice with begin and end as its minimum and maximum, respectively. All vertices of PP(n) are connected to each other. However, since Pweak only uses two PMOs ("Operator insertion" and "Precedence insertion"), it cannot leave a vertex by any of the arcs. Only those related to the two PMOs can be followed. There are certainly plenty of arcs consistent with the PMOs which leave any vertex; and possibly so many that there exists more than one path from the initial plan to a plan-solution (there might be many solutions to a problem). Some paths may be shorter, some may be longer. Pweak plunges depth-first into PP(n); but this depth-first plungeon does not mean Pweak increases the number of operators of its current partial plans at each vertex. Arc selection (to leave a vertex) depends on which precondition must be satisfied and how it is satisfied. To satisfy a precondition, Pweak always tries to find an establisher in the plan first; and always tries demotion first. Among all the possible unachieved precondition that can be chosen (in order to try to establish it), Pweak chooses the first one of a list (the list of not yet achieved preconditions). This list is modified when PMO "Operator insertion" is applied: the preconditions set of the newly inserted operator is added to this list, either at the end (in case the list is maintained as a queue) or else at the beginning (the list is thus maintained as a stack). These two goal list managements are proposed via the menu 'Goal list management...'. Initially, the goal list is managed as a queue. The queue or stack strategy must be chosen prior to running Pweak and is valid until the runtime is complete. A third management scheme of the goal list is also possible. It can be used in conjunction with the stack or else the queue schemes. It is that of cyclic update. Once a goal has been achieved, it is possible to see if any other unachieved goals can be achieved while leaving the plan unchanged (i.e. this step does not involve inserting operators and/or modifying the order relation). Note also that when PMO Tweak separation is applied, the vertex is not left since neither operator insertion nor precedence constraint is applied. ¥¥ Precondition achievement :---------------------------------------------- Pweak applies PMOs so as to get closer and closer to a solution. A first step closer is made when looking for an establisher (i.e. applying old_establishment of new_establishment) and other steps are made for declobbering (i.e. demotion, promotion, etc, of clobberers). The combination of establishment and declobbering ensures that the concerned precondition is safe: it is now correctly achieved. Each partial plan thus possess a set of preconditions that are already achieved (henceforth noted Paa) and a set of preconditions that are not yet achieved (henceforth noted Pnya) in which a unachieved precondition is chosen (this set can be managed as a stack, as a queue, etc, see subsection ¥¥ Movements above) so as to get closer to a solution. A solution vertice is a vertice whose Pnya is empty. Let us now consider the following Achieve function: Achieve : (PP x Pnya(PP) x Paa(PP)) --> (PP\{p_init} x Pnya(PP\{p_init}) x Paa(PP\{p_init})) (px,Pnya(px),Paa(px)) --> py = Achieve(px) where Pnya(PP) is the set of all not yet achieved preconditions sets of all partial of PP while Pnya(px) is the set of Preconditions of partial plan px that are not yet achieved. Accordingly for Paa(PP) and Paa(px). Obviously, function Achieve must be surjective. Surjectivity says that for all py, there exists a px such that Achieve(px) = py. Assume this is not the case; i.e. there exists a py such that there is no px such that Achieve(px) = py. Then py is unreachable through Achieve. If py is a solution then Achieve cannot reach it and the planner using Achieve is not complete. Surjectivity of Achieve is the key to completeness of the planning procedure. Let us first consider the case where Achieve is not injective: there exists two distinct partial plans pa and pb which have the same image through Achieve: Achieve(pa) = Achieve(pb). This means that vertex related to pa and vertex related to pb are connected to a third vertex (note this third vertex may be pa or pb) with Achieve (because Achieve(pa) = Achieve(pb)). PP thus is visited as a graph: it can be the case that one partial plan is visited more than once (once coming from pa and once coming from pb). If Achieve is injective, any two distinct vertices have different images through Achieve. PP thus is visited as a tree: there is a unique path from a partial plan to its image through Achieve. For instance, there is no way to leave a partial plan unchanged: Achieve should not be able to act as identity to be injective. Note that if Achieve is injective then its inverse exists. Since Achieve is made of applications of plan modification operators, injectivity or surjectivity is reached by controlling the applications of those plan modification operators. Never using promotion places surjectivity out of reach. And using Tweak separation places injectivity out of reach; so does any combination which leaves a partial plan unchanged. This can always be the case when old establishment is applied; note that if you use cyclic update (as in planners TO and UA) in conjunction with old establishment, then injectivity is enforced. Moreover if declobbering does not change the partial order, then the partial plan is left unchanged and then Achieve is not injective (since the partial was first reach from a distinct partial plan and then it is reached again from itself, though a new precondition has been achieved); again, cyclic update corrects this. Effects of these properties on efficiency are currently unknown, but research does its best. [References] About UA (brilliant, must read, papers)? [*] Steven MINTON, John BRESINA and Mark DRUMMOND, "Commitment Strategies in Planning: A Comparative Analysis", Proceedings of IJCAI'91, pages 259--265. Also technical report FIA-91-08 (December 1991), NASA Ames Research Center, AI Research Branch, 29 pages. Also Journal of Artificial Intelligence Research 2 (1994), pages 227-262. Research does its best? [*] Subbarao KAMBHAMPATI, Craig KNOBLOCK & Qiang YANG, "Planning as refinement Search: A Unified Framework for Evaluating Design Tradeoffs in Partial-Order Planning", Special issue of Artificial Intelligence on Planning and Scheduling, Volume 76:1-2, pages 167--238. ¥ Running Pweak on examples :============================================== To run pweak on examples, you must first load an example. ¥¥ Loading and example :--------------------------------------------------- To load an example, click on the "Pweak" item of the menu bar and then select 'Load an example'. An hierarchical menu appears. Each item corresponds to an example file to be loaded. If you select one, say "Empty problem", the corresponding example file is loaded and the menu item "Empty problem" is both disabled and marked (the latter, i.e. Ã, for better visibility of loaded examples). While loading the file, Open Prolog displays a progress bar. The corresponding filename is returned in the Open Prolog Worksheet window. For instance, Example file <:Examples:Empty problem> is now loaded. is written in the Open Prolog Worksheet window after selecting the 'Empty problem' menu item. You can load as many examples as the available memory of your Mac shall let you do it. Selecting 'Discard all examples' purges all loaded examples. Be careful, this will purge all the loaded example from memory. A message is returned in the Open Prolog Worksheet. For instance, ...All example clauses retracted! tells you that 3 examples were removed (becaused of the three dots before the sentence). Once all examples are retracted, the 'Discard all examples' menu and all example-related menus are disabled. Once an example has been loaded, you can run the planner. ¥¥ Plan existence tuples :------------------------------------------------- To run pweak, select "Pweak(Types,Is, Fs, Ops)..." in the "Planner" menu. A planning problem selection dialog appears. You are asked to enter 4 strings and a number. This means that not only you are asked to give a 4-tuple (made of a type descriptor, an initial state, a final state and a set of operators) but also to give a number bounding the number of operators in a possible solution. In the case the 'Sussman anomaly' example is loaded, enter the 5 following answers (press the tab key to move from one field to another or click in the field with the mouse): sussman_anomaly sussman_anomaly sussman_anomaly chapman 3 How can you know you have to type these 5 answers to get Pweak running on the Sussman anomaly example? To know the first four, once an example has been loaded and before selecting 'Pweak(Types, Is, Fs, Ops)...', select "Current descriptors..." in the "Pweak" menu. Current descriptors of all loaded examples are then written in the Open Prolog Worksheet. For instance if the sussman anomaly is loaded, the following is written: Descriptors of actually loaded examples: Type(s): [sussman_anomaly] Initial state(s): [sussman_anomaly,sa_robot] Final state(s): [sussman_anomaly,sussman_anomaly_1,sa_robot_1] Operators set(s): [chapman,robot] IPP operators set(s): [] IPP order(s): [] IPP Pnyaa: [] IPP Paa: [] The user has to know the number (how many operators are needed to reach the final state, starting from the initial state?). Assume you type 3 for the sussman anomaly example; this means the procedure shall look for solutions possessing at most 3 operators. Please note that some numbers are given below. There is actually no other way than looking in the example file in order to know what these descriptors refer to. A future version of Pweak could fix this. Click "Go" (or hit the enter key) when you have finished entering the three strings and the number. The problem data, the current date and time are printed first in the Open Prolog Worksheet: Types : [(box,[a,b,c]),(stand,[a,b,c,table])] Initial State : [clear(table),clear(c),on(c,a),on(a,table),clear(b),on(b,table)] Final State : [on(a,b),on(b,c)] Operators : chapman Maximum depth : 3 Search begins at 14:19:57, Jeudi 16 Mars 1995 Pweak is then ran on this problem and shall print each solution it finds in the Open Prolog Worksheet. Here is what it prints for the first solution it finds, when separation is on: # solutions/# visited = 1/47 @ depth 3 (Jeudi 16 Mars 1995, 14:20:05) ----------> Pweak proposes a plan! -----> Operators set: [ad(newtower_3(c,a), [neq(c,a)], [on(c,a),clear(c)], [on(c,table),clear(a)], [on(c,a)]), ad(puton_2(b,c,table), [neq(b,c),neq(c,table),neq(b,table)], [on(b,table),clear(b),clear(c)], [on(b,c),clear(table)], [on(b,table),clear(c)]), ad(puton_1(a,b,table), [neq(a,b),neq(b,table),neq(a,table)], [on(a,table),clear(a),clear(b)], [on(a,b),clear(table)], [on(a,table),clear(b)]), ad(begin, [], [], [clear(table),clear(c),on(c,a),on(a,table),clear(b),on(b,table)], []), ad(end, [], [on(a,b),on(b,c)], [], [])]. -----> Relations set: [t(newtower_3(c,a),puton_2(b,c,table)), t(begin,newtower_3(c,a)), t(puton_2(b,c,table),puton_1(a,b,table)), t(begin,puton_2(b,c,table)), t(newtower_3(c,a),puton_1(a,b,table)), t(begin,puton_1(a,b,table)), t(puton_2(b,c,table),end), t(puton_1(a,b,table),end), t(begin,end)]. -----> Bindings set: env([neq(table,c),neq(table,b)],[]) For instance "t(newtower_3(c,a),puton_2(b,c,table))", in the relations set, means that the operator whose header is newtower_3(c,a) is before the one whose header is puton_2(b,c,table). Pweak now displays a confirm box which asks whether the user wants to continue the search. If so, just click 'Yes' (or hit the enter key); click 'No' otherwise. While searching, the current solution number, the number of partial plans that have been visited so far and the current depth (i.e. the cardinal of the operators set of the current plan) are displayed in the message box at the top of the Open Prolog Worksheet. For instance, when the previous plan-solution is printed, the message box displays "0-47-3": 0 solution has been visited, 47 plans has been visited so far and the current depth is 3. A menu 'Solutions' with 4 submenus is provided which allows to change this 'find first solution and then ask to go on' behavior. The 4 submenus and their respective behavior are: 1. 'First and ask' which stops the search when a solution is found and asks the user whether to keep on searching. 2. 'First and stop' which ends up the search as soon as the first solution is found. 3. 'All' means the search only ends up when all solutions have been found. 4. 'Other...' asks the user the number of solutions to be found before ending up the search. A mark indicates which submenu is currently active. 4 extra submenus are also available for auto-saving purpose. For instance, you may choose to automatically save in a file what is written in the Open Prolog Worksheet. The 4 extra submenus and their respective behavior are: 5. 'Auto-saving' which saves in a file what is written in the Open Prolog Worksheet. The filename is NOT chosen by the user: it is made of the current date and is placed in the "Solutions" folder. Only the last runtime of consecutive runtimes on the same day will be kept. 6. 'Auto-saving as...' which saves in a file what is written in the Open Prolog Worksheet. But the filename is now chosen by the user. A dialog box is presented to the user. A filename MUST be given in a Mac format. No checking is made. A relative filename (e.g. :Solutions:Blah) or else an absolute filename (HD:Pweak:Solutions:Blah) can be given. To deactivate 'Auto-saving as...' once it is selected, select this option again and just click 'Ok' (i.e. no filename must be given: the corresponding field must be empty). 7. 'Auto-saving only' which is initially disabled and is enabled only when option 5. or else 6. above have been selected. It prevents from writing in the Open Prolog Worksheet. This is particularly useful to save runtime traces in a file only (remember Open Prolog windows can only contain 32kb). 8. 'PPS Statistics' which is initially disabled and is enabled only when option 5. or else 6. above have been selected. This writes informations about the Partial Plan Space. For instance, it writes the current number of the plan, its depth, its number of unachieved and achieved preconditions. Select this option to produce files compatible with the Mathematicaª files provided in the :Pweak:Tools folder. Selecting 5. while 6. is already selected leaves 7. and 8. as previously selected (e.g. if 'Auto-saving' is on together with 'Auto-saving only', then toggling to 'Auto-saving as...' will leave 'Auto-saving only' switched on). There are about 70 tuples (made of the 4 strings and the number). Some are given below (* means any number will do; when a number is given it is the length of the shortest solution; when '_' is given, try by yourself...): - (empty,empty,empty,empty,*) - (sussman_anomaly,sussman_anomaly,sussman_anomaly,chapman,3) - (sussman_anomaly,sussman_anomaly,sussman_anomaly1,chapman,3) - (sussman_anomaly,sa_robot,sa_robot_1,robot,6) - (doubledas,doubledas,doubledas,chapman,6) - (doubledas,doubledas_rh,doubled_as,robot,12) - (fiveblocks,fiveblocks,fiveblocks,chapman,5) - (fiveblocks,fiveblocks,fiveblocks_rh,robot,10) - (disprover,disprover,disprover,disprover,4) - (th,th_3d_3p,th_3d_3p,th_3d,7) - (llregistres,llregistres,llregistres1,llregistres,3) - (llregistres,llregistres,llregistres2,llregistres,3) - (llregistres,llregistres,llregistres3,llregistres,3) - (empty,offex1,offex1,offex1,3) - (empty,np_offex1,np_offex1,np_offex1,3) - (empty,loop_tweak,loop_tweak,loop_tweak,*) - (empty,loop_pweak,loop_pweak,loop_pweak,*) - (mtex7_1,mtex7_1,mtex7_1,mtex7_1,_) - (mtex7_1,mtex2,mtex2,mtex2,_) - (mtex7_1,mtex2biscorrect,mtex2bis,mtex2bis,_) - (mtex7_1,mtex2bisincorrect,mtex2,mtex2bis,_) - (mtex7_1,mtex2tercorrect,mtex2ter,mtex2ter,_) - (mtex7_1,mtex2terincorrect,mtex2ter,mtex2ter,_) - (m2c,m2cex1,m2cex1,m2c,_) - (m2c,m2cex2,m2cex2,m2c,6) - (be_1st,be_1st,be_1st,chapman,2) - (be_2nd,be_2nd,be_2nd,chapman,4) - (be_3rd,be_3rd,be_3rd,chapman,6) - (be_4th,be_4th,be_4th,chapman,8) - (be_1st,be_1st_robot,be_1st_robot,robot,4) - (be_2nd,be_2nd_robot,be_2nd_robot,robot,8) - (be_3rd,be_3rd_robot,be_3rd_robot,robot,12) - (be_4th,be_4th_robot,be_4th_robot,robot,16) - (empty,old_wk_useful,old_wk_useful,old_wk_useful,4) - (lba,lba,lba,lba,13) - (mtsimulelba,mtsimulelba,mtsimulelba,mtsimulelba,_) - (deuxsat,deuxsat,deuxsat,deuxsat,8) - (ch_4_blocks,ch_4_blocks,ch_4_blocks,jacopin,4) - (counters,start_from_zero,reach_two,sim_counter,2) - (counters,start_from_two,reach_six,sim_counter,3) - (counters,start_from_three,reach_zero,sim_counter,6) If you don't like these names, feel free to edit the example files and change them to what you wish. ¥¥ Adding your examples :-------------------------------------------------- The addition of an example is towfold. First, you have to write a file problem. Give a look at the example files to get some hints. Moreover, a "* problem file template" in the "Examples" folder provides the general format of what you should fill in. Second, you may wish to have your example file appear in the "Load an example" menu. If so, open the file "examples_list" in the "Examples" folder and add your filename (between ' and ': it is a prolog-string of characters!) with the other filenames. Your filename can be put anywhere in the list, because this list is alphabetically sorted before the menu is constructed. Then, when Pweak is loaded, your example appears in the example menu. ¥¥ What options for which planners? :-------------------------------------- Playing with Pweak menus, you may think there are too much or too little to play with. Here are a few planning procedures of the literature that can be simulated with Pweak, using different options, listed in the table below (where ± means optional, i.e. it can be selected but is not in the original procedure; + means it is necessary; Ñ means unnecessary or useless; and ? means unknown; NYI means Not Yet Implemented). Note that all the options can be switched on or off as you like. For instance, you may wish to switch on some (but not all) of the necessary options of the contributor protection to simulate UA. Then, you partially simulate UA, but you got a planner anyway. You may also switch on the SNLP Separation (Establishement Refine.) for Pweak or MacNonLin instead of the Tweak Separation, just for fun or for serious tests (the only difference between those two is the contraining of the clobberer in-between the establisher and the established in the case of the SNLP Separation); note that in this case, you are simulating a yet unknown planning procedure... ================================================================================= | | TWEAK | PWEAK | McNonLin | UA | SNLP | SNLP_UA | visit | |----------------------|-------|-------|----------|----|------|---------|-------| | Does the procedure |-------|-------|----------|----|------|---------|-------| | accept variables? | YES | NO | YES | NO | YES | YES | YES | 'NO' means propositional |----------------------|-------|-------|----------|----|------|---------|-------| language |*Goal List Management |-------|-------|----------|----|------|---------|-------| | FIFO | - | ± | ± | ± | ± | ± | ± | should be switched on. | LIFO | - | ± | ± | ± | ± | ± | ± | Only 1 of those 2 | Pick-up (MTC) |-------|-------|----------|----|------|---------|-------| | Establishment | + | - | - | - | - | - | - | | Promotion | + | - | - | - | - | - | - | | Demotion | + | - | - | - | - | - | - | | Separation | + | - | - | - | - | - | - | | Old White Knight | + | - | - | - | - | - | - | | Cyclic Update | ± | - | - | + | - | + | - | |----------------------|-------|-------|----------|----|------|---------|-------| |*Establishment Refine.|-------|-------|----------|----|------|---------|-------| | Promotion | + | + | + | - | + | + | + | | Demotion | + | + | + | + | + | + | + | | Separation (Tweak) | + | - | + | - | - | - | + | | Separation (SNLP) | - | - | - | - | + | + | - | | Old White Knight | + | ± | ± | - | - | - | + | |----------------------|-------|-------|----------|----|------|---------|-------| |*Establisher Protect. |-------|-------|----------|----|------|---------|-------| | Promotion | - | + | + | - | + | + | - | | Demotion | - | + | + | - | + | + | - | | Separation (Tweak) | - | - | + | - | - | - | - | Only 1 of those 2 | Separation (SNLP) | - | - | - | - | + | + | - | should be switched on. | Old White Knight | - | ± | ± | - | - | - | - | |----------------------|-------|-------|----------|----|------|---------|-------| |*Decontributing: |-------|-------|----------|----|------|---------|-------| | Promotion | - | - | - | - | + | + | - | | Demotion | - | - | - | - | + | + | - | | Separation (Tweak) | - | - | - | - | - | - | - | Only 1 of those 2 | Separation (SNLP) | - | - | - | - | + | + | - | should be switched on. |----------------------|-------|-------|----------|----|------|---------|-------| |*Deinteracting: |-------|-------|----------|----|------|---------|-------| |**Demotion |-------|-------|----------|----|------|---------|-------| | Add(E) \ Pre(I) ­ ¯| - | - | - | + | - | + | - | | Del(E) \ Pre(I) ­ ¯| - | - | - | + | - | + | - | | Del(E) \ Add(I) ­ ¯| - | - | - | + | - | + | - | | Add(I) \ Pre(E) ­ ¯| - | - | - | + | - | + | - | | Del(I) \ Pre(E) ­ ¯| - | - | - | + | - | + | - | | Del(I) \ Add(E) ­ ¯| - | - | - | + | - | + | - | |**Promotion |-------|-------|----------|----|------|---------|-------| | Add(E) \ Pre(I) ­ ¯| - | - | - | + | - | + | - | | Del(E) \ Pre(I) ­ ¯| - | - | - | + | - | + | - | | Del(E) \ Add(I) ­ ¯| - | - | - | + | - | + | - | | Add(I) \ Pre(E) ­ ¯| - | - | - | + | - | + | - | | Del(I) \ Pre(E) ­ ¯| - | - | - | + | - | + | - | | Del(I) \ Add(E) ­ ¯| - | - | - | + | - | + | - | ================================================================================= About Cyclic update. This option acts as MTC-goal-pick-up does, in removing, from the goal list, all possible preconditions that can be achieved in one cycle of the chosen planning procedure. Therefore, when this option is on, it is as if you selected MTC-goal-pick-up, although the first-goal-pick-up runs ok with it. But when the MTC-goal-pick-up is first selected, the cyclic update of the goal list is an option. In Subbarao Kambhampati's papers (see the references below), Establisher protection is called Interval protection; Contributor protection is not cited. However, his contributor protection is both my establisher and contributor protections. Finally, Interaction protection is called Unambiguous ordering. Note that back in (december) 1990, Pweak was able to simulate a planning procedure called Pweak (hence its name) and Tweak. UA came as a procedure designed from Pweak from the original procedure by the end of 1992 (with a simpler "interacts?" metrics than that of UA). This has been designed and ported on the Macintosh since March 1994 on top of the original 1990 Pweak procedure. The other options have been added since the Macinstosh version and with the help of Subbarao Kambhampati's papers. [References] About the very first PWEAK planning procedure? [*] ƒric JACOPIN & Jean-Franois PUGET, "From TWEAK to PWEAK: Reducing the Non-Linear Planning Framework", Laforia Technical Report 27/90, 12 pages. About Tweak (difficult paper)? [*] David CHAPMAN, "Planning for Conjunctive Goals", Artificial Intelligence 32, pages 333--377. About UA (brilliant, must read, papers)? [*] Steven MINTON, John BRESINA & Mark DRUMMOND, "Commitment Strategies in Planning: A Comparative Analysis", Proceedings of IJCAI'91, pages 259--265. Also technical report FIA-91-08 (December 1991), NASA Ames Research Center, AI Research Branch, 29 pages. Also Journal of Artificial Intelligence Research 2 (1994), pages 227-262. About SNLP (don't hope too much)? [*] David McALLESTER & David ROSENBLITT, "Systematic Nonlinear Planning", Proceedings of the 9th AAAI (July 1991), pages 633--639. A (very bad and very inefficient) Prolog Implementation of SNLP? First read the SNLP paper and then duplicate this code. And then look at the code in Pweak which simulates SNLP: much much faster! [*] Yoav SHOHAM, "Artificial Intelligence Techniques in Prolog", Morgan Kaufmann (1994), pages 225-233. About comparing planners (brilliant, must read, paper)? (McNonLin) [*] Subbarao KAMBHAMPATI, "Design Tradeoffs in Partial Order (Plan Space) Planning", Proceedings of the 2nd International Conference on Artificial Intelligence Planning Techniques (Chicago, June 1994), pages 92--97.. Much longer version than the previous paper; try to implement the procedure of the previous paper first; when you're stuck, switch to this paper. When you're stuck again, ask rao; but don't tell him I told you so. Better description of McNonLin. [*] Subbarao KAMBHAMPATI, Craig KNOBLOCK & Qiang YANG, "Planning as refinement Search: A Unified Framework for Evaluating Design Tradeoffs in Partial-Order Planning", Special issue of Artificial Intelligence on Planning and Scheduling, Volume 76:1-2, pages 167--238. Comparison of efficiency between McNONLIN, TWEAK and SNLP? [*] Craig KNOBLOCK & Qiang YANG, "Relating Performance of Partial Order Planning Algorithms to Domains Features", ACM SIGART Bulletin Volume 6, Number 1, ACM Press (1995), pages 8--15. ¥ Tracing Pweak :========================================================== Before running Pweak, either hit Apple-T or select "Trace planning". The trace is then printed in the Open Prolog Worksheet window, as soons as Pweak's run has begun. However, any Open Prolog window can only contain 32Kb of text. This is very few regarding all the tracing information that is printed: the 32Kb limit is reached very quickly. You can save this trace in a file and prevent from writing it in the Open Prolog Worksheet by selecting submenu 'Auto-saving only' of the 'Solutions' menu. Once tracing has been switched on and Pweak is running, tracing cannot be switched off. One must wait for Pweak to terminate or Open Prolog to be aborted in order to switch off tracing. ¥ Pweak's user files :===================================================== In the :Pweak:User folder, there are four files which give the user some control over Pweak. ¥¥ The 'configurations' file :--------------------------------------------- This file contains a expression of the form: define(configurations_list, c_l(['From menus', '-', 'McNonLin', 'Pweak', 'SNLP', 'Tweak', 'UA', '-', 'McNonLin_MTC', 'SNLP_UA', 'SNLP_MTC', 'Tweak_visit' ])). All the strings are names of files contained in the 'Pweak:Configurations' folder. When Pweak is loaded, this list is read and the planning configurations menu of Pweak is constructed from it. ¥¥ The 'constraints' file :------------------------------------------------ There, you can define your own constraints to be used in the corresponding var. constraints field of an action description. To use them during the planning process, the 'Variable constraints' menu must be selected prior to any run. This selection can be automatic if you add pps(var_constraints) in the user preferences files (see below). ¥¥ The 'examples_list' file :---------------------------------------------- This file contains a expression of the form: define(examples_list, e_l(['2-counter machine', 'Chapman''s 4 blocks', 'Disprover 3rd IJCAI', '2-register swapping', '2-SAT',hierarchical, 'Block Exchange', 'Looping Tweak', 'Sussman Anomaly', 'Pengi planning', 'TM simulates LBA', 'Towers of Hanoi', 'Doubled Sussman Anomaly', 'Non-Polynomial Sussman Anomaly', 'Old WK Useful', 'Polynomial Sussman Anomaly', 'Simulating a counter', 'Empty problem', 'Five blocks', 'LBA (G0011D -> GXXYYD)', 'Looping Pweak', 'Turing (B0011B -> BXXYYB) (C)', 'Turing (BXBYB -> BXXYB) (J)', 'Turing (BXYB -> BYXB) (C)', 'Turing (BXYB -> BYXB) (J)' ])). All the strings are names of files contained in the 'Pweak:Examples' folder. When Pweak is loaded, this list is read and the examples menu of Pweak is constructed from it. Before contruction, it is first sorted in alphabetical order. If you want to add an example in the Pweak's menu of examples, you must: (i) place your file in the 'Pweak:Examples' folder and (ii) add the name of your file anywhere in the above list of the 'examples_list' file. Or you can (i) place your file in the 'Pweak:Examples' folder and (ii) select the 'Add example...' menu within Pweak and follow the intructions; Pweak shall automatically adds your example filename to the list above and update the menus accordingly. At the top of the submenu constructed from the list above, there are two menus: one to add (resp. to delete) an example to (resp. from) both the list in the file and the examples menu. No checking is made at addition time. The existence of a menu is checked before deletion; the user is warned when the menu does not exist. For both menus, a dialog box is opened after selection, asking the user to give a menu name to be either added or else deleted. For instance, if you want to delete 'Looping Pweak' from the menus (and the examples file), type Looping Pweak (with no quotes) in the editable field of the dialog box. ¥¥ The 'preferences' file :------------------------------------------------ This file contains an expression of the form (this is an example): pweak_gestalt([solutions(first_and_stop,1), partial_plan_space(establisher_protection,promotion), partial_plan_space(establisher_protection,demotion), search(depth_first), interactor_protection(add_tn_pre_in,demotion), interactor_protection(del_tn_pre_in,promotion), e_r(promotion), e_r(demotion), goal_list_management(queue), precondition_pick_up(first) ]). Mots of the predicates contained in the pweak_gestalt list correspond to an option that can be selected from either a menu or else a dialog box. Switching on or off an option design a planning procedure (see ¥¥ What options for which planners? above). These options are written in a solution file when solutions are written in a solution file. They are also written in a special option window when the 'Pweak's current gestalt...' menu is selected. When this menu is selected, use the Window menu of Open Prolog to toggle between windows. Once some options have been selected they can be written in the file ':Pweak:User:preferences' using the 'Save preferences' menu. At boot time for Pweak, they are used to pre-select the menus, when Pweak is loaded (after double clicking on (i) the Open Prolog Worksheet of the Pweak Folder or (ii) any alias of the Open Prolog Worksheet of the Pweak Folder). For instance, the predicate solutions(first_and_stop,1) shall select the corresponding option in the "Solution Management..." dialog box. Consequenlty, if you wish to pre-select some options, then you just need to add the options to the list contained in the ':Pweak:User:preferences' file. Please note that option search(depth_first) SHOULD ALWAYS appear in the preference list. ¥ Known bugs :============================================================= This section contains informations about present bugs contained in the version you are running. These bugs may or may not be corrected in future versions. ***** Interval [Establisher,Needer] Management do note DeInteract correctly ***** (fixed with 0.91d1) /** end of file Pweak_info ************************************************/