Horn Clause Programs have a natural exhaustive depth-first procedural semantics. However, for many programs this semantics is ineffective. In order to compute useful solutions, one needs the ability to modify the search method that explores the alternative execution branches.
Tor, a well-defined hook into Prolog disjunction, provides this ability. It is light-weight thanks to its library approach. Tor supports modular composition of search methods and other hooks. The Tor library is already provided and used as an add-on to SWI-Prolog

Desouter, Benoit

Schrijvers, Tom

English

Ghent University Academic Bibliography

Tor: Modular Search with Hookable DisjunctionBenoit Desouter∗and Tom Schrijvers†Ghent University, BelgiumMarch 8, 2013AbstractHorn Clause Programs have a natural exhaustive depth-first procedu-ral semantics. However, for many programs this semantics is ineffective.In order to compute useful solutions, one needs the ability to modify thesearch method that explores the alternative execution branches.Tor, a well-defined hook into Prolog disjunction, provides this ability.It is light-weight thanks to its library approach. Tor supports modu-lar composition of search methods and other hooks. The Tor library isalready provided and used as an add-on to SWI-Prolog.1 IntroductionKowalski’s well-known adage [1] crisply captures the essence of programming inthe equation:Algorithm = Logic + ControlUnfortunately, it is not all that easy to cleanly separate logic and control whenimplementing search heuristics in Prolog. When one discovers that Prolog’scontrol is ineffective, it is often impossible to orthogonally add one’s own controlwithout touching the existing logic. Syntactically, logic and control in Prologare tightly coupled, and adding a different control means cross-cutting existingcode.Our novel approach to adding, in an orthogonal manner, control, featuresthe following properties:• It is a light-weight and efficient library-based approach that is easilyportable; it is currently an SWI-Prolog library [2] available at http://www.swi-prolog.org/pack/list?p=tor.• Our approach has all the benefits of modularity: search methods can becomposed and the library of these heuristics is (user-)extensible.With Tor, we capture all common search methods in CLP(FD) libraries. Thisapproach is indeed particularly suitable for Constraint Logic Programming, butalso useful for general Prolog programs with a large search space.For a more thorough discussion of Tor, we refer the interested reader to [3].An earlier version is discussed in [4].∗Benoit.Desouter@UGent.be†Tom.Schrijvers@UGent.be1label([]).label([Var|Vars]) :-( var(Var) ->fd_inf(Var,Value),( Var #= Value,label(Vars);Var #\= Value,label([Var|Vars]));label(Vars)).label([] ,_ ).label([Var|Vars] ,D ) :-( var(Var) ->D > 0,ND is D - 1,fd_inf(Var,Value),( Var #= Value,label(Vars ,ND );Var #\= Value,label([Var|Vars] ,ND ));label(Vars ,D )).Figure 1: Labeling predicate: plain (left) and with depth bound (right).2 Problem StatementWe illustrate the heart of the matter on a simple labeling predicate label/1written against SWI-Prolog’s clpfd library [5] (see Fig. 1, left). label/1 definesa search tree where the branches are created by the disjunction.1Suppose that for a certain call label([X1,...,Xn]) the search tree is toolarge to fully explore. In order to get some useful answers, certain parts of thetree can be left unexplored. This can for example be achieved by imposing adepth bound on Prolog’s depth first search (Figure 1 right).Imposing a depth bound may or may not be a successful approach to gettinguseful answers. In case it is not, other pruning strategies can be tried, likeimposing a node bound or a discrepancy bound. Each of these requires rewritingthe label/1 predicate to incorporate a different pruning technique.The problems with the above approach should be apparent:• It follows the well-known copy-paste-modify anti-pattern.• The same heuristic is implemented over and over in different settings. Thisprocess is error-prone, wastes precious programmer time and is bound toyield non-optimal code quality.• The effort and expertise required to combine working labeling code withvarious search heuristics is non-trivial. This means that fewer combina-tions are explored, leading to suboptimal solutions.• As soon as the labeling code spans several different predicates or mul-tiple invocations of the same predicate, the complexity of adding searchheuristics increases drastically.1fd inf/2 returns the smallest value in a variable’s finite domain.23 Solution Overview3.1 User PerspectiveTor divides search code into two parts: a) the code that defines the searchtree, and b) the code that defines the search method. The user defines theseseparately (or reuses library definitions) and combines them into a search goal.This decoupling means that new search methods and new search tree code canbe written without awareness of one another and without the modification ofany existing code.Search Tree Code The search tree code sets up the problem specific searchtree. To fit in the Tor framework, the code must use Tor’s custom disjunc-tion tor/2 rather than ;/2. For instance, tor label/1 is the Tor-compatiblevariant of label/1:tor_label([]).tor_label([Var|Vars]) :-( var(Var) ->fd_inf(Var,Value),( Var #= Value,tor_label(Vars)torVar #\= Value,tor_label([Var|Vars]));tor_label(Vars)).Search Methods A search method is defined as a predicate that capturesthe essence of that method in a declarative way, as a bare-bones search treewithout any useful work (such as labeling variabels). For instance, dbs tree/1captures the depth-bounded search method.dbs_tree(Depth) :-Depth > 0,Depth1 is Depth - 1,( dbs_tree(Depth1)tordbs_tree(Depth1)).Search methods change less frequently. They are usually written by advancedusers and library writers. For instance, Tor itself comes with a library ofpredefined search methods.Combining Search Tree and Search Method The user imposes a searchmethod on a search tree by calling the Tor predicate tor merge(MGoal,TGoal),where MGoal is a call to the search method predicate and TGoal is a call to the3search tree predicate. Conceptually, tor merge/2 overlays or merges the searchtrees of the two goals, synchronizing their tor/2 disjunctions.To facilitate reuse, we generally recommend to encapsulate the application oftor merge/2 to a particular search method in a separate predicate, like dbs/2for dbs tree/1.dbs(Depth,Goal) :-tor_merge(dbs_tree(Depth),Goal).Wrapping Up In the final step, the Tor predicate search(Goal) is used to,conceptually, replace all the occurrences (merged or not) of tor/2 by properProlog disjunctions.In summary, the behavior of label/2 of Fig. 1 is recovered as follows:search(dbs(Depth,tor label(Vars)))≡label(Vars,Depth)3.2 Modularity AspectsModular Composition of Search Tree Code and Search Method Eventhough their implementations are decoupled, any search tree and any searchmethod code can be combined out of the box with the help of Tor’s search/1predicate. For instance, a user can define a complex labeling goal as the con-junction of two invocations of tor label/1. It is easy to express a differentscenario, either by varying the search tree or the search method code. By lds,we denote the limited discrepancy search method; nbs stands for node-boundedsearch:?- search(lds((tor_label([X1,...,Xn]), tor_label([Y1,...,Ym])))).?- search(nbs(30000,(tor_member([X1,...,Xn]), tor_member([Y1,...,Ym])))).It becomes even more interesting if you label both lists with different variableand value selection strategies.Modular Composition of Multiple Search Heuristics A further modu-larity advantage of Tor is that it provides nested invocation as an out of thebox way to compose two (or more) search methods. Nesting denotes that bothsearch methods are simultaneously active.For instance, we can simultaneously apply a depth-limit and perform a lim-ited discrepancy search:?- search(dbs(10,lds(tor_label([X1,...,Xn])))).Contrast this with the non-modular approach were the user would have to writea combined search heuristic dbs lds/2 from scratch.Finally, the compositional nature of the notation can be exploited to itsfullest potential to obtain sofisticated search specifications. For instance, thegoal?- ..., search(lds((dbs(XsLimit,tor_label(Xs)),dbs(YsLimit,tor_label(Ys))))).4applies limited discrepancy search to the whole search tree, and additionallyimposes one depth-limit on the search of the Xs and another to that of the Ys.Such a composite heuristic is not readily expressible with any of the existingCLP libraries.4 Heuristics LibraryFollowing the above approach, it is easy to write various modular search methodsyourself. However, Tor already provides a substantial library of which we wecover only two here. Many others can be found in [3].4.1 Node-Bounded SearchA node-bounded search is much like a depth-bounded search, except that thedecrements of the limit are not backtracked. Hence, as an optimization we abortthe whole search at once by throwing an exception.nbs(Nodes,Goal) :-new_nbvar(Nodes,NodesVar),catch(tor_merge(nbs_tree(NodesVar),Goal),out_of_nodes(NodesVar),fail).nbs_tree(Var) :-nb_get(Var,N),( N > 0 ->N1 is N - 1,nb_put(Var, N1),( nbs_tree(Var)tornbs_tree(Var));throw(out_of_nodes(Var))).4.2 Branch-and-Bound OptimizationThis well-known optimization approach posts constraints in the intermediatenodes of the search tree to find increasingly better solutions. Our implemen-tation uses Tor to access those intermediate nodes and generate increasinglylarger values of the Objective variable. It uses two variables, BestVar andCurrent. The former keeps track of the overall best solution so far, while thelatter is the solution that the current node tries to improve upon.Both the overall and current best solution are initialized to a value smallerthan the infimum of the objective variable’s domain. Whenever a solution isfound, the overall best solution is updated. Whenever we backtrack into aTor choicepoint, the heuristic synchronizes the current best solution with the5overall best solution. If the current best solution was out of sync, the handleralso imposes a new lower bound on the objective variable. Note that inf denotesnegative infinity.bab(Objective,Goal) :-fd_inf(Objective,Inf),LowerBound is Inf - 1,new_nbvar(LowerBound,BestVar),Current = LowerBound,tor_merge(bab_tree(Objective,BestVar,Current),Goal),nb_put(BestVar,Objective).bab_tree(Objective,BestVar,Current) :-nb_get(BestVar,Best),( Best \= inf , (Current == inf ; Best > Current ) ->Objective #> Best,NCurrent = Best;NCurrent = Current),( bab_tree(Objective,BestVar,NCurrent)torbab_tree(Objective,BestVar,NCurrent)).5 Search Tree ObservationTor enables various ways to observe the search tree, so that one can gaininsight in the search process itself, e.g., for (performance) debugging purposes.We provide different components that monitor various metrics of the search tree.We can also visualize the actual search tree. For that purpose, we providea predicate log/1 that emits a textual representation of the search tree. Acomplimentary tool that turns this log into a PDF image is also available in theTor release.6 ConclusionWe have presented Tor, a light-weight library-based approach for modifyingProlog’s depth-first search with reusable and compositional search methods.The notion of hookable disjunction enables a surprisingly large number of pos-sibilities for modifying Prolog search.References[1] R. Kowalski, Logic for Problem Solving. North-Holland, 1979.[2] J. Wielemaker, T. Schrijvers, M. Triska, and T. Lager, “SWI-Prolog,” The-ory and Practice of Logic Programming, vol. 12, no. 1-2, pp. 67–96, 2012.6[3] T. Schrijvers, B. Demoen, M. Triska, and B. Desouter, “Tor: Modular searchwith hookable disjunction.” To appear in Science of Computer Programming,2013.[4] T. Schrijvers, M. Triska, and B. Demoen, “Tor: extensible search with hook-able disjunction,” in Proceedings of the 14th symposium on Principles andpractice of declarative programming, PPDP ’12, (New York, NY, USA),pp. 103–114, ACM, 2012.[5] M. Triska, “The finite domain constraint solver of SWI-Prolog,” in Pro-ceedings of the 11th International Symposium on Functional and Logic Pro-gramming (FLOPS 2012), vol. 7294 of Lecture Notes in Computer Science,pp. 307–316, Springer, 2012.7

Tor: modular search with hookable disjunction

https://biblio.ugent.be/publication/4091822/file/4091964.pdf

Tor: modular search with hookable disjunction

Abstract

Similar works

Full text

Available Versions

Ghent University Academic Bibliography