File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/91/p91-1040_metho.xml
Size: 30,028 bytes
Last Modified: 2025-10-06 14:12:47
<?xml version="1.0" standalone="yes"?> <Paper uid="P91-1040"> <Title>CONSTRAINT PROJECTION: AN EFFICIENT TREATMENT OF DISJUNCTIVE FEATURE DESCRIPTIONS</Title> <Section position="3" start_page="0" end_page="307" type="metho"> <SectionTitle> 1 Introduction </SectionTitle> <Paragraph position="0"> Unification is a central operation in recent computational linguistic research. Much work on syntactic theory and natural language parsing is based on unification because unification-based approaches have many advantages over other syntactic and computational theories. Unification-based formalisms make it easy to write a grammar. In particular, they allow rules and lexicon to be written declaratively and do not need transformations. null Some problems remain, however. One of the main problems is the computational inefficiency of the unification of disjunctive feature structures. Functional unification grammar (FUG) (Kay 1985) uses disjunctive feature structures for economical representation of lexical items. Using disjunctive feature structures reduces the number of lexical items. However, if disjunctive feature structures were expanded to disjunctive normal form (DNF) 1 as in definite clause grammar (Pereira and Warren 1980) and Kay's parser (Kay 1985), unification would take exponential time in the number of disjuncts. Avoiding unnecessary expansion of disjunction is important for efficient disjunctive unification. Kasper (1987) and Eisele and DSrre (1988) have tackled this problem and proposed unification methods for disjunctive feature descriptions.</Paragraph> <Paragraph position="1"> ~DNF has a form C/bt Vq~ VC/3 V.-. Vq~n, where C/i includes no disjunctions.</Paragraph> <Paragraph position="2"> These works are based on graph unification rather than on term unification. Graph unification has the advantage that the number of arguments is free and arguments are selected by labels so that it is easy to write a grammar and lexicon. Graph unification, however, has two disadvantages: it takes excessive time to search for a specified feature and it requires much copying.</Paragraph> <Paragraph position="3"> We adopt term unification for these reasons.</Paragraph> <Paragraph position="4"> Although Eisele and DSrre (1988) have mentioned that their algorithm is applicable to term unification as well as graph unification, this method would lose term unification's advantage of not requiring so much copying. On the contrary, constraint unification (CU) (Hasida 1986, Tuda et al. 1989), a disjunctive unification method, makes full use of term unification advantages. In CU, disjunctive feature structures are represented by logical constraints, particularly by Horn clauses, and unification is regarded as a constraint satisfaction problem. Furthermore, solving a constraint satisfaction problem is identical to transforming a constraint into an equivalent and satisfiable constraint. CU unifies feature structures by transforming the constraints on them. The basic idea of CU is to transform constraints in a demand-driven way; that is, to transform only those constraints which may not be satisfiable. This is why CU is efficient and does not require excessive copying.</Paragraph> <Paragraph position="5"> However, CU has a serious disadvantage. It does not have a mechanism for abandoning irrelevant information, so the number of arguments in constraint-terms (atomic formulas) becomes so large that transt'ormation takes much time.</Paragraph> <Paragraph position="6"> Therefore, from the viewpoint of general natural language processing, although CU is suitable for processing logical constraints with small structures, it is not suitable for constraints with large structures.</Paragraph> <Paragraph position="7"> This paper presents constraint projection (CP), another method for disjunctive unification. The basic idea of CP is to abandon information irrelevant to goals. For example, in bottom-up parsing, if grammar consists of local constraints as in contemporary unification-based formalisms, it is possible to abandon information about daughter nodes after the application of rules, because the feature structure of a mother node is determined only by the feature structures of its daughter nodes and phrase structure rules.</Paragraph> <Paragraph position="8"> Since abandoning irrelevant information makes the resulting structure tighter, another application of phrase structure rules to it will be efficient. We use the term projection in the sense that CP returns a projection of the input constraint on the specified variables.</Paragraph> <Paragraph position="9"> We explain how to express disjunctive feature structures by logical constraints in Section 2. Section 3 introduces CU and indicates its disadvantages. Section 4 explains the basic ideas and the algorithm of CP. Section 5 presents some results of implementation and shows that adopting CP makes parsing efficient.</Paragraph> </Section> <Section position="4" start_page="307" end_page="308" type="metho"> <SectionTitle> 2 Expressing Disjunctive Feature </SectionTitle> <Paragraph position="0"/> <Section position="1" start_page="307" end_page="308" type="sub_section"> <SectionTitle> Structures by Logical Constraints </SectionTitle> <Paragraph position="0"> This section explains the representation of disjunctive feature structures by Horn clauses. We use the DEC-10 Prolog notation for writing Horn clauses.</Paragraph> <Paragraph position="1"> First, we can express a feature structure without disjunctions by a logical term. For example, (1) is translated into (2). FPdeg'&quot; \] (1) / agr \[num sin L subj \[agr Inure \[per ~irndg \] \] (2) cat (v, agr (sing, 3rd), cat (_, agr (sing, 3rd), _) ) The arguments of the functor cat correspond to the pos (part of speech), agr (agreement), and snbj (subject) features.</Paragraph> <Paragraph position="2"> Disjunction and sharing are represented by the bodies of Horn clauses. An atomic formula in the body whose predicate has multiple definition clauses represents a disjunction. For example, a disjunctive feature structure (3) in FUG (Kay 1985) notation, is translated into (4). &quot;pos v { \[numsing .\] }...~ plural\] agr \[\] \[per j 1st t/ 12nd j'J (3) subj \[ gr ! \[num L agr per (4) p(cat (v, Agr, cat (_, Agr,_)))</Paragraph> <Paragraph position="4"> Here, the predicate p corresponds to the specification of the feature structure. A term p(X) means that the variable I is a candidate of the disjunctive feature structure specified by the predicate p. The ANY value used in FUG or the value of an unspecified feature can be represented by an anonymous variable '_'.</Paragraph> <Paragraph position="5"> We consider atomic formulas to be constraints on the variables they include. The atomic formula lst_or_2nd(Per) in (4) constrains the variable Per to be either 1st or hd. In a similar way, not_3s (Agr) means that Agr is a term which has the form agr(l~um,Per), and that//am is sing and Per is subject to the constraint lst_or_2nd(Per) or that }lure is plural.</Paragraph> <Paragraph position="6"> We do not use or consider predicates without their definition clauses because they make no sense as constraints. We call an atomic formula whose predicate has definition clauses a constraint-term, and we call a sequence of constraint-terms a constraint. A set of definition clauses like (4) is called a structure of a constraint. Phrase structure rules are also represented by logical constraints. For example, If rules are binary and if L, R, and M stand for the left daughter, the right daughter, and the mother, respectively, they stand in a ternary relation, which we represent as psr(L,R,M). Each definition clause ofpsr corresponds to a phrase structure rule. Clause (5) is an example.</Paragraph> <Paragraph position="8"> Definition clauses ofpsr may have their own bodies. null If a disjunctive feature structure is specified by a constraint-term p(X) and another is specified by q(Y), the unification of X and Y is equivalent to the problem of finding X which satisfies (6). (6) \[p(X),q(X)\] Thus a unification of disjunctive feature structures is equivalent to a constraint satisfaction problem. An application of a phrase structure rule also can be considered to be a constraint satisfaction problem. For instance, if categories of left daughter and right daughter are stipulated by el(L) and c2(R), computing a mother category is equivalent to finding M which satisfies constraint (7).</Paragraph> <Paragraph position="9"> (7) \[cl (L), c2 (R) ,psr (L,R, M)\] A Prolog call like (8) realizes this constraint satisfaction.</Paragraph> <Paragraph position="10"> (8) :-el (L), c2(R) ,psr (L,R,M), assert (c3(M)) ,fail.</Paragraph> <Paragraph position="11"> This method, however, is inefficient. Since Prolog chooses one definition clause when multiple definition clauses are available, it must repeat a procedure many times. This method is equivalent to expanding disjunctions to DNF before unification. null</Paragraph> </Section> </Section> <Section position="5" start_page="308" end_page="309" type="metho"> <SectionTitle> 3 Constraint Unification and Its </SectionTitle> <Paragraph position="0"> This section explains constraint unification ~ (Hasida 1986, Tuda et al. 1989), a method of disjunctive unification, and indicates its disadvantage. null</Paragraph> <Section position="1" start_page="308" end_page="309" type="sub_section"> <SectionTitle> 3.1 Basic Ideas of Constraint Unification </SectionTitle> <Paragraph position="0"> As mentioned in Section 1, we can solve a constraint satisfaction problem by constraint transformation. What we seek is an efficient algorithm of transformation whose resulting structure is guaranteed satisfiability and includes a small number of disjuncts.</Paragraph> <Paragraph position="1"> CU is a constraint transformation system which avoids excessive expansion of disjunctions. The goal of CU is to transform an input constraint to a modular constraint. Modular constraints are defined as follows.</Paragraph> <Paragraph position="2"> (9) (Definition: modular) A constraint is modular, iff 1. every argument of every atomic formula is a variable, 2. no variable occurs in two distinct places, and 3. every predicate is modularly defined. A predicate is modularly defined iff the bodies of its definition clauses are either modular or NIL. For example, (10) is a modular constraint, while (11), (12), and (13) are not modular, when all the predicates are modularly defined.</Paragraph> <Paragraph position="4"> Constraint (10) is satisfiable because the predicates have definition clauses. Omitting the proof, a modular constraint is necessarily satisfiable.</Paragraph> <Paragraph position="5"> Transforming a constraint into a modular one is equivalent to finding the set of instances which satisfy the constraint. On the contrary, nonmodular constraint may not be satisfiable. When ~Constralnt unification is called conditioned unification in earlier papers.</Paragraph> <Paragraph position="6"> a constraint is not modular, it is said to have dependencies. For example, (12) has a dependency concerning Y=.</Paragraph> <Paragraph position="7"> The main ideas of CU are (a) it classifies constraint-terms in the input constraint into groups so that they do not share a variable and it transforms them into modular constraints separately, and (b) it does not transform modular constraints. Briefly, CU processes only constraints which have dependencies. This corresponds to avoiding unnecessary expansion of disjunctions.</Paragraph> <Paragraph position="8"> In CU, the order of processes is decided according to dependencies. This flexibility enables CU to reduce the amount of processing.</Paragraph> <Paragraph position="9"> We explain these ideas and the algorithm of CU briefly through an example. CU consists of two functions, namely, modularize(constraint) and integrate(constraint). We can execute CU by calling modularize. Function modularize divides the input constraint into several constraints, and returns a list of their integrations. If one of the integrations fails, modularization also fails.</Paragraph> <Paragraph position="10"> The function integrate creates a new constraint-term equivalent to the input constraint, finds its modular definition clauses, and returns the new constraint-term. Functions rnodularize and integrate call each other.</Paragraph> <Paragraph position="11"> Let us consider the execution of (14).</Paragraph> <Paragraph position="12"> (14) modularize( \[p(X, Y), q(Y. Z), p(A. B) ,r(A) ,r(C)\]) The predicates are defined as follows.</Paragraph> <Paragraph position="13"> (15) pCfCA),C):-rCA),rCC).</Paragraph> <Paragraph position="14"> (16) p(a.b).</Paragraph> <Paragraph position="15"> (17) q(a,b).</Paragraph> <Paragraph position="16"> (18) q(b,a).</Paragraph> <Paragraph position="17"> (19) rCa).</Paragraph> <Paragraph position="18"> (20) r(b).</Paragraph> <Paragraph position="19"> The input constraint is divided into (21), (22), and (23), which are processed independently (idea (a)).</Paragraph> <Paragraph position="20"> (21) \[p(x,Y),q(Y,z)\] (22) \[p(A,B) ,r(A)\] (23) \[r(C)\] If the input constraint were not divided and (21) had multiple solutions, the processing of (22) would be repeated many times. This is one reason for the efficiency of CU. Constraint (23) is not transformed because it is already modular (idea (b)). Prolog would exploit the definition clauses of r and expend unnecessary computation time. This is another reason for CU's efficiency. To transform (21) and (22) into modular constraint-terms, (24) and (25) are called. Since (24~ and (25) succeed and return e0(X,Y,Z)&quot; and el(A,B), respectively, (14) returns (26).</Paragraph> <Paragraph position="21"> (26) \[c0(X,Y,Z), el (A,B) ,r(C)\] This modularization would fail if either (24) or (25) failed.</Paragraph> <Paragraph position="22"> Next, we explain integrate through the execution of (24). First, a new predicate c0 is made so that we can suppose (27).</Paragraph> <Paragraph position="23"> (27) cO (X,Y, Z) 4=:#p(X,Y), q(Y,Z) Formula (27) means that (24) returns c0(X,Y,Z) if the constraint \[p(X,Y) ,q(Y,Z)\] is satisfiable; that is, e0(X,Y=,Z) can be modularly defined so that c0(X,Y,Z) and p(X,Y),q(Y,Z) constrain X, Y, and Z in the same way. Next, a target constraint-term is chosen. Although some heuristics may be applicable to this choice, we simply choose the first element p(X,Y) here. Then, the definition clauses of p are consulted. Note that this corresponds to the expansion of a disjunction. null First, (15) is exploited. The head of (15) is unified with p(X,Y) in (27) so that (27) becomes (28).</Paragraph> <Paragraph position="24"> (28) c0(~ CA) ,C,Z)C=~r(A) ,r(C) ,q(C,Z) The term p(f(A),C) has been replaced by its body r(A),r(C) in the right-hand side of (28). Formula (28) means that cO(f (A) ,C,Z) is true if the variables satisfy the right-hand side of (28). Since the right-hand side of (28) is not modu- null lar, (29) is called and it must return a constraint like (30).</Paragraph> <Paragraph position="25"> (29) modularize(Er(A) ,rCC), qCC, Z)'l) (30) It(A) ,c2(C,Z)\] Then, (31) is created as a definition clause of cO. (31) cOCf(l) ,C,Z):-rCA) ,c2(C,Z).</Paragraph> <Paragraph position="26"> Second, (16) is exploited. Then, (28) becomes (32), (33) is called and returns (34), and (35) is created.</Paragraph> <Paragraph position="27"> (32) c0(a,b,Z) C/==~q(b,Z) (33) modularize( \[q(b,Z) \] ) (34) \[c3(Z)\] (35) cO(a,b,Z):-c3(Z).</Paragraph> <Paragraph position="28"> As a result, (24) returns c0(X,Y,Z) because its definition clauses are made.</Paragraph> <Paragraph position="29"> All the Horn clauses made in this CU invoked</Paragraph> <Paragraph position="31"> aWe use cn (n = 0, 1, 2,.- -) for the names of newlymade predicates.</Paragraph> <Paragraph position="32"> c2(b,a).</Paragraph> <Paragraph position="33"> c3(a).</Paragraph> <Paragraph position="34"> cl(a,b).</Paragraph> <Paragraph position="35"> When a new clause is created, if the predicate of a term in its body has only one definition clause, the term is unified with the head of the definition clause and is replaced by the body. This operation is called reduction. For example, the second clause of (36) is reduced to (37) because c3 has only one definition clause.</Paragraph> <Paragraph position="36"> (37) c0(a,b,a).</Paragraph> <Paragraph position="37"> CU has another operation called folding. It avoids repeating the same type of integrations so that it makes the transformation efficient. Folding also enables CU to handle some of the recursively-defined predicates such as member and append.</Paragraph> </Section> <Section position="2" start_page="309" end_page="309" type="sub_section"> <SectionTitle> 3.2 Parsing with Constraint Unification </SectionTitle> <Paragraph position="0"> We adopt the CYK algorithm (Aho and Ullman 1972) for simplicity, although any algorithms may be adopted. Suppose the constraint-term caZ_n_m(X) means X is the category of a phrase from the (n + 1)th word to the ruth word in an input sentence. Then, application of a phrase structure rule is reduced to creating Horn clauses like (38).</Paragraph> <Paragraph position="1"> psr(L,R,M)\]).</Paragraph> <Paragraph position="2"> (2<re<l, 0<n<m - 2, n + l<_k<m - 1, where I is the sentence length.) The body of the created clause is the constraint returned by the modularization in the right-hand side. If the modularization fails, the clause is not created.</Paragraph> </Section> <Section position="3" start_page="309" end_page="309" type="sub_section"> <SectionTitle> 3.3 Problem of Constraint Unification </SectionTitle> <Paragraph position="0"> The main problem of a CU-based parser is that the number of constraint-term arguments increases as parsing proceeds. For example, It returns a constraint like cl(L,R,M,R1,M1). Thus the number of the constraint-term arguments increases.</Paragraph> <Paragraph position="1"> This causes computation time explosion for two reasons: (a) the augmentation of arguments increases the computation time for making new terms and environments, dividing into groups, unification, and so on, and (b) resulting structures may include excessive disjunctions because of the ambiguity of features irrelevant to the mother categories.</Paragraph> </Section> </Section> <Section position="6" start_page="309" end_page="312" type="metho"> <SectionTitle> 4 Constraint Projection </SectionTitle> <Paragraph position="0"> This section describes constraint projection (CP), which is a generalization of CU and overcomes the disadvantage explained in the previous section.</Paragraph> <Section position="1" start_page="309" end_page="311" type="sub_section"> <SectionTitle> 4.1 Basic Ideas of Constraint Projection </SectionTitle> <Paragraph position="0"> Inefficiency of parsing based on CU is caused by keeping information about daughter nodes. Such information can be abandoned if it is assumed that we want only information about mother nodes. That is, transformation (43) is more useful in parsing than (44).</Paragraph> <Paragraph position="2"> Constraint \[c3(M)\] in (43) must be satisfiable and equivalent to the left-hand side concerning H.</Paragraph> <Paragraph position="3"> Since \[c3(M)\] includes only information about H, it must be a normal constraint, which is defined in (45).</Paragraph> <Paragraph position="4"> (45) (Definition: Normal) A constraint is normal iff (a) it is modular, and (b) each definition clause is a normal defini- null tion clause; that is, its body does not include variables which do not appear in the head. For example, (46) is a normal definition clause while (47) is not.</Paragraph> <Paragraph position="5"> (46) p(a,X) :-r(X).</Paragraph> <Paragraph position="6"> (47) q(X) :-s(X,Y=).</Paragraph> <Paragraph position="7"> The operation (43) is generalized into a new operation constraint projection which is defined in (48).</Paragraph> <Paragraph position="8"> (48) Given a constraint C and a list of variables which we call goal, CP returns a normal constraint which is equivalent to C concerning the variables in the goal, and includes only variables in the goal.</Paragraph> <Paragraph position="9"> * Symbols used: - X, Y .... ; lists of variables.</Paragraph> <Paragraph position="10"> - P, Q .... ; constraint-terms or sometimes &quot;fail&quot;.</Paragraph> <Paragraph position="11"> - P, Q .... ; constraints or sometimes &quot;fail&quot;. - H, ~ .... ; lists of constraints.</Paragraph> <Paragraph position="12"> * project(P, X) returns a normal constraint (list of atomic formulas) on X.</Paragraph> <Paragraph position="13"> 1. If P = NIL then return NIL.</Paragraph> <Paragraph position="14"> 2. IfX=NIL, If not(satisfiable(P)), then return &quot;fail&quot;, Else return NIL.</Paragraph> <Paragraph position="15"> 3. II := divide(P).</Paragraph> <Paragraph position="16"> 4. Hin := the list of the members of H which include variables in X.</Paragraph> <Paragraph position="17"> 5. \]-\[ex :--- the list of the members of H other than the members of ~in.</Paragraph> <Paragraph position="18"> 6. For each member R of \]\]cx, If not(satisfiable(R)) then return &quot;fail&quot; 7. S := NIL.</Paragraph> <Paragraph position="19"> 8. For each member T of Hi,=: -V := intersection(X, variables appearing in T).</Paragraph> <Paragraph position="20"> - R := normalize(T, V). If R = 'faT', then return &quot;fail&quot;, Else add R to S.</Paragraph> <Paragraph position="21"> 9. Return S.</Paragraph> <Paragraph position="22"> * normalize(S, V) returns a normal constraint-term (atomic formula) on V. 1. If S does not include variables appearing in V, and S consists of a modular term, then Return S.</Paragraph> <Paragraph position="23"> 2. S := a member of S that includes a variable in V.</Paragraph> <Paragraph position="24"> 3. S' := the rest of S.</Paragraph> <Paragraph position="25"> 4. C := a term c.(v\], v2 ..... vn). where v\], .... vn are all the members of V and c. is a new functor.</Paragraph> <Paragraph position="26"> 5. success-flag := NIL.</Paragraph> <Paragraph position="27"> 6. For each definition clause H :- B. of the predicate of S: - 0 := mgu(S, H).</Paragraph> <Paragraph position="28"> If 0 = fail, go to the next definition clause.</Paragraph> <Paragraph position="29"> - X := a list of variables in C8.</Paragraph> <Paragraph position="30"> - Q := pro~ect(append(BO, S'0), X ). If. Q = fall, then go to the next definitton clause Else add C0:-Q. to the database with reduction. 7. If success-flag = NIL, then return &quot;fail&quot;, else return C.</Paragraph> <Paragraph position="31"> * mgu returns the most general unifier (Lloyd 1984) * divide(P) divides P into a number of constraints which share no variables and returns the list of the constraints.</Paragraph> <Paragraph position="32"> * satisfiable(P) returns T if P is satisfiable, and NIL otherwise. (satisfiable is a slight modifica null CP also divides input constraint C into several constraints according to dependencies, and transforms them separately. The divided constraints are classified into two groups: constraints which include variables in the goal, and the others. We call the former goal-relevant constraints and the latter goal-irrelevant constraints. Only goal-relevant constraints are transformed into normal constraints. As for goal-irrelevant constraints, only their satisfiability is examined, because they are no longer used and examining satisfiability is easier than transforming. This is a reason for the efficiency of CP.</Paragraph> </Section> <Section position="2" start_page="311" end_page="312" type="sub_section"> <SectionTitle> 4.2 Algorithm of Constraint Projection </SectionTitle> <Paragraph position="0"> CP consists of two functions, project(constraint, goal(variable list)) and normalize(constraint, goal(variable list)), which respectively correspond to modularize and integrate in CU. We can execute CP by calling project. The algorithm of constraint projection is shown in Figure 14.</Paragraph> <Paragraph position="1"> We explain the algorithm of CP through the execution of (49).</Paragraph> <Paragraph position="2"> (49) project( \[p(X,Y) ,q(Y ,Z) ,p(A,B) ,r(A) ,r (C)\], Ix,c\]) The predicates are defined in the same way as (15) to (20). This execution is illustrated in Figure 2. First, the input constraint is divided into (50), (51) is goal-irrelevant, only its satisfiability is examined and confirmed. If some goal-irrelevant constraints were proved not satisfiable, the projection would fail. Constraint (52) is already normal, so it is not processed. Then (53) is called to transform (50).</Paragraph> <Paragraph position="3"> (53) normalize ( \[p(X, Y), q(Y=, Z) \], \[X\]) The second argument (goal) is the list of variables that appear in both (50) and the goal of (49). Since this normalization must return a constraint like \[c0(X)\], (49) returns (54).</Paragraph> <Paragraph position="4"> (54) \[c0(X) ,r(C)\] This includes only variables in the goal. This constraint has a tighter structure than (26). Next, we explain the function normalize through the execution of (53). This execution is illustrated in Figure 3. First, a new term c0(X) is made so that we can suppose (55). Its arguments are all the variables in the goal.</Paragraph> <Paragraph position="5"> (55) c0 (x)c=~p(x,Y) ,q(Y,Z) The normal definition of cO should be found.</Paragraph> <Paragraph position="6"> Since a target constraint must include a variable in the goal, p(X,Y) is chosen. The definition clauses of p are (15) and (16).</Paragraph> <Paragraph position="7"> (15) pCfCA) ,C) :-rCA),r(C).</Paragraph> <Paragraph position="8"> (16) p(a,b).</Paragraph> <Paragraph position="9"> The clause (15) is exploited at first. Its head is unified with p(X,Y) in (55) so that (55) becomes (56). (If this unification failed, the next definition clause would be exploited.) (56) c0 (f CA)) C/=:C/,r (A) ,r (C), q(C, Z) Tlm right-hand side includes some variables which do not appear in the left-hand side. Therefore, (57) is called.</Paragraph> <Paragraph position="10"> (57) project(\[r(h),r(C),q(C,Z)\], \[AJ) This returns r(A), and (58) is created.</Paragraph> <Paragraph position="11"> (58) c0(f(a)):-r(A).</Paragraph> <Paragraph position="12"> Second, (16) is exploited and (59) is created in the same way.</Paragraph> <Paragraph position="13"> (59) c0(a).</Paragraph> <Paragraph position="14"> Consequently, (53) returns c0(X) because some definition clauses of cO have been created. All the Horn clauses created in this CP are shown in (60).</Paragraph> <Paragraph position="15"> (60) c0(f(A)) :-r(A).</Paragraph> <Paragraph position="16"> cO(a).</Paragraph> <Paragraph position="17"> Comparing (60) with (36), we see that CP not only is efficient but also needs less memory space than CU.</Paragraph> </Section> <Section position="3" start_page="312" end_page="312" type="sub_section"> <SectionTitle> 4.3 Parsing with Constraint Projection </SectionTitle> <Paragraph position="0"> We can construct a CYK parser by using CP as in (61).</Paragraph> <Paragraph position="1"> (61) cat_n_m(M) &quot;project( \[cat_ n_k (L), cat_k_m(R), psr(L,R,M)\], \[.\] ).</Paragraph> <Paragraph position="2"> (2<m<l, 0<n<m - 2, n + l<k<m - 1, where l is the sentence length.) For a simple example, let us consider parsing the sentence &quot;Japanese work.&quot; by the following projection.</Paragraph> <Paragraph position="3"> The new term c0(M) is made, and (63) is exploited. Then (71) is to be created if its right-hand side succeeds.</Paragraph> <Paragraph position="5"> This projection calls (72).</Paragraph> <Paragraph position="6"> (72) normalize(\[cat_of_j apanese (n (gum, Per)), cat_of_work (v ( \]lum, Per, Tens e) ) \], \[Tense\]).</Paragraph> <Paragraph position="7"> New term cl(Tense) is made and (65) is exploited. Then (73) is to be created if the right-hand side succeeds.</Paragraph> <Paragraph position="9"> Since the first of argument of the projection is satisfiable, it returns NIL. Therefore, (74) is created, and (75) is created since the right-hand side of (71) returns cl(Tense).</Paragraph> <Paragraph position="10"> (74) cl (present).</Paragraph> <Paragraph position="11"> (75) c0(s (Tense)) : -cl (Tense).</Paragraph> <Paragraph position="12"> When asserted, (75) is reduced to (76).</Paragraph> <Paragraph position="13"> (76) c0(s(present)).</Paragraph> <Paragraph position="14"> Consequently, \[c0(M)\] is returned.</Paragraph> <Paragraph position="15"> Thus CP can he applied to CYK parsing, but needless to say, CP can be applied to parsing algorithms other than CYK, such as active chart parsing.</Paragraph> </Section> </Section> <Section position="7" start_page="312" end_page="313" type="metho"> <SectionTitle> 5 Implementation </SectionTitle> <Paragraph position="0"> Both CU and CP have been implemented in Sun Common Lisp 3.0 on a Sun 4 spare station 1.</Paragraph> <Paragraph position="1"> They are based on a small Prolog interpreter written in Lisp so that they use the same non-disjunctive unification mechanism. We also implemented three CYK parsers that adopt Prolog, CU, and CP as the disjunctive unification mechanism. Grammar and lexicon are based on ttPSG (Pollard and Sag 1987). Each lexical item has about three disjuncts on average.</Paragraph> <Paragraph position="2"> Table I shows comparison of the computation time of the three parsers. It indicates CU is not as efficient as CP when the input sentences are long.</Paragraph> <Paragraph position="3"> Input sentence He wanted to be a doctor.</Paragraph> <Paragraph position="4"> You were a doctor when you were young.</Paragraph> <Paragraph position="5"> I saw a man with a telescope on the hill.</Paragraph> <Paragraph position="6"> He wanted to be a doctor when he was a student.</Paragraph> </Section> class="xml-element"></Paper>