Control Network Programming with SPIDER: Dynamic Search Control

Control Network Programming with SPIDER: Dynamic Search Control Kostadin Kratchanov1, Tzanko Golemanov2, Emilia Golemanova2, and Tuncay Ercan1 1

Department of Software Engineering, Yasar University, Universite Cad. Yagacli Yol No.35-37, Bornova/Izmir, 35100 Turkey {kostadin.kratchanov,tuncay.ercan}@yasar.edu.tr 2 Department of Computing, Rousse University, 8 Studentska Street, Rousse, Bulgaria {EGolemanova,TGolemanov}@ecs.ru.acad.bg

Abstract. The report describes the means for dynamic control of the computation process that are available in Spider – a language for Control Network Programming. Keywords: Control network programming, programming paradigms, programming languages, non-procedural programming, search control, computation control, dynamic control, heuristic algorithms.

1 Introduction This report builds on publications [1-4] and, together with [5], completes this series of six papers describing the fundamentals of the programming paradigm referred to as Control Network Programming or CNP: the rationale behind its development, the structure of a program, a program’s interpretation, problem types particularly well suited for CNP, solutions to representative problems. More specifically, the exposition and descriptions focus on the SPIDER programming language for CNP which is the core of the SPIDER programming environment for CNP1. 1.1 A Program in CNP Is a Network – The CN Control Network Programming means programming through “control networks”. It is a programming paradigm in which the program can be visualized as a finite set of graphs. This set of graphs is called a control network (CN). The graphs comprising the CN are referred to as subnets; one of the subnets is identified as the main subnet. Each subnet consists of nodes (states) and arrows. A chain of primitives is assigned to each arrow. The primitives may be thought of as elementary actions and are technically user-defined procedures. A subnet may call other subnets or itself. Both subnets and primitives can have parameters and variables. The complete program consists of two main components - the CN and the definitions of the primitives. 1

A considerably more advanced programming environment called WinSpider is now operational; however, for consistency, all explanations and examples here are based on SPIDER. The SPIDER environment for CNP is available for free download at http://controlnetworkprogramming.com

R. Setchi et al. (Eds.): KES 2010, Part II, LNAI 6277, pp. 253–262, 2010. © Springer-Verlag Berlin Heidelberg 2010

254

K. Kratchanov et al.

An example of the graphical representation of a simple CN is shown in Fig.1. The corresponding textual representation of the same CN in the SPIDER language is also demonstrated. This exemplary CN consists of a single subnet called Astar. It is a working demo of a possible CNP implementation of the A*-algorithm (e.g., [6-9]) for solving the 8-puzzle problem and was originally presented in [10]. Note that the above example is not meant as representative for the type of problems where using CNP is particularly effective but is rather a simple illustration of a CN.

Fig. 1. Graphical and textual representations of the CN of an implementation of the A*algorithm for solving the 8-puzzle problem

The program in CNP integrates conveniently declarative and imperative features where a possibly declarative problem description – the CN – can be considered as “leading”. In general, this description may be nondeterministic [1-3], and the execution (computation, inference, interpretation) of a CN program is essentially search in the CN. Generally, the built-in search strategy (a form of extended backtracking [3,4]) directs automatically the search and, ideally, the programmer should not be concerned with procedural details of the computation. In practice, however, in many cases procedural aspects are significant with ramification for efficiency, termination and choice among alternative solutions. Therefore, similarly to Prolog and other declarative languages, Spider provides means for control of the computation process [11,12].

Control Network Programming with SPIDER: Dynamic Search Control

255

These means are the so called system options for static search control which are discussed in detail in [4]. The system options of this group are summarized in Table 1. Table 1. Static control system options Option SOLUTIONS

Default value 1

Other values

Description

BACKTRACKING ONEVISIT

YES NO

ALL, ASK, unsigned integer NO YES

Specifies max number of solutions to be found Is backtracking allowed Are multiple entries into a node (within a recursive level) allowed Max number of repeated visits to a node in the current path Max number of repeated invocations of a subnet

LOOPS

ANY

unsigned integer

RECURSION

ANY

unsigned integer

1.2 Dynamic Computation Control and the Purpose of This Report In addition to the static search control discussed above, Spider features powerful tools for a second type of computation control which we call dynamic search control. Two groups of tools for dynamic search control are available: system options for dynamic search control and control states. The former are summarized in Table 2. The control states available are SELECT, RANGE and ORDER. Table 2. Dynamic control system options Option ARROWCOST

Default value 1

MAXPATHCOST

ANY

RANGEORDER

NO

ORDEROFARROWS

NO

PROXIMITY

0

NUMBEROFARROWS

ANY

Other values real value (const, var) real value (const, var) LOWFIRST, HIGHFIRST, RANDOM RANDOM

real value (const, var), or NEAREST integer value (const, var)

Description All arrows in scope have the specified cost Arrow fails if current cost exceeds value See description of control state RANGE Is the order of attempting arrows emanating from a given (regular) state random? See description of control state SELECT Max number of attempted outgoing arrows

The fundamental purpose for introducing dynamic search control is the “automatic” (or “nonprocedural”, “declarative”) implementation of heuristic algorithms. Paper [5] is especially devoted to this issue. The aim of the current report is to describe the tools for dynamic search control provided in SPIDER with simple illustrations.

256

K. Kratchanov et al.

The phrases “Static control” and “Dynamic control” are somewhat imprecise and have been chosen mainly for convenience. Other possible distinctive names would have been “Basic control” and “Advanced control”. Static control refers to controlling the basic parameters of the search process while Dynamic control is mainly related to more advanced features leading to implementing heuristic and more efficient algorithms. We may argue that the values of the static options are chosen when writing the CN and cannot be changed at execution time. In contrast, most dynamic options’ values can be set equal to values of given variables, and therefore may be dynamically changed by changing the values of these variables during execution. In principle, it would be easy to allow the values of the options from the “static” group to also equal variables; however, we have not needed such a feature so far. 1.3 A Grain of History Ideas related to controlling the computation/search process and modeling heuristic strategies in CNP have been discussed in the Intelligent Systems group in Rousse University led by K. Kratchanov and I. Stanev, and many colleagues have contributed to the development, implementation and applications of those ideas. Currently, there are two main lines of research. They have common roots but subsequently developed different foci, solutions, implementations and achievements. The first line is presented in this paper; some earlier publications are [10,13,14]. The programming language used in the second approach is called Net. There are considerable differences between SPIDER and Net in concept, syntax and implementation discussed in [10]; most importantly, Net follows the concept of a completely specified language while Spider uses an underlying language [1]. Some publications related to the second line are [15,16].

2 Arrow Costs and System Option ARROWCOST As emphasized repeatedly (e.g., [2,14]), problems that can be naturally visualized as graph-like structures are prime candidates for effective and simple CNP solutions. One particular example is the case when the problem representation is based on the state space approach [7]. Often, the arrows in graph-like problem representations are assigned numeric values called costs. For example, in the map traversal problem [4Fig.7,6,17] or the traveling salesperson problem [7,8,19] the costs are the distances between the cities2; in the sheep and wolves problem [2,9] there might be different costs for carrying one sheep or one wolf in the boat, and so on. Normally, in a CNP solution to a problem with graph-like representation the CN mimics this representation [2]. Therefore, possible advantages may be expected if we can specify costs for the arrows in the CN. In SPIDER arrows can be assigned costs in two ways. Firstly, it can be done directly in the textual representation of the CN using prefixes in brackets. For instance, modifying the example of Fig. 1, we can write 0: 2

(20) Init

>1;

If a state represents a partial tour the cost of an arrow will be the additional distance introduced by traveling to the latest point in the tour.

Control Network Programming with SPIDER: Dynamic Search Control

257

specifying cost 20 for the given arrow. The corresponding segment of the graphical representation of the CN will look as follows: 0

(20) Init

1

Secondly, identical arrow costs can be specified using the system option ARROWCOST for all arrows in the scope [4] of the system option.

Fig. 2. Using arrow costs: Finding all paths with their lengths

Fig. 2 is a modification of the solution to the map traversal problem shown in Fig. 9 of [4]. For convenience, the map is repeated in Fig. 3 below. In the example, all paths between given initial and final cities will be found and printed together with the length in kilometers of each path. Value ARROWCOST=0 must be specified with range the whole CN. In this way all “system” arrows without specified cost will get cost 0 and will not affect the accumulated cost of a solution found. The cost of the

258

K. Kratchanov et al.

current path is automatically calculated by the SPIDER interpreter as value of an accessible system variable (called O.CurrCost) and will be printed by the primitive Print.

Fig. 3. The Map Traversal problem

3 System Option MAXPATHCOST and Branch-and-Bound If the accumulated cost of the current path exceeds the value of the system option MAXPATHCOST the forward execution of the active arrow fails. Note that the value of MAXPATHCOST may equal the value of a variable thus allowing dynamic change of the threshold. Let us consider the exemplary map of Fig.3 and assume that a minimal path from A to D is sought. Our solution is based on the CN of Fig.2, with MAXPATHCOST=Bound added for the whole CN where Bound is a variable whose initial value is the maximal real value. Note that SOLUTIONS=ALL. Primitive Print must also be slightly modified by adding the statement Bound:=O.CurrCost. The first solution path found and printed will be ABD with cost 120. During the execution of primitive Print the value of variable Bound will be changed to 120. Then the interpreter will backtrack from state FINISH of the main subnet, the control will enter backwards subnet MAP throw nodes RETURN and D into node B. From B, the second outgoing arrow to node C will be attempted. The current path cost will become 150. As this value exceeds the current value of MAXPATHCOST which is 120, arrow BÆC will fail and the control will return to node B. This means that the system will not produce the solution path ABCD whose cost is worse than that of the current optimal cost 120 of path ABD. Same applies to solution ACD. It is clear that the last found solution path will be optimal (or shortest if all costs in the map are 1). Thus, our CNP program will always produce an optimal (or shortest) solution. Moreover, in the process of search many “unpromising” paths such as ABC will be pruned. Such paths are called insipid paths in [9]. Our solution is equivalent or very similar to the Branch-and-Bound strategy [7,9,18] and DFS adapted for finding the cheapest solution within a prescribed amount of search effort [9]. Branch-andBound in the literature usually means “best-first branch-and-bound” [19]; our solution is not “best-first” but is completely non-procedural. (Branch-and-Bound in [17] has a different meaning.)

Control Network Programming with SPIDER: Dynamic Search Control

259

A simpler version of our solution where the value of MAXPATHCOST is set to a constant will correspond to what is known as cost-bound (respectively length-bound) depth-first search [9].

4 Order of Attempting the Outgoing Arrows and Control States Normally the arrows emanating from a given node in the CN are attempted in the order they are specified in the CN. The three control states featured in SPIDER (ORDER, RANGE, and SELECT) allow this order to be controlled and changed, even dynamically. In order to achieve this (and consequently certain heuristically informed choice) arrows emanating from a control state can be equipped with ``heuristic`` values – such arrows will be called evaluated arrows. Note that these evaluations are different from the arrow costs discussed earlier. The three control states are introduced below. Their usage is illustrated in [5]. 4.1 Control State ORDER The first type of control state is called control state ORDER (Fig.4). Here, Control is the identifier of the state, sel and S1 are variables. The outgoing arrows are evaluated – the evaluations can be constants or variables, like in the case of S1. A control state ORDER has an associated quantity called a selector; in the example the selector`s value is the value of the variable sel. The interpreter chooses the arrows in the order of how close their evaluations are to the value of the state selector. For instance, if the values of both sel and S1 are 0 then the arrows will be attempted in the order b, c, a; if the values of sel and S1 are 100 and 3.14, respectively, the order of the arrows will be a, b, c.

Fig. 4. Control state ORDER – graphical representation and specification in the CN

4.2 Control State RANGE and System Option RANGEORDER There are two versions of control state RANGE – without or with an ELSE clause. They are shown in Fig.5. There are two selectors – L and H where L≤H, and only the arrows with heuristic values in the range between L and H are considered, the arrows outside the specified range are cut off. When there are no arrows within the range the ELSE arrow is tried if any, otherwise backtracking is performed.

260

K. Kratchanov et al.

Fig. 5. The two versions of control state RANGE – graphical representation and specification in the CN

The arrows falling within the range must be attempted in certain order. This order is determined by the value of the system option RANGEORDER. If the value of RANGEORDER is NO then the arrows are chosen according to their order in the CN, if RANGEORDER=LOWFIRST the arrows with smaller heuristic values are first, and if RANGEORDER=HIGHFIRST the arrows with larger heuristic values are first. Value RANGEORDER=RANDOM implies a random choice among the arrows within the range. 4.3 System Option ORDEROFARROWS While system option RANGEORDER is used with control states of type RANGE, system option ORDEROFARROWS is used with normal states. Its possible values NO and RANDOM have meaning identical of that for the same values of RANGEORDER. 4.4 Control State SELECT and System Option PROXIMITY Control state SELECT is illustrated in the upper part of Fig.6. Analogously to control state RANGE, there is a second version with an ELSE arrow. Here, an outgoing arrow is active (can be selected) only if its evaluation is equal to the value of the state selector. For the example, if Sel=3.14 and S1=3.14, then both arrows b and c will be active. The state selector and arrow evaluations are real number and their comparison is very sensitive. In the example considered, if S1=3.142857 then only arrow c will eventually be active. The system option PROXIMITY defines a tolerance value – the values of the selector and evaluations are considered equal if the absolute value of their difference is not greater than the value of PROXIMITY. For example, in the lower part of Fig.6 if Sel=3.14 and S1=3.142857 then both arrows b and c will be active. The system option PROXIMITY may also have the constant value NEAREST – in that case the outgoing arrow selected will be the one whose evaluation is the nearest to the value of the selector.

Control Network Programming with SPIDER: Dynamic Search Control

261

Fig. 6. Control state SELECT without and with system option PROXIMITY – graphical representation and specification in the CN

5 Conclusion The means for dynamic control of the computation process in Spider have been discussed. These include system options for dynamic control and control states. Most prominent usage of the dynamic search control is for automatic, “non-procedural” implementation of various heuristic algorithms for informed search or improved uninformed search algorithms. Report [5] presented to the same conference is devoted to the usage of dynamic control for non-procedural implementation of heuristic algorithms, as well as related ideas for automation of programming.

References 1. Kratchanov, K., Golemanov, T., Golemanova, E.: Control Network Programming. In: 6th IEEE/ACIS Conf. on Computer and Information Science (ICIS 2007), Melbourne, Australia, pp. 1012–1018. IEEE Computer Society Press, Los Alamitos (2007) 2. Kratchanov, K., Golemanova, E., Golemanov, T.: Control Network Programming Illustrated: Solving Problems With Inherent Graph-Like Structure. In: 7th IEEE/ACIS Conf. on Computer and Information Science (ICIS 2008), Portland, Oregon, USA, pp. 453–459. IEEE Computer Society Press, Los Alamitos (2008) 3. Kratchanov, K., Golemanova, E., Golemanov, T.: Control Network Programs and Their Execution. In: 8th WSEAS Int. Conf. on Artificial Intelligence, Knowledge Engineering and Data Bases (AIKED 2009), Cambridge, UK, pp. 417–422. WSEAS Press (2009) 4. Kratchanov, K., Golemanov, T., Golemanova, E.: Control Network Programs: Static Search Control with System Options. In: 8th WSEAS Int. Conf. on Artificial Intelligence, Knowledge Engineering and Data Bases (AIKED 2009), Cambridge, UK, pp. 423–428. WSEAS Press (2009) 5. Kratchanov, K., Golemanova, E., Golemanov, T., Ercan, T.: Nonprocedural Implementation of Local Heuristic Search in Control Network Programming. In: 14th Int. Conf. on Knowledge-Based and Intelligent Information & Engineering Systems (KES 2010), Cardiff, UK (2010)

262

K. Kratchanov et al.

6. Russell, S., Norvig, P.: Artificial Intelligence: A Modern Approach, 3rd edn. Prentice Hall, Upper Saddle River (2010) 7. Luger, G.F.: Artificial Intelligence: Structures and Strategies for Complex Problem Solving, 6th edn. Addison Wesley, Boston (2009) 8. Jones, M.T.: Artificial Intelligence: A Systems Approach. Infinity Science Press, Higham (2008) 9. Shinghal, R.: Formal Concepts in Artificial Intelligence. Fundamentals. Chapman & Hall, London (1992) 10. Golemanov, T.: An Integrated Environment for Control Network Programming. Research report, Rousse University (1996) 11. Golemanov, T., Kratchanov, K., Golemanova, E.: Spider vs. Prolog: Simulating Prolog in Spider. In: 10th Int. Conf. on Computer Systems and Technologies (CompSysTech 2009), Rousse, Bulgaria, ACM Bulgaria, Sofia. ACM International Conference Proceeding Series, vol. 433,pp. II.9-1-II.9-7. ACM, New York (2009) 12. Golemanova, E., Kratchanov, K., Golemanov, T.: Spider vs. Prolog: Computation Control. In: 10th Int. Conf. on Computer Systems and Technologies (CompSysTech 2009), Rousse, Bulgaria, ACM Bulgaria, Sofia. ACM International Conference Proceeding Series, vol. 433, pp. II.10-1-II.10-6. ACM, New York (2009) 13. Kratchanov, K., Golemanov, T., Golemanova, E., Stanev, I.: Control Network Programming in SPIDER: Built-in Search Control Tools. In: Ciftcibasi, T., Karaman, M., Atalay, V. (eds.) New Trends in Artificial Intelligence & Neural Networks, pp. 105–109. EMO Scientific Books, Ankara (1997) 14. Golemanova, E., Golemanov, T., Kratchanov, K.: Built-in Features of the SPIDER Language for Implementing Heuristic Algorithms. In: Conf. on Computer Systems and Technologies (CompSysTech 2000), Sofia, pp. 2091–2095. ACM Press, New York (2000) 15. Stanev, I.: Formal Programming Language Net. Part I – Conception of the language. In: Conf. on Computer Systems and Technologies (CompSysTech 2001), Sofia (2001) 16. Stanev, I.: Formal Programming Language Net. Part II – Syntax Diagrams. In: Conf. on Computer Systems and Technologies (CompSysTech 2001), Sofia (2001) 17. Winston, P.: Artificial Intelligence, 3rd edn. Addison Wesley, Reading (1992) 18. Lee, R.C.T., Tseng, S.S., Chang, R.C., Tsai, Y.T.: Introduction to the Design and Analysis of Algorithms. McGraw-Hill, Singapore (2005) 19. Levitin, A.: Introduction to the Design and Analysis of Algorithms, 2nd edn. Addison Wesley, Boston (2007)