### ### Table of Contents, ht2.s7 ### ### i. Initializations and loads ### I. Evaluation criteria ### II. Selection space setup ### III. Evaluation operators ### ### Copyright 1994. F. E. Ritter & R. M. Young. ### ### Last substantially modified: 4-Jan-98 RMY ### ### 4-Jan-98 Richard Young - Rationalised the evaluation criteria ### - Removed the pass-up-result operator ### (since equivalent to a goal-recognition rule) ### - Some other minor simplifications ### 3-Nov-96 Frank Ritter - converted to Soar 7.0.4. ### 16/4/96 Richard Young - Minor mods to avoid need for default rules ### 10/2/96 Frank Ritter - convert to Soar7 ### 5/7/95 Gary Jones - NNPSCM conversion. ### ### 27/7/95 Gary Jones - Altered references to to be . ### For example, state is now state . ### Just to make it easier to understand. ### Also commented out two of the default rules, ### one which is now a duplicate, the other ### no longer need apply (and gives an error). ### ### 10/8/95 Gary Jones - Commented out duplicate default rule ### default*selection*propose*evaluate-object. ### ### ht2.s7 loads ht.s7 but: ### - There is also a selection space for assessing Eat best etc. ### ### ### i. Initializations and loads ### ## For safety, excise -all excise -all ## Build upon the previous version of hungry-thirsty: source "ht.s7" ## This is done in file ht.s7 ## learn -off ## echo "learn -off " ## Remove a production so that we get forced into an impasse excise ht*compare*eat*better*drink ### ### I. Evaluation criteria ### ### ### Provide the evaluation criteria, in the default selection ### space (created below in a simplified form in Sections II and III). ### Our approach is to evaluate each of the possible situations: ### Eat, when hungry = yes, yes (and want not to be), or no ### Drink, when thirsty = yes, yes (and want not to be) or no ### The values are "good", "excellent", or "poor", respectively. ### We also have to add the semantics for the evaluations: ### - anything "excellent" is better than anything "good" (and indifferent) ### - anything "excellent" is better than anything "poor" (and indifferent) ### - anything "good" is better than anything "poor" (and indifferent) ### - anything "poor" is indifferent with anything else "poor" sp {selection*evaluate*eat*hungry*want-not (state ^problem-space.name selection ^operator ^superstate ) ( ^name evaluate-object ^object ) ( ^name eat) ( ^hungry yes ^desired ) ( ^hungry no) --> ( ^evaluation + &) ( ^value t ^object ^quality excellent)} sp {selection*evaluate*eat*hungry*dont-care (state ^problem-space.name selection ^operator ^superstate ) ( ^name evaluate-object ^object ) ( ^name eat) ( ^hungry yes ^desired ) -( ^hungry no) --> ( ^evaluation + &) ( ^value t ^object ^quality good)} sp {selection*evaluate*eat*hungry-no (state ^problem-space.name selection ^operator ^superstate ) ( ^name evaluate-object ^object ) ( ^name eat) ( ^hungry no) --> ( ^evaluation + &) ( ^value t ^object ^quality poor)} sp {selection*evaluate*drink*thirsty*want-not (state ^problem-space.name selection ^operator ^superstate ) ( ^name evaluate-object ^object ) ( ^name drink) ( ^thirsty yes ^desired ) ( ^thirsty no) --> ( ^evaluation + &) ( ^value t ^object ^quality excellent)} sp {selection*evaluate*drink*thirsty*dont-care (state ^problem-space.name selection ^operator ^superstate ) ( ^name evaluate-object ^object ) ( ^name drink) ( ^thirsty yes ^desired ) -( ^thirsty no) --> ( ^evaluation + &) ( ^value t ^object ^quality good)} sp {selection*evaluate*drink*thirsty-no (state ^problem-space.name selection ^operator ^superstate ) ( ^name evaluate-object ^object ) ( ^name drink) ( ^thirsty no) --> ( ^evaluation + &) ( ^value t ^object ^quality poor)} ### Now the semantics for the evaluations. ### Notice how these return preferences in the higher context. ### Anything "excellent" is better than anything "good" (and indifferent) sp {selection*evaluation*semantics*excellent-good (state ^problem-space.name selection ^superstate ) ( ^evaluation ) ( ^value t ^object ^quality excellent) ( ^value t ^object ^quality good) --> ( ^operator > ^operator =)} ### Anything "excellent" is better than anything "poor" (and indifferent) sp {selection*evaluation*semantics*excellent-poor (state ^problem-space.name selection ^superstate ) ( ^evaluation ) ( ^value t ^object ^quality excellent) ( ^value t ^object ^quality poor) --> ( ^operator > ^operator =)} ### Anything "good" is better than anything "poor" (and indifferent) sp {selection*evaluation*semantics*good-poor (state ^problem-space.name selection ^superstate ) ( ^evaluation ) ( ^value t ^object ^quality good) ( ^value t ^object ^quality poor) --> ( ^operator > ^operator =)} ### Anything "poor" is indifferent with anything else "poor" sp {selection*evaluation*semantics*indifferent (state ^problem-space.name selection ^superstate ) ( ^evaluation {<> }) ( ^value t ^object ^quality poor) ( ^value t ^object ^quality poor) --> ( ^operator =)} ### ### II. Selection space setup ### ### We use several rules taken from default rules and slightly ### simplified them to set up this selection space. ### ### ********************************************************** ### Like most bodies of knowledge, there are places that are difficult ### for novices, and in Soar, this is such an area. We don't ### particularly expect you in your first day to understand all that ### is here. You may wish to ignore this part of the model and continue ### on. ### ********************************************************** ### ### The slightly different formating between rules comes from the ### default productions file's various formats. ### A. default*selection*propose*space*selection ### Use the selection problem space for all multiple choice impasses. ### make it acceptable (+) but worst (<) so that nearly any other ### space will dominate. sp {default*selection*propose*space*selection :default (state ^choices multiple) --> ( ^problem-space

+

< ) (

^name selection)} ### ### III. Evaluation operators ### ## ## 7.3.1 The evaluate-object operator ## ### A. default*selection*propose*operator*evaluate-object ### Create evaluate operator in selection problem space. ## The squiggly brackets indicate a set of grouped clauses. ## The - sign means that the set of clauses must not be matched ## in order for the production to fire. ### Create evaluate operator in selection problem space. sp { default*selection*propose*evaluate-object :default (state ^problem-space.name selection ^item ) -{( ^evaluation ) ( ^object ^value t)} --> ( ^state ^name evaluate-object ^object ) ( ^operator +)} ### B. default*selection*select*operator*evaluate-object*indifferent ### The '=' indicates an indifferent preference. sp { default*selection*select*evaluate-object*indifferent ### The '=' indicates an indifferent preference. sp { default*selection*select*evaluate-object*indifferent :default (state ^problem-space.name selection ^operator +) ( ^name evaluate-object) --> ( ^operator =)} ### ### Reconsider evaluation operator after it finishes to allow next one ### in. ### sp {default*terminate*evaluate-object :default (state ^operator ) ( ^evaluation ) ( ^object ) ( ^object ^value ) --> ( ^operator @)} ###--------------------------------------------------------------- ### END OF FILE ###---------------------------------------------------------------