Logic Programming Paradigm

Transcription

1 Logic Programming Paradigm Sample Courseware Logic Programming Paradigm Logic programming offers a formalism for specifying a computation in terms of logical relations between entities. A logic program consists of a collection of logic statements describing a certain state of affairs. In order to write a program in such a language, the programmer must first describe all the relevant logical relationships between the various entities. A computation in essence, amounts to determining whether a particular conclusion follows from those logical statements. The implementation of a logic programming language provides an automatic theorem prove which is used to establish the validity of the conclusion. An important point to writing logic programs is to model the domain (or state of affairs) in terms of logical relations. The relative ease with which this can be done depends on the domain itself. The following section provides some insights on how to represent "ordinary" statements in logic programming. A Logical Data Model operates with so-called Facts. Generally speaking, fact is any expression which can be interpreted as True or False. Examples: Alex is a nice guy. 25 > = 66 Smith is a student and he got "2" for examination on Software Paradigms Facts are presented as so-called structured terms that are made of several components. 1 Predicates (Structured Terms) file:///e /LV_CD/wbtmaster/main_library/swp4.htm (1 of 32) [10/16/2002 4:15:41 PM]

2 A structured term is syntactically formed by a functor (also called a predicate symbol) and a list of arguments. The list of arguments appears between parentheses. Each argument is separated from the following one by a comma. Examples: Functor Arguments Alex is a nice guy. niceguy (Alex) 25 > 36 greaterthan (25,36) = 66 plus (25,41,66) Smith is a student and he got "2" for examination on Software Paradigms exam ('Smith','Software Paradigms',2) A structured term is syntactically formed by a functor (also called a predicate symbol) and a list of arguments. The list of arguments appears between parentheses. Each argument is separated from the following one by a comma. Each argument of a predicate is a so-called term, for example, it can be another predicate (structured term). The number of arguments of a structured term is called its arity. Examples: greaterthan(9, 6) exam(a, b, h(c,d)) plus(2, 3, 5) An important point to mention is that a structure is simply a mechanism for combining terms together, thus forming more complex ones but without performing any implicit evaluation. So for instance, in the last example above, the integers 2, 3, and 5 are combined with the functor plus. An equally valid combination, albeit a slightly misleading one, could be plus(2, 3, 7). If evaluated, plus(2,3,5) is True plus(2,3,7) is False file:///e /LV_CD/wbtmaster/main_library/swp4.htm (2 of 32) [10/16/2002 4:15:41 PM]

3 An atom can be formed in four ways: A letter, which can possibly be followed by other letters (either case), digits, and the underscore character. Examples: a greaterthan two_b_or_not_2_b A string of special characters such as: + - * / \ = ^ < > :. # $ & Examples: <> ##&& ::= A string of any characters enclosed within single quotes. Examples: 'ABC' '1234' 'a<>b' In the third case above, if what appears between the single quotes is a valid atom as specified by one of the first two cases, then the quotes are optional. Thus, 'abc' and abc represent the same atom. Applications involving heavy numerical calculations are rarely written in Logic Programming Languages. In fact, Logic Paradigm is not particularly well suited to write such applications. Nevertheless, the paradigm provides representation for integers and real numbers. The following examples illustrate integer representation: Examples: Real numbers can be written in standard or scientific notation. A decimal point must appear in all real numbers and there must be at least one digit on either side of it. Several points with respect to the representation of numbers are implementation dependent. A brief list of some of these points follows. The actual range of numbers (real and integer) that can be represented. Examples: e e-3-2.6e-2 file:///e /LV_CD/wbtmaster/main_library/swp4.htm (3 of 32) [10/16/2002 4:15:41 PM]

4 A variable is a name for value which can change while an evaluation is running. Examples: StudentName may be 'Johns', 'Mayer', 'Ivanov', etc. ExaminationMark may be 1, 2, 3, 4 and 5 GoodGuy may be True and False Set of all possible values which may have a particular variable is called a variable scope or a variable range. Please note the following (!) A predicate (structured term) having all arguments as constants is called a fact. A particular Fact can be either true or false. Example: greaterthan (25,36) is False plus (25,41,66) is True Why? Because we know formal rules to validate the facts and can communicate these rules to computers, i.e. an algorithm can be defined. Such terms are called computational terms. niceguy(alex) is True exam('smith','software Paradigms') is False Why? Because we know that from our own experience which cannot be formalized as an algorithm. We can simply put such knowledge into a computer's memory by listing all facts which are valid. For example, we can list all guys who considered to be nice or list all students who pass an examination on software paradigms. Such facts are called basic facts or database facts. Formally speaking, a logic programming paradigm heavily rely on a database of persistent data objects which list all basic facts which are valid. If a particular basic fact cannot be found in such database, it is considered to be false. A predicate (structured term) having at least one variable argument is called a file:///e /LV_CD/wbtmaster/main_library/swp4.htm (4 of 32) [10/16/2002 4:15:41 PM]

5 logical function or simply predicate. All variables used for definition of such predicate are called free variables. A particular logical function maps each combination of free variable values onto True/False boolean value. In other words, predicate can be true or false depending on a particular combination of free variable values. Example: greaterthan (25,X) is a function of variable "X" F(X) greaterthan(25,x) is True if X = 26, 27, etc. the same predicate is false if X = 25, 24, etc. Example: plus (X,Y,66) is a function of variables "X and Y" F(X,Y) plus(x,y,66) is True if {X,Y} = {1,65}, {2,64}, {3,63}, etc. the same predicate is false if, for example, {X,Y} = {30,45} or {X,Y} = {55,55}. Example: niceguy(x) is is a function of variable "X" F(X) niceguy(x) is True if X = "Alex" and "Alex" can be found among persistent database objects "niceguy". Example: exam(studentname,vo) is a function of variables "StudentName and VO" F(StudentName,VO) exam(studentname,vo) True if StudentName = "Alex", VO = "Software Paradigm" and ("Alex","Software Paradigms" can be found among persistent database objects "exam"), 2 Logical Operations and Composite Predicates In order to specify a computation in terms of logical relations between entities, we need a mechanism to compose a new predicate of one or more simple predicates. Moreover, we need to define special rules for evaluating such composite predicates. file:///e /LV_CD/wbtmaster/main_library/swp4.htm (5 of 32) [10/16/2002 4:15:41 PM]

6 This section describes the predicate composition techniques and rules necessary to evaluate composite predicates. 2.1 Logical Operations Syntactically, a predicate can be composed of one or more simple predicates using logical operation "&" logical "and", " " logical "or", " " logical "not" and brackets. Example: greaterthan(25,36) & plus(55,11,66) is True because greaterthan(25,36) is True and plus(55,11,66) is True Example: niceguy('alex') exam('alex','software Paradigms') is True if one of the facts: niceguy('alex') or exam('alex','software Paradigms') can be found in the database. The operator precedence for the '&' and ' ', operators follow the standard precedence rules, i.e. '&' binds stronger than ' '. Thus, F1 & F2 F3 == ( F1 & F2 ) F3 Explicit use of parenthesis, as in predicate above, is required to override this default precedence. Thus if the intention is for the ' ' operator to bind stronger in the above expression, it has to be written as F1 & (F2 F3) Example: niceguy('alex') & niceguy('tom') exam('tom', 'Software Paradigm',1) is True if both basic facts: niceguy('alex') and niceguy('tom') are True or the other fact exam('tom','software Paradigms',1) is true. In other words, if the fact exam('tom','software Paradigms',1) is true, it is already sufficient for the whole expression to be valid (true). Example: file:///e /LV_CD/wbtmaster/main_library/swp4.htm (6 of 32) [10/16/2002 4:15:41 PM]

7 niceguy('alex') & (niceguy('tom') exam('tom', 'Software Paradigm',1)) is True if basic fact: niceguy('alex') is true and the composite predicate niceguy('tom') or exam('tom','software Paradigms',1) is true. In other words, if the fact exam('tom','software Paradigms',1) is true, it is not sufficient for the whole expression to be valid (true). 2.2 Quantifiers Predicates may also include variable quantifiers, specifically: the existential quantifier, denoted by the symbol, and the universal quantifier, denoted by the symbol These quantifiers quantify variables. An existentially quantified variable, say X, is written " " and is read as "there exists an X such that...". A universally quantified variable is written as " " and is read as "for all X...". Quantification is applied to a formula and is written preceding it. For example, x (greaterthan(y,x) & greaterthan(12,y)) would be read as "there exists an X such that X is less than Y and Y is less than 12". The formula to which the quantification is applied is called the scope of quantification. Occurrences of quantified variables in the scope of quantification are said to be bound (existentially or universally). The scope is normally obvious from the written expressions, but if ambiguities might otherwise arise, we will use parenthesis to delimit scope. Informally, the formula " X ( <expr> )" asserts that there exists at least one value of X (from among its range of values) such that is true. This assertion is false only when no value of X can be found to satisfy. On the other hand, if the assertion is true, there may be more than one such value file:///e /LV_CD/wbtmaster/main_library/swp4.htm (7 of 32) [10/16/2002 4:15:41 PM]

8 of X, but we don't care which (!). Thus, the truth of an existentially quantified expression is not a function of the quantified variable(s). As an example, consider the unquantified expression greaterthan(y,x) & greaterthan(12,y) == F(X,Y) and suppose X ranges over {4,15} and Y over {7,14}. The truth table for the expression is: X Y F(X,Y) 4 7 true 15 7 false 4 14 false false Now consider the same expression but with X existentially quantified: X(greaterThan(Y,X) & greaterthan(12,y)) == F(Y) Since we don't care which value of X makes the expression true as long as there is at least one, its truth depends only on the unbound variable Y: The truth table for the expression is: Y F(Y) 7 true 14 false The truth of a quantified expression does depend, of course, on the range of permitted values of the quantified variables. Let's turn now to the universal quantifier. Informally, the formula " X ( <expr> )" asserts that for every value of X(from among its range of values) <expr> is true. Like the existential quantifier, the truth of an existentially quantified expression is not a function of the quantified variable(s). As an example, consider the unquantified expression greaterthan(y,x) greaterthan(12,y) == F(X,Y) and suppose X ranges over {4,15} and Y over {7,14}. The truth table for the expression is: X Y F(X,Y) 4 7 true 15 7 true 4 14 true false file:///e /LV_CD/wbtmaster/main_library/swp4.htm (8 of 32) [10/16/2002 4:15:41 PM]

9 Now consider the same expression but with X universally quantified: X(greaterThan(Y,X) greaterthan(12,y)) == F(Y) In a sense, like the existentially quantified variable, we don't care what the values of X are, as long as every one of them makes the expression true for any given Y. Thus its truth table is: The truth table for the expression is: Y F(Y) 7 true 14 false Note that the different types of quantifiers can be mixed. But note also that their order is significant, i.e. x y ( <expr> ) is not the same as y x ( <expr> ). Suppose, for example, a predicate is_a_mother(m,ch) defines a set of database facts " M is the mother of Ch". Ch M (is_a_mother(m,ch)) asserts that everyone has a mother. Whereas, M Ch (is_a_mother(m,ch)) asserts that there is a single individual (M) who is the mother of everyone! Let us now be more precise about the valid forms of predicates involving variables. Such valid forms are called well-formed formulae (WFF) and are defined as follows: 1. F(X1,... Xn) is a WFF where X1, X2,.. are called free variables Example: niceguy(x), exam(x,y,m), greaterthan(a,b) 2. F1 & F2 and F1 F2 are WFFs if F1 and F2 are WFFs Example: niceguy(x) & niceguy(y) exam(x, S, "1") 3. (F) is a WFF if F is a WFF Example: niceguy(x) & (niceguy(y) exam(x, S, "1")) 4. x (F(X)) and x (F(X)) are WFFs if F(X) is a WFF with a free occurrence of the file:///e /LV_CD/wbtmaster/main_library/swp4.htm (9 of 32) [10/16/2002 4:15:41 PM]

10 variable X. In this case, X is called a bound variable in the scope of F(x). Example: x(niceguy(x) & exam(x, S, "1")) 3 Rules of Inference Any programming paradigm deals with organizing computations. In logic programming paradigm computation are defined in a form of rules of inference. Rules of inference, in turn, are defined in a form of so-called clauses. 3.1 Head and Body The general form of clauses is as follows: [head] :- [body] Note, these two component (body and head) may be also called conclusion and premise respectively. [conclusion] :- [premise] where body (premise) is a WFF (logical expression) head (conclusion) is a predicate If we do not use variables, both components (i.e. head and body) are facts. The rule is interpreted as follows: "If a body is valid (true) then head is also valid (true) by definition" file:///e /LV_CD/wbtmaster/main_library/swp4.htm (10 of 32) [10/16/2002 4:15:41 PM]

11 For example, we can define the following rule of inference: humanbeing('alex'):-goodguy('alex') if Alex is a good guy, then he is a human being. Suppose, fact enrollvo('alex', 'Programming') is true if a student "Alex" is enrolled for the course "Programming". Suppose also, the fact locvo('programming', 'Thursady, 'Room 22') is true if the classes on Programming take place in room 22 on Thursday. For example, we can define the following rule of inference: mustgo('alex', 'Thursday','Room 22') :- enrollvo('alex', 'Programming') & locvo('programming', 'Thursday', 'Room 22') meaning that the fact mustgo('alex', 'Thursday', 'Room 22') is true if both facts enrollvo('alex', 'Programming') and locvo('programming', 'Thursday', 'Room 22') are true. Actually, all the examples above are not very illustrative because rules of inference are almost never defined without variables. If we use variables, both components (i.e. head and body) are predicates. The rule is interpreted as follows: "If a body is valid (true) for a particular combination of values of free variables then the head is also valid (true) for the same combination of values of free variables" For example, we can define the following rule of inference: humanbeing(x):-goodguy(x) any (!) good guy is a human being. Suppose, predicate enrollvo(student, Subject) is true if a student is enrolled for a course on this particular subject. Suppose also, the predicate locvo(subject, Day, Room) is true if classes on this particular subject takes place in this room and on this day. For example, we can define the following rule of inference: mustgo(student, Room, Day, Subject) :- enrollvo(student, Subject) & locvo(subject, Day, Room) file:///e /LV_CD/wbtmaster/main_library/swp4.htm (11 of 32) [10/16/2002 4:15:41 PM]

12 meaning that a particular student should be in a particular room on a stipulated day, if he/she enrolled for a classes and this classes take place in this room on that day. Predicates enrollvo and locvo definitely operates on database facts, i.e. system should search an internal database to find whether, for example, the fact enrollvo('alex', 'Programming') is true or false. Suppose, the database looks as follows: locvo( Subject Day Room) Hypermedia Monday Room 22 Databases Tuesday Room 23 Programming Thursday Room 22 enrollvo( Student Subject) Palina Hypermedia Palina Programming Alex Databases Alex Programming Result of application the following rule of inference: mustgo(student, Room, Day, Subject) :- enrollvo(student, Subject) & locvo(subject, Day, Room) to the above mentioned basic facts is a number of inferred facts (!) can be seen as the following table: mustgo( Student Room Day Subject) Palina Room 22 Monday Hypermedia Palina Room 22 Thursday Programming Alex Room 23 Tuesday Databases Alex Room 22 Thursday Programming In other words, the system automatically infer such facts as mustgo(palina,room 22, Monday, Hypermedia) is true: "Palina should go to Room 22 on Monday to participate in classes on Hypermedia" mustgo('alex','room 22', 'Monday', 'Hypermedia') is false: "Alex has nothing to do in Room 22 on Monday" The last example suggest that perhaps we should simplify the rule by removing the Subject variable from the head: mustgo(student, Room, Day) :- enrollvo(student, Subject) & locvo(subject, Day, Room) file:///e /LV_CD/wbtmaster/main_library/swp4.htm (12 of 32) [10/16/2002 4:15:41 PM]

13 and inferring the following facts: mustgo( Student Room Day) Palina Room 22 Monday Palina Room 22 Thursday Alex Room 23 Tuesday Alex Room 22 Thursday Actually, this rule mustgo(student, Room, Day) :- enrollvo(student, Subject) & locvo(subject, Day, Room) is erroneous because free variables in the head of the rule are not identical to the variables in the body. Following to the formal definition of a rule of inference: "If a body is valid (true) for a particular combination of values of free variables then the head is also valid (true) for the same combination of values of free variables" the system simply cannot make conclusion on whether the expression mustgo('alex','room 22', 'Thursday') is true or false. In order to verify the fact: mustgo('alex','room 22', 'Thursday'), the system should evaluate the following expression: enrollvo('alex', Subject) & locvo(subject, 'Room 22', 'Thursday') Obviously the expression is not a fact and depends on a particular value of variable "Subject". For example, it is true, if subject is "programming" and false for any other value. enrollvo('alex', 'Programming') & locvo('programming', 'Room 22', 'Thursday') is true enrollvo('alex', 'Databases') & locvo('databases', 'Room 22', 'Thursday') is false There is of course an obvious solution for the problem: existential quantifier ( ). Thus, we can define the rule as the following: mustgo(student, Room, Day) :- Subject (enrollvo(student, Subject) & locvo(subject, Day, Room)) The above predicate (body) is true if there exists at least one subject such that the condition file:///e /LV_CD/wbtmaster/main_library/swp4.htm (13 of 32) [10/16/2002 4:15:41 PM]

14 enrollvo(student, Subject) & locvo(subject, Day, Room) is true. In other words, the fact mustgo('alex','room 22', 'Thursday') is definitely true since there exists a subject, for example, "Programming" such that enrollvo('alex', 'Programming') & locvo('programming', 'Room 22', 'Thursday') is true. mustgo( Student Room Day) Palina Room 22 Monday Palina Room 22 Thursday Alex Room 23 Tuesday Alex Room 22 Thursday 3.2 Recursion Recursive definition of rules of inference is a very powerful and commonly used method of logic programming. Suppose, we have a predicate parent(g,d) the predicate identifies whether a person D is a child of person G. We can easily define a new predicate descendent(g,d) that identifies whether a person D is a descendent of person G as descendent(g,d):-parent(g,d) X (parent(g,x) & descendent(x,d)) Note that rules like this one, can be defined more clearly using a number of rules of inference with one and the same head. descendent(g,d):-parent(g,d) descendent(g,d):- X (parent(g,x) & descendent(x,d)) first rule for finding direct descendent just copy all facts "parent" as facts "descendent" the second rule uses the same head predicate (i.e., recursion) to find indirect descendent. Here, if the inferred fact is true in accordance with one of the rules, it is considered file:///e /LV_CD/wbtmaster/main_library/swp4.htm (14 of 32) [10/16/2002 4:15:41 PM]

15 to be true generally. Consider the following genealogy tree: It may be described as the following facts: parent( G D) Nick Pauline Pauline Alex Pauline Paul Alex Tom Application of the rule: descendent(g,d):-parent(g,d) results in the following inferred facts descendent( G D) Nick Pauline Pauline Alex Pauline Paul Alex Tom Application of the rule: descendent(g,d):- X (parent(g,x) & descendent(x,d)) results in the following inferred facts descendent( G D) X Nick Alex Pauline parent('nick','pauline') & descendent('pauline','alex') Nick Paul Pauline parent('nick','pauline') & descendent('pauline','paul') Pauline Tom Alex parent('pauline','alex') & descendent('alex','tom') Nick Tom Pauline parent('nick','pauline') & descendent('pauline','tom') file:///e /LV_CD/wbtmaster/main_library/swp4.htm (15 of 32) [10/16/2002 4:15:41 PM]

16 3.3 Inferred Calculations In Logic Programming, calculation are performed by means of computational terms looking as, for example, follows: plus(v1,v2,r) the predicate is true if R = V1 + V2; mult(v1,v2,r) the predicate is true if R = V1 * V2; etc. For example, plus(10,20,30) is true; plus(12,14,30) is false; plus(10,20,200) is true; plus(12,14,300) is false; Consider, for example, a well-known example of a so-called bill of materials that identify which components and in which amount are needed to assembly a particular product / another component: It may be described as the following facts: need( P C Q) D_A D_B 5 D_B D_D 3 D_B D_C 8 D_D D_E 4 The following rules identify how many direct and indirect components are needed to assembly a particular product / component need+(p,c,q):-need(p,c,q) need+( P,C,Q):- X Q1 Q2(need(P,X,Q1) & need+(x,c,q2) & mult(q1,q2,q)) file:///e /LV_CD/wbtmaster/main_library/swp4.htm (16 of 32) [10/16/2002 4:15:41 PM]

17 Application of the rule: need+(p,c,q):-need(p,c,q) results in the following inferred facts need+( P C Q) D_A D_B 5 D_B D_D 3 D_B D_C 8 D_D D_E 4 Application of the rule: need+( P,C,Q):- X Q1 Q2(need(P,X,Q1) & need+(x,c,q2) & mult(q1,q2,q)) results in the following inferred facts need+( P C Q) X Q1 Q2 D_A D_D 15 D_B 5 3 need(d_a,d_b,5) & need+(d_b,d_d,3) & mult(5,3,15) D_A D_C 40 D_B 5 8 need(d_a,d_b,5) & need+(d_b,d_c,8) & mult(5,8,40) D_B D_E 12 D_C 3 4 need(d_b,d_c,3) & need+(d_c,d_e,4) & mult(3,4,12) D_A D_E 60 D_B 5 12 need(d_a,d_b,5) & need+(d_b,d_e,12) & mult(5,12,60) 3.4 Functions and Variables Defining calculations as computational predicates involving multiple bound variable as, for example, need+( P,C,Q):- X Q1 Q2(need(P,X,Q1) & need+(x,c,q2) & mult(q1,q2,q)) may constitute a serious problem. Functions provide much more straight and simple way to define calculations. A particular function may be applied to a number of free variables and be reused further as a variable. For example, the previously defined rule of inference need+ may be defined in much more clear way as: need+( P,C,(Q1 * Q2)):- X (need(p,x,q1) & need+(x,c,q2) ) where notation (Q1 * Q2) is used in a normal mathematical way file:///e /LV_CD/wbtmaster/main_library/swp4.htm (17 of 32) [10/16/2002 4:15:41 PM]

18 Application of this rule need+( P,C,(Q1 * Q2)):- X (need(p,x,q1) & need+(x,c,q2) ) results in the same list of inferred facts, but the inference procedure is much simple need+( P C Q) X Q1 Q2 D_A D_D 15 D_B 5 3 need(d_a,d_b, 5) & need+(d_b,d_d, 3) D_A D_C 40 D_B 5 8 need(d_a,d_b, 5) & need+(d_b,d_c, 8) D_B D_E 12 D_C 3 4 need(d_b,d_c,3) & need+(d_c,d_e,4) D_A D_E 60 D_B 5 12 need(d_a,d_b,5) & need+(d_b,d_e,12) 4 Goals (Queries) The term "executing programs" in logic programming typically refers to verification of one or a collection of predicates with respect to a given set of rules of inference and basic facts. Thus, a calculation in logic programming is identified by the following components: database of basic facts set of rules of inference a given goal A computation in logic programming is initiated by a goal. file:///e /LV_CD/wbtmaster/main_library/swp4.htm (18 of 32) [10/16/2002 4:15:41 PM]

19 In a general case we should distinguish between three different types of goals: Verifier Goal Finder Goal Doer Goal 4.1 Verifier Goal Example Database of basic facts: locvo( Subject Day Room) Hypermedia Monday Room 22 Databases Tuesday Room 23 Programming Thursday Room 22 enrollvo( Student Subject) Palina Hypermedia Palina Programming Alex Databases Alex Programming Rules of inference: mustgo(student, Room, Day) :- Subject (enrollvo(student, Subject) & locvo(subject, Day, Room)) Goal (Query): file:///e /LV_CD/wbtmaster/main_library/swp4.htm (19 of 32) [10/16/2002 4:15:41 PM]

20 ? mustgo('alex', 'Room 22', 'Thursday') The output will be success or failure, depending whether the validity of this predicate (fact) could be verified or not. In this particular case, the calculation will produce a true value as a result. Example A verifier goal is a predicate without free variables, i.e. it is a fact which can be true or false depending on a given set of basic facts and rules of inference. For instance, given that we have facts and rules describing a genealogy tree, Consider the following genealogy tree: Rules of Inference: descendent(g,d):-parent(g,d) descendent(g,d):- X (parent(g,x) & descendent(x,d)) we could issue the following verifier goal:? descendent('nick','tom') This verifier goal can be paraphrased as "Is Tom a descendent of Nick?" In this case, the engine would simply return yes or no depending on the predicates of the program. Another verifier goal may look as follows:? X (parent(x,'alex') & parent(x,'paul')) The second verifier goal corresponds to the question "Are Alex and Paul siblings?". The last query is somewhat more complicated. It is composed of a conjunction of two goals which basically attempt to verify the following: "Is there a single person (X) who is a parent of Alex and parent of Paul?". Note, here we use variables to define a verifier goal, but this variable is bound with the existential quantifier. file:///e /LV_CD/wbtmaster/main_library/swp4.htm (20 of 32) [10/16/2002 4:15:41 PM]

21 Of course, goals are interpreted in a certain environment. Consider, for example, facts and rules describing a bill of materials: Rulees of Inference need+(p,c,q):-need(p,c,q) need+( P,C,(Q1*Q2)):- X Q1 Q2(need(P,X,Q1) & need+(x,c,q2)) In this environment, we could issue the following verifier goals:? X (need+('d_a','d_e',x) This verifier goal can be paraphrased as "Do we need a component "D_E" to assembly "D_A"?". Another verifier goal may look as follows:? X Y (need+(y,'d_e',x) & greaterthan(x,100)) "Are there any components where the component 'D_E' is reused in amount greater than 100?" 4.2 Finder Goal In cases in which a goal contains unbound variables, such goal is called a finder goal. A finder goal requests the logic programming system to show particular values of free variables that make this goal. To clarify this last point, let's consider some sample queries. Database of basic facts: file:///e /LV_CD/wbtmaster/main_library/swp4.htm (21 of 32) [10/16/2002 4:15:41 PM]

22 locvo( Subject Day Room) Hypermedia Monday Room 22 Databases Tuesday Room 23 Programming Thursday Room 22 enrollvo( Student Subject) Palina Hypermedia Palina Programming Alex Databases Alex Programming Rules of inference: mustgo(student, Room, Day) :- Subject (enrollvo(student, Subject) & locvo(subject, Day, Room)) Finder Goal:? mustgo('alex', X, 'Thursday') The engine is requested to show all the values satisfying the mustgo. In this particular case, the calculation will produce X = "Room 22" as a result. Finder Goal:? mustgo('alex', X, Y) The engine is requested to display all paars of values (X,Y) such that the predicate mustgo ('Alex',X,Y) is valid. In this particular case, the calculation will produce {<X,Y>} = {<Room 23, Tuesday>,<Room 22, Thursday>} as a result. Example Example "genealogy tree" Rules of Inference: descendent(g,d):-parent(g,d) descendent(g,d):- X (parent(g,x) & descendent(x,d)) Finder Goal: file:///e /LV_CD/wbtmaster/main_library/swp4.htm (22 of 32) [10/16/2002 4:15:41 PM]

23 ? descendent('nick',x) In this case, the engine will show all values for the variable X that satisfy the descendent('nick',x) predicate. X = {Pauline,Alex,Paul,Tom} Finder Goal:? X (parent(x, 'Alex') & parent(x, Y)) This goal can be paraphrased as "Get all siblings of a person "Alex"". This is interesting to note, despite the fact that we use two variables to define the goal X and Y, the system is requested to show just values for the variable Y that satisfy the X (parent(x, 'Alex') & parent(x, Y)) predicate. Variable X is bound with the existential quantifier and we do not care which particular value of the variable X satisfy the conditions parent(x, 'Alex') & parent(x, Y). Example Example "Bill of Materials": Rulees of Inference need+(p,c,q):-need(p,c,q) need+( P,C,(Q1*Q2)):- X Q1 Q2(need(P,X,Q1) & need+(x,c,q2)) Finder Goal:? need+('d_b',x, Y) Actually, we are asking systems to display list of materials needed to produce a component "D_B" and to provide additional information on quantity of the materials. <X,Y> = {<D_D, 3>, <D_C, 8>, <D_D, 12>} 4.3 Doer Goal file:///e /LV_CD/wbtmaster/main_library/swp4.htm (23 of 32) [10/16/2002 4:15:41 PM]

24 Another kind of goals in logical programming is called a Doer Goal. As the name suggests, these statements are used to communicate specific information to modify environment for other goals. In a simplest case, a doer goal simply adds/deletes basic facts. Database of basic facts: locvo( Subject Day Room) Hypermedia Monday Room 22 Databases Tuesday Room 23 Programming Thursday Room 22 enrollvo( Student Subject) Palina Hypermedia Palina Programming Alex Databases Alex Programming Rules of inference: mustgo(student, Room, Day) :- Subject (enrollvo(student, Subject) & locvo(subject, Day, Room)) Doer Goals:? delete(locvo('programming', 'Thursday', 'Room 22'))? add(locvo('software Paradigms', 'Thursday', 'Room 21')) Database of basic facts (Modified): locvo( Subject Day Room) Hypermedia Monday Room 22 Databases Tuesday Room 23 Software Paradigms Thursday Room 21 enrollvo( Student Subject) Palina Hypermedia Palina Programming Alex Databases Alex Programming Database of basic facts: file:///e /LV_CD/wbtmaster/main_library/swp4.htm (24 of 32) [10/16/2002 4:15:41 PM]

25 locvo( Subject Day Room) Hypermedia Monday Room 22 Databases Tuesday Room 23 Software Paradigms Thursday Room 21 enrollvo( Student Subject) Palina Hypermedia Palina Programming Alex Databases Alex Programming Doer Goals:? add(enrollvo('alex', 'Software Paradigms'))? delete(enrollvo('alex', 'Programming'))? add(enrollvo('palina', 'Software Paradigms')) Database of basic facts (Modified): locvo( Subject Day Room) Hypermedia Monday Room 22 Databases Tuesday Room 23 Software Paradigms Thursday Room 21 enrollvo( Student Subject) Palina Hypermedia Palina Programming Alex Databases Alex Software Paradigms Palina Software Paradigms 5 Some Implementation Issues The term "executing programs" in logic programming typically refers to verification of one or a collection of predicates with respect to a given set of rules of inference and basic facts. This verification is done according to a specific algorithm which will be presented in the next section. The term resolution mechanism is often used to refer to this algorithm. file:///e /LV_CD/wbtmaster/main_library/swp4.htm (25 of 32) [10/16/2002 4:15:41 PM]

26 5.1 Backtracking Resolution Algorithm How do deductive DBMS infer a response to a given goal? Given a program and an initial query, the resolution algorithm to verify this query can be described as follows. Phase 1: A given goal is reduced to simple sub-goals corresponding to basic facts or procedures. The process is repeated until the goal is represented as a tree having only simple sub-goals corresponding to basic facts or procedures as leaves. Such tree is called a tree on inference or resolution tree (see example below). Phase 2: Searching for values for (Verifying) the simple sub-goals and putting them together to form the response. This process is actually called a backtracking. file:///e /LV_CD/wbtmaster/main_library/swp4.htm (26 of 32) [10/16/2002 4:15:41 PM]

27 Finder goals are interpreted in a similar way. Consider the Finder Goal:? P1(X) Phase 1: The system built a resolution tree as above: Phase 2: A particularily selected term is used to select a number of basic facts which define all potentially possible values of the free variables. Such selected values are called hypothesis. Phase 3: All hypothesis are checked out as Verifier Goals to select valid values of free variables All hypothesis which are proved to be valid, are considered as a result of the finder goal. file:///e /LV_CD/wbtmaster/main_library/swp4.htm (27 of 32) [10/16/2002 4:15:41 PM]

28 5.2 Forward Resolution Algorithm Counterpart for the Backward Chaining Procedure is called Forward Chaining Procedure. The Forward Chaining Procedure deals with putting basic facts together to infer all possible new facts. Note that the Backward Chaining Procedure needs to be invoked every time when the user issues a Verifier or Finder Goal. The responce is infered dynamically and NO infered data are stored into the database. file:///e /LV_CD/wbtmaster/main_library/swp4.htm (28 of 32) [10/16/2002 4:15:41 PM]

29 On the contrary, the Forward Chaining Procedure needs to be invoked only when the database is modified (i.e. when the user issues a Doer Goal). All facts defined by means of rules of inference are infered and stored into the database. Thus, forthcoming Verifier or Finder Goals can be interpreted by means of searching such previously stored infered fact. Since, interpreting a Finder goal may take considerable time, the Backward Chaining Procedure is normally applied for database systems which are not critical to responce time. Deductive systems which are supposed to control processes in real time (say, an oil refinery process), normally supports Forward Chaining Procedure to minimize a responce time. file:///e /LV_CD/wbtmaster/main_library/swp4.htm (29 of 32) [10/16/2002 4:15:41 PM]

30 5.3 Discussion We can view the task of executing a logic program as a search problem. The representation of goals in terms of a tree, and the algorithm itself support this analogy. Hence, the objective of the algorithm is to find a solution if one exists in the search space. The depth-first nature and the backtracking of the algorithm introduced, are simply computational features to deal with the non-determinism of the task at hand. In theory, any other (correct) means of dealing with such non-determinism could be used. For instance, the search of the tree could be done breadth- first manner instead. Since predicates can be recursive, breadth-first search would have the advantage of always finding a solution whenever one exists. On the other hand, a depth-first search of the same tree might not terminate, when for instance recursive clauses are attempted first. Since breadth-first search seems to avoid this problem of infinite recursion, one might wonder why it is not used for searching at the first place. file:///e /LV_CD/wbtmaster/main_library/swp4.htm (30 of 32) [10/16/2002 4:15:41 PM]

31 The answer is due to efficiency considerations. Much more information would have to be kept at runtime (in fact all the information of the tree up to that point) with breadth-first search. Depth-first search can be implemented much more efficiently in this respect. But, as is often the case, the gain in efficiency comes at a cost. In this case, the cost is considerable in that it forces programmers to be careful and aware of how programs are executed and arrange their programs accordingly. The order of in which clauses of a predicate appear will matter (depth-first). In particular, the possibility of infinite recursion must be avoided either by placing at least one non-recursive clause before the recursive one(s), or by ensuring that the head of the recursive clause(s) will at some point not unify with a goal. One might think of predicates and facts in several ways. One natural way (perhaps especially so for non-programmers) to look at rules of inference is to think of them as declarative sentences in natural language. As stated earlier, predicates describe relationships between entities (e.g., grandparenthood, parenthood, etc.). Some relationships can be stated in one sentence, other relationships require more than one sentence (rule of inference) in order to specify the relationship fully. Programmers might find similarities between a predicate and a procedure. In that sense, a predicate specifies how to "compute" something (e.g., finding a ascendant to an individual). In this context, rules would correspond to a procedure call and file:///e /LV_CD/wbtmaster/main_library/swp4.htm (31 of 32) [10/16/2002 4:15:41 PM]

32 general directives would correspond to calls involving built-in procedures (this last analogy is weaker than the others). To regard predicates and queries in this way is certainly accurate, however, it constitutes a restricted view. file:///e /LV_CD/wbtmaster/main_library/swp4.htm (32 of 32) [10/16/2002 4:15:42 PM]