conspiracy numbers

ARTIFICIAL INTELLIGENCE 67

Conspiracy Numbers

Jonathan Schaeffer Department of Computing Science, University of Alberta, Edmonton, Alberta, Canada T6G 2H1

ABSTRACT

McAllester' s conspiracy numbers algorithm is an exciting, new minimax search procedure that builds trees to variable depths in an application-independent manner. The algorithm selectively expands nodes in the tree trying to narrow the range o f plausible minimax values at the root o f the search tree. It does so by computing the conspiracy number for each possible root value; the minimum number o f leaf nodes that must change their score to cause the root to change to that value. This paper describes the algorithm and presents an implementation in a computer chess program. Experimental results give rise to optimism about the algorithm's future, although there are still some serious problems to be overcome.

I. Introduction

Shannon, in his seminal paper on computer chess, described two methods for searching game trees [8]. The first, brute-force, involves considering all possible moves to some fixed depth. This approach has the advantage of not missing any interesting moves within the search horizon, but suffers because of the exponential growth of the trees.

The second approach, selective search, involves using application knowledge to select the set of plausible moves to consider. Search depth is not constrained, but the success of the approach depends on the quality of the move selections. Everyone recognizes the advantages of selective search, with its human-like approach, but the method is usually shunned because of the extensive application-dependent knowledge required to make it workable.

A third, intermediate approach to searching has evolved called selective deepening. ~ Parts of the tree are searched to varying depths depending on some application-dependent criteria. For example, common practice among chess programmers is to extend the search depth of a subtree by the number of checking moves encountered. Strictly speaking, these extensions are not brute-force, since they do not examine all possibilities to a fixed depth, nor are

1Tony Scherzer coined this term to the best of my knowledge.

Artificial Intelligence 43 (1990) 67-84 0004-3702/90/$3.50 (~ 1990, Elsevier Science Publishers B.V. (North-Holland)

68 J. S C H A E F F E R

they selective search, since no moves are disregarded; only some selected for preferential treatment. Currently, all the best computer chess programs are largely based on a selective-deepening approach.

Recently, an exciting, new approach for searching minimax trees has been introduced that elegantly bridges the gap between brute-force and selective search. McAllester's conspiracy numbers algorithm selectively expands nodes in the tree trying to narrow the range of plausible minimax values for the root [5]. The likelihood of the root taking on a particular value is reflected in that value's associated conspiracy number. The conspiracy number is the minimum number of leaf nodes in the tree that must change their score (by being searched deeper) to result in the root taking on that new value. These nodes are said to have to conspire for that result to be achieved. A threshold is used to terminate the algorithm. If a value's conspiracy number reaches this threshold, it is considered unlikely that the node can take on that value. The algorithm terminates when only one root value has a conspiracy number less than the threshold.

The conspiracy numbers algorithm is not constrained by depth, such as alpha-beta or SSS* are. Rather, it selectively expands parts of the tree to variable depth trying to gather information on how likely it is that the root can achieve a specific value. The algorithm is a probabilistic search in that when it terminates there is no guarantee that the correct solution has been found; only the most likely one, and that likelihood depends on how high the threshold is. However the new idea in conspiracy numbers is that, unlike similar types of search algorithms such as B* [1, 6], the probabilities used to decide which branch to expand are generated directly from the tree in an application- independent manner.

In this paper, the conspiracy numbers algorithm is described and improvements and enhancements to it discussed. McAllester's original paper only outlined the procedure without presenting a formal algorithm. Four alternate implementations are described that trade off space for time and/or depth of search for breadth.

The algorithm has been implemented in a tactics searching chess program. The results are impressive; on a set of 300 tactical chess positions, conspiracy numbers gave performance comparable to the best chess programs. The potential of the algorithm is illustrated by a problem with a 15-ply solution that would take days of CPU time to solve with a conventional alpha-beta searcher, but is quickly solved by conspiracy numbers. Less successful have been the experiments applying conspiracy numbers to positional chess. The finer granularity of the position evaluation gives rise to a larger range of possible values. The result is that the program is indecisive, having difficulty converging on a single value, while exploring the tree to unnecessary depths. This problem must be overcome before conspiracy numbers will be a viable alternative to depth-first alpha-beta.

CONSPIRACY NUMBERS 69

Conspiracy numbers are an important new idea that allows selective search to be performed in an application-independent manner. Although this paper only presents preliminary work, it is hoped that the potential of the algorithm is evident and that this will provide incentive to others to explore this new research area.

2. Conspiracy Numbers

The simplest way to explain conspiracy numbers is with an example. Consider the minimax tree in Fig. 1 and, for simplicity, assume a constant branching factor of 2. Further, restrict the value of a node to be in the range 1 to 6. For this example, the minimax value of the root node, A, is 3. What is the likelihood that, if we search deeper, the root will change from 3? If the chances are small, then we might as well stop the search, but if high, we should continue. If there were some way of knowing these probabilities, then the search could be stopped when we had enough confidence in the root value, rather than using some artificial criterion, such as depth or time, to make our decision.

In Fig. 1, how many leaf nodes in the tree have to change their value, as a result of being searched one level (or ply) deeper, to cause the minimax value at the root (Vroot) to become 4? If node E is searched deeper and its minimax value changes to 4, then Vroot would become 4. But E is not the only node; a change to F could also have this effect. In other words, if a deeper search of E or F resulted in either of their values changing to 4, then Vroot value would be 4. What about changing V~oot to 1? In this case, either D or E must become 1 and either F or G must also change to 1. Hence a minimum of 2 nodes in the tree must change their value. The minimum number of leaf nodes that must conspire to change to alter Vroot is the conspiracy number for that value. Table 1 shows the conspiracy numbers for Fig. 1 with the nodes that must change to achieve that result.

Conspiracy numbers represent the likelihood of a node taking on a particular value. For Fig. 1, only one node in the tree must change value to make Vroot 5,

Fig. 1. Minimax tree.

70 J. SCHAEFFER

Table 1 Conspiracy numbers and conspirators

Value CN Nodes to change

1 2 (D or E) and (F or G) 2 1 (F or G) 3 0 4 1 (E or F) 5 1 E 6 2 (D and E) or (F and G)

but two nodes are required to make it 6. It is therefore less likely that additional search will result in Vroo~ becoming 6 than 5.

It turns out that there is a simple method for calculating conspiracy numbers. At a MAX node in the tree (such as the root), if we want to increase the value of that subtree, only one of the sons of the root need change value. The conspiracy number for that value would then be the minimum over all the sons (the one requiring the least amount of work to raise its value). If we wanted to decrease the value, then all the sons whose value is greater must be decreased. Hence, we must sum the number of conspirators for these nodes. It is the reverse at MIN nodes.

The conspiracy numbers for leaf nodes are easy. If the evaluation of a node is v, then the conspiracy number associated with v is 0 and for all other values is 1. Nothing has to change to achieve v, but one (that leaf node) must change to achieve any other value. Further, if that leaf node is terminal (its value is absolute), then the alternative values can be viewed as requiring ~ conspirators.

For an interior node, consider breaking the set of conspiracy numbers into two groups: the numbers required to increase a node's value (~needed) and those to decrease it ($needed). Values below the minimax score in ~needed and above the minimax score in ~,needed are assigned 0. For node A in Fig. 1, ~needed is (0 ,0 ,0 , 1, 1,2) and +needed is (2, 1,0, 0 ,0 ,0 ) . $needed and ,~needed of an interior node's sons can be combined to form the parent 's

conspiracy numbers, CN, using the following rules (with v being a value and m being the minimax value):

CN(v) = O , i f v = m .

For a MAX node:

CN(v) = ~] ~neededi(v ) for all v < m , al l s o n s i

CN(v) = min ~neededi(o ) for all v > m . al l s o n s i

C O N S P I R A C Y N U M B E R S 71

For a MIN node:

CN(v) = min ~neededi(v ) for all v < m , all sons i

CN(v)= ~ Tneededi(v ) for all v > m . all sons i

Figure 2 contains the conspiracy number vectors for Fig. 1, with Tneeded and J, needed merged into one vector. It is worth pointing out that if v < w, then ~needed(v) <~ ~needed(w) and Sneeded(v) >i Sneeded(w).

So how do we use conspiracy numbers? Since they represent likelihoods, the idea is to search until it is unlikely that the value of the root of the tree will change. The algorithm uses a conspiracy threshold, CT, the minimum number of conspirators required to consider a value unlikely. Nodes in the tree are expanded in such a way as to narrow the range of possible root values until only one has a conspiracy number less than the threshold. Of course, this method is not guaranteed to find the best move, but the higher the threshold, the greater the confidence in the choice of move. Consider, for example, the case where a tree has a minimax value of 3, but to change it to 2 or 4 requires 100 nodes to conspire. The chances of all those nodes successfully conspiring is very small. That does not mean it cannot happen; just unlikely.

Nodes are expanded in a manner that tries to alter the conspiracy numbers of the minimum and maximum plausible values of the root. Consider Fig. 2 with a conspiracy threshold of 2. Values 1 and 6 are considered unlikely because they require at least CT conspirators. The minimum plausible value (Vmin) is 2, the maximum plausible value (Vmax) is 5, and the likely value (Vroot)

11 11 2 0 ~ o z ~ f - ~ 2 1

4 1 4 1 5 2

11 I 1 2 1 2 1 3 1 3 1 4 1 4 0 5 0 5 1 6 1 6 1 6 1 6 1

Fig. 2. Consp i r acy n u m b e r s .

72 J. SCHAEFFER

is 3. There are more plausible values above Vroot than below (V,,ax- Vroot > Vroot- Vmin), SO the algorithm tries to narrow the range from above. In this case, it will expand a node that tries to change Vroot to 5 (lncreaseRoot). It will either succeed in doing so, thereby changing the range of values at the root, or fail, hopefully increasing the conspiracy number associated with 5 to at least CT. From the root, node B has a conspiracy number of 1 for value 5, while C has 2. Since there appears to be less work to do to change B to a 5 than C, the algorithm descends to node B.2 At B, nodes D and E are examined and node E is elected to be searched; there is no point in going to D since it already has achieved the desired value. Node E is a leaf, so it is extended one ply deeper (see Fig. 3). The result is that V~oot changes to a 4, but the range of possible values at the root has decreased from 2 -5 to 3-5 .

In Fig. 3, the range of possible values above and below 4 are the same, so we arbitrarily decide to try to change the minimax value of the tree to 3 (DecreaseRoot). We choose to descend to node B over C because C has already achieved the value of 3. There is nothing to choose between considering nodes D and E, so the algorithm arbitrarily chooses to consider the left-most son. Expanding D results in Fig. 4. Although the conspiracy numbers at the root have changed, there has been no effect o n Vmi n and Vm, x.

11 21 31 41 50 61

31 4 0

11 51 11 21 62 21 31 30 4 0 41 51 52 62 62

22 21 31 30 4 0 41 51 51 61 61

11 ~ 11

3 0

51 61 61

Fig. 3. Expansion of node E.

11 21 31 4 0 51 61

2 Of course, one would not want to consider C since it already is at CT. The point here is to take

the alternative requiring least work.


11 21 31 41 50 61

12 21 I 41 50 61

6

12 ~ I I 21 ~ o z ~ f - - ~ 21

40 ~= '~ ) ~='~} 41 51),.......,'( xr.~..~ 52

J 61 \ 61

O ...A. x .,.-L.. 1 ..-.~... 21 1 1 3 0 1 (Ko3 ° l ~ . ~ ~ 1 ~ . . J 51

1 61

Fig. 4. Expansion of node D.

11 21 31 40 51 61

Were the algorithm to be carried on an additional step, if the lncreaseRoot strategy were employed, node J would be expanded, but with DecreaseRoot, node H.

Conspiracy numbers is an elegant method for gathering probabilities from the tree and using that as a guide of where to search. However, this type of search strategy has to be taken in the context of the strengths and weaknesses of the algorithm. On the positive side, the algorithm will search deep on some lines and shallow on others. In the context of computer chess, this means that forcing sequences are automatically searched deeper. Typically the opponent has only a few valid responses in such a sequence. As a result, the conspiracy numbers along these lines are low, because only one or two nodes have to prove to be winning to result in a good score at the root. On the negative side, the program often expands lines to ridiculous depths futilely attempting to prove something that is not there. Consequently, convergence of the algorithm can be slow and, in fact, it may never converge.

3. Implementing Conspiracy Numbers

In his paper, McAllester described conspiracy numbers in general terms, without getting into the specifics of a formal algorithm. In this section, an algorithm reflecting our interpretation of his method is presented.

The important observation about how the algorithm grows trees is that it moves around in the tree irregularly. It is not like a depth-first alpha-beta

74 J. SCHAEFFER

search, where there is a fixed pattern that the search algorithm follows so only a small portion of the tree need be present in memory at any given time. For conspiracy numbers, the only practical implementation method is to store the entire tree in memory. Although this causes problems for memory-limited systems, the falling cost of memory makes this a viable solution.

A problem arises as to what to store in the tree. Of course moves, scores and pointers are required, but what about the conspiracy numbers? One approach is to store ~needed and +needed at each node, thereby making the re- computing of these vectors easy. The problem is that if the range of possible values is large, then considerable storage is required. On the other hand, if the conspiracy numbers are not saved at interior nodes of the tree, then the cost of traversing the entire tree to re-compute them may be prohibitively high.

Both approaches have been experimented with. In the latter, a compromise was used whereby only the conspiracy numbers for Vmi n and Irma x were stored at interior nodes. Then, re-calculating conspiracy numbers only occurs when Vm, ~ or Vm~ x changed. If storage is a problem, this approach is viable, but the periodic re-traversals of the tree proved to be expensive. The alternative of saving conspiracy numbers at the nodes has little CPU overhead; just additional space. Since our experiments convinced us this was the faster method, it was used for all experiments reported in this paper. However, for other applica- tions, this may not be a good choice.

Appendix A gives the pseudocode for a version of the conspiracy numbers algorithm that saves the conspiracy numbers at all interior nodes. The algorithm presented differs in a fundamental way from that originally proposed by McAllester. His strategy for the lncreaseRoot and DecreaseRoot routines emphasized depth-first searching over breadth-first. In our experiments, we often found the program pursuing possibilities to ridiculous depths in the tree, when a little more breadth at a node would solve the problem more quickly. The code in Appendix A reflects a change to the algorithm to give some breadth at nodes before depth. This change obviates the notion of local conspiracy thresholds mentioned in McAllester's paper.

4. Algorithm Enhancements

Experience with the algorithm suggests several enhancements that can be made to improve its performance. For this paper, some have been tried while others remain to be experimented with.

First, experience with random trees (not reported here) showed that convergence of the algorithm can be slow, even for small conspiracy thresholds. In the context of a chess program, there is always the pressure to make a move every three minutes. A slowly converging algorithm can be a problem. A simple solution is to borrow the idea of iterative deepening from the alpha-beta algorithm [9]; instead of iterating on depths, we iterate on thresholds. All the results presented in the next section start with a threshold of 2, and having


successfully solved that, increase the threshold to 3 and continue the search, and so on. The search can be stopped at any time with a known confidence (the highest conspiracy threshold achieved) in the best move(s).

Another idea borrowed from alpha-beta searching is the use of minimal windows ([4], for example). The tree can be searched with a narrow range of values centered around the expected value of the tree. If the true minimax value falls in this range, then it is achieved using less CPU and less storage. On the other hand, if it falls outside the range, then the search must be re-started with a wider window encompassing the value. This method has the advantage that if the window is small, then the conspiracy numbers can be stored at interior nodes of the tree with little storage penalty. This method has great potential for bridging the CPU versus space tradeoffs of the algorithm.

A further refinement, not implemented, is transposition tables [9]. Nodes in the tree may not be unique; in chess different move sequences may lead to the same position. Transposition tables would be used to detect identical positions in the tree and having them point to the same node. This would help reduce storage requirements and reduce wasted computation.

These points do not exhaust the possibilities, but are intended to emphasize that there is still room for making significant improvements to conspiracy numbers.

5. Performance: Chess Tactical Play

The conspiracy numbers algorithm has been implemented in a chess tactics searching program called CONSPIRE. The application of chess tactics is ideal for experimenting with conspiracy numbers. The range of possible values at the root is limited, allowing a space-intensive version of the algorithm to be used. The program is simple, evaluating leaf nodes solely on material balance. Position evaluation is done by an alpha-beta capture search. Capture moves are considered to arbitrary depth and checking moves are only considered at the root of the capture tree. A leaf node is assigned one of 21 values : -10, lose a king, - 9 , lose 9 pawns (a queen) or more; - 8 lose 8 p a w n s ; . . . - 1 , lose a pawn; 0, equality; +1, win a p a w n , . . . +9, win 9 or more pawns, +10, win a king.

To test the program, the 300 tactical positions from the book, W i n at Chess

[7], are used. CONSPIRE evaluates positions solely on material balance with no positional considerations. Thus the criteria for correctly solving a problem is that it find the move that wins the most material without, in the case of two or more correct moves, having to decide which is positionally best. Of the 300, two are discounted because there are no solutions that win material. 3 Thus the effective test set is 298 positions.

3 For one of these, Win at Chess #180, CONSPIRE discovered that the "winning" move does not in fact win any material but still happens to be best for positional reasons.

76 J. SCHAEFFER

Table 2 Experimental results

Time CONSPIRE PHOENIX

(minutes) Correct Threshold Correct Depth

3 225 4.9 240 6.0 10 251 6.7 259 6.9 30 265 8.9 266 7.6 60 273 12.0 267 8.0

Table 2 shows the performance of CONSPIRE on the Win at Chess positions as a function of t ime on a SUN 3/75 (roughly two VAX 11/780s in performance). For comparison purposes, the test data was run on the chess program PHOENIX, 4 a

selective-deepening alpha-beta search program. The table shows the number of problems correctly solved by both programs, the average threshold achieved by CONSPIRE, and the average search depth of PHOENIX. Several positions where the programs make the right move for the wrong reasons have been classified as incorrect solutions. Initially PHOENIX outperforms CONSPIRE, but with 60 minutes CONSPIRE is able to solve successfully more problems. Of the problems, 259 were solved by both programs, 7 by neither, 14 by CONSPIRE only, and 8 by only PHOENIX. For the 3-minute data point, CONSPIRE was at a disadvantage since inspection of the algorithm shows it always builds a 2-ply minimax tree. For some positions, the cost of building and evaluating this tree was in itself over half of the allotted 180 seconds. Nevertheless, these are remarkably good results for CONSPIRE, especially when one considers that this algorithm is in its infancy and there is room for major improvements and enhancements.

These results can be compared with two other programs. Palay's work with the B* algorithm yielded 245 correct solutions (excluding those where the right move was chosen for the wrong reason), using a maximum of 4 hours of VAX 11/780 time per position [6]. The chess machine BELLE 5 has also solved 273 problems [6], using 3 minutes per position (its hardware is roughly 50-75 times faster than a SUN 3/75). There are 8 problems that both BELLE and CONSPIRE cannot solve, and 17 that BELLE could not solve but CONSPIRE could because the solution extended beyond the 8 -9 ply BELLE was typically searching.

The fact that PHOENIX can do so well is largely due to the test data used. Table 2 shows that PHOENIX can search 6 ply in 3 minutes, but in an hour can only reach 8 ply. Thus most of the problems do not require deep searches to be solved. However , PHOENIX cannot do significantly bet ter on the test data

4One of four programs tying for first in the 1986 World Computer Chess Championship, Cologne, FRG.

5World Computer Chess Champion, 1980-1983.

C O N S P I R A C Y N U M B E R S 77

without considerably more time. An extra ply of search costs roughly a 5-fold factor in time. Allowing PHOENIX 5 hours per position would only add one additional ply of search. CONSPIRE, on the other hand, has no such limitations. Given a test set whose solutions required 10 ply or more, it is doubtful whether PHOENIX could solve any in one hour, whereas CONSPIRE may do well.

Figure 5 illustrates the potential of conspiracy numbers (Win at Chess #270). The solution requires 15 ply but, with selective deepening, PHOENIX need only search 13 ply to see the win of material beginning with Qd4g4. With one hour of CPU time, the program can only make it half way through 9 ply before running out of time. In contrast, CONSPIRE finds the win in 10 minutes.

Conspiracy numbers is not without its problems. Consider Fig. 6 (Win at Chess #163). The winning line begins

1 . . . . Qf3g2t 2. Ne3×g2 h 3 × g 2 t 3. Kh2×g2 Bg4f35- 4. Qb3×f3 e 4 × f 3 t 5. Kg2gl (Fig. 7).

CONSPIRE has no problem getting this far. From here, the solution runs

5 . . . . Rf8f5 6. any Rf5h5 7. any Rh5hl mate. 6

Consider White's 7th move. f f the program ever gets to this position, then the evaluation function is smart enough to discover that all moves lead to mate. Backing up one move, on evaluating the position after Rf5h5, the program concludes the position is even (or in some lines losing) because it cannot see

~- , - /~ : ; . ~ . . ;._y__-,. "///,~,. V/,'~. . . . . . . . . . .~ "//'.-~,~

Fig. 5. White to move.

6There are minor variations on this analysis that are not important to the point being raised.

78 J. SCHAEFFER

Fig. 6. Black to move.

IN NxN N


that the mate is forced regardless of any response by White. Going back further to White 's sixth move, in the program's opinion, all White 's moves lead to even or winning positions. Consequently the number of nodes that must conspire to achieve a losing value for White is h igh- -grea te r than the number of legal moves in the position. The point of this discussion is to show that variations involving a free move by one side are difficult to solve unless either the conspiracy threshold is set high enough or the evaluation function has bet ter assessment capabilities. Of the 25 positions CONSPIRE does not solve, at least 10 are due to this problem.

Another example of the importance of the evaluation function is the ordering of moves at expanded nodes. The moves are sorted on their evaluation scores, a heuristic a t tempt to put the best ones first. Assume that the winning move gets sorted into l l t h place because the evaluation function is not capable of assessing its real strength. It is possible that with a conspiracy threshold of 10 this move will never be considered. The first 10 moves may be sufficient to increase the conspiracy number to the threshold, thus never getting a chance to consider the l l th . Of course, if the threshold is high enough, the move will eventually be found. As is obvious from Table 2, even for a threshold of 10 it may take a long time to get there. Thus it is important to have a good move ordering scheme. Solutions to some of the Win at Chess positions incorrectly solved by CONSPIRE can be found by increasing the application-dependent knowledge to improve the move ordering.

Figure 8 (Win at Chess #7) perhaps best illustrates that there remains work to be done in improving the algorithm. The solution, Ng4e3 winning a queen, is "obvious" and is quickly found by both PHOENIX and CONSPIRE. However , with an hour of CPU time, CONSPIRE is only able to verify this move to a threshold of 8. In such a case, where there are no other moves that come close to winning material , one feels that there must be improvements available in the algorithm to get bet ter results.


X//K'4 -- /,N, _ _ //Ai,z ~,///, //_///." y///, .... ~/,/,

N.N. N ,.N


Table 3 Resource usage

T i m e Expansions Storage (minutes) (nodes) (bytes)

3 34,531 234,137 10 99,725 661,967 30 297,738 1,976,745 60 628,414 4,168,379

A major concern of the algorithm is its space requirements. Although any statistics given are implementation-dependent, an idea of the requirements might be insightful. Table 3 shows the average storage used and number of nodes expanded for the results reported. Space usage for endgame positions tends to be higher than for the middle game. In the endgame, the program spends little time evaluating positions, allowing it to build significantly larger trees. The data for 60 minutes does not include four endgame positions where we ran out of storage.

Although storage usage may eventually be a problem, there are several things that can be done to minimize its usage. The first is transposition tables as previously mentioned, although it is not known how significant an improve- ment this will be. The second is a better evaluation function. It has already been pointed out that a better evaluation function can improve performance. By increasing the sophistication of CONSPIRE's evaluation routine, the program will spend more time computing, and therefore build the tree at a slower rate.

6. Performance: Chess Positional Play

The next logical step was to experiment with conspiracy numbers in a chess program that could play positional as well as tactical chess. Positional play

80 J. SCHAEFFER

requires an evaluation function which has extensive application-dependent knowledge. The result is a finer granularity of values, increasing the number of possible root values.

PHOENIX'S evaluation function assesses chess positions to the granularity of 1/100th of a pawn. With the space-intensive version of the algorithm, it is not feasible to store conspiracy numbers for all these possible values. Accordingly, to minimize storage requirements the positional granule was set at 1/10th of a pawn. CONSPIRE classified a score as winning or losing material, and for those where the balance was maintained, used PHOENIX's evaluation function to assign a score. Positional scores were divided by 10, allowing CONSPIRE to assign 21 possible positional scores: -10 /10 , - 9 / 1 0 . . . . . 0 . . . . . 9/10, 10/10 of a pawn. To test the program, the 12 nontactical problems from the Bra tko-Kopec set of positions [3] were used.

The results were disappointing. Of the 12 positions, CONSPIRE with one hour of CPU time could only match 3 of 7-ply PHOENIX'S solutions. The program had enormous difficulty converging on an answer, as was reflected by an average threshold of 3 achieved. (Some problems never achieved consensus for a threshold of 2!) Examination of the trees indicates that the program does a lot of unproductive searching deep in the tree. These results are consistent with work done at Carnegie-Mellon University [2].

Why the indecision? A theory is that the evaluation function is not stable enough. From move to move, the assessment of the position would change, if only by a small amount (unlike in the tactical case). This would make it difficult for the algorithm to converge on one value. One way of increasing the stability of the evaluation function is to increase the distinction between differently valued positions. Re-running the experiments using a positional granule of 1/Sth of a pawn, instead of 1/10th, did not increase the number of correctly solved problems. However, the average conspiracy threshold achieved in- creased to 5. Stability of the evaluation function may be part of the problem but it cannot be part of the solution. The Carnegie-Mellon group has made similar observations about the stability of evaluation functions [2].

Explanations of this phenomenon and improvements to the algorithm to solve it are the subject of current work.

7. Conclusions and Further Work

Upon initially embarking on this project, there was a lot of skepticism as to how effective conspiracy numbers would prove to be in practice. Several months of work later, the question now is how good is it? It does a t remendous job on tactical positions, proving to be at least the equal of alpha-beta search. On the other hand, we have yet to repeat this success with positional chess, where the range of possible values is much higher and convergence appears to


be significantly slower. Nevertheless, conspiracy numbers is a fresh idea where it is hoped a lot of research effort can be devoted to in the near future.

There are three conspiracy number projects currently under way at the University of Alberta. First is the continued investigation of the problems encountered with positional play. More work is required on understanding the algorithm and its behavior, both in theory and practice. The long-range goal is to have the algorithm implemented in PHOENIX. A complication is that it requires too much storage to save all the conspiracy numbers at interior nodes. Re-calculating them can be CPU expensive. Compromise strategies are under development.

Other issues need to be raised if the algorithm is to be used in a competitive chess program. For example, at what threshold do you terminate the algorithm? You could use time as the stopping criteria, but what if time runs out and you are only at threshold 2? Do you have enough confidence to make the suggested move? Also, the algorithm converges on a root value, not a move. There may be more than one move suggested as best by the algorithm. How do you distinguish between them?

Second, the B* algorithm, with its notion of optimistic and pessimistic values bounding the value of a position, is an elegant proof procedure. A serious defect with the algorithm has been the use of artificially constructed probabilities to guide the search. Conspiracy numbers provide a means for generat- ing probabilities directly from the tree searched. A hybrid algorithm combining the best of both B* and conspiracy numbers might be a powerful search procedure.

Third, a parallel implementation of conspiracy numbers is under construc- tion. A simple implementation has a MASTER process to maintain the tree and N EVALUATOR processes that are assigned leaf nodes to evaluate by the MASTER. When the MASTER expands a node, it passes off each move to an available EVALUATOR for assessment. Since the quality of the leaf node score can improve program performance, our implementation has each leaf node being evaluated by a 2-ply alpha-beta search with capture searching. In this way, it is hoped that running time of the program can be improved to the point where conspiracy numbers can become a viable alternative to depth-first alpha-beta searching.

Appendix A. The Conspiracy Numbers Algorithm

The following is a pseudocode description of the algorithm using C-like programming constructs. Several items to note are the following:

(1) The data structure used at each interior node of the tree is storage- inefficient and is presented this way solely for readability. For example, '~needed and Sneeded can share the same vector. The minimax value of a

82 J. SCHAEFFER

subtree can be obtained by looking in "~needed and Sneeded. In our implementation, the information was tightly packed to minimize storage usage.

(2) EvaluatePosition, MakeMove and RetractMove are chess-specific routines to assign a value to a position (evaluate a node), make a move (descend the tree), and undo a move (ascend the tree) respectively.

(3) GetStorage allocates space for a record.

/* Info stored at all interior nodes of the tree */ struct record {

integer Tneeded[ 1..MAX_VALUES ]; /* conspiracy numbers integer ~needed[ 1..MAX VALUES ];

integer minimax; integer values[ 1..MAX MOVES ];

integer moves [ 1..MAX MOVES ]; record * nextp [ 1..MAX MOVES ];

}

/* Driver routine for conspiracy numbers. int CN TOP LEVEL( threshold ) {

Expand( root, I, MAXNODE );

V~t = root.minimax;

Vmm = LowerBound( root, threshold ); Vm,x = UpperBound( root, threshold );

while( Vmi, < Vm,~ ) {

if( ~t - Vmln > V~, - V~o t )

DecreaseRoot( root, threshold, MAXNODE, NULL ); else IncreaseRoot( root, threshold, MAXNODE, NULL );

~t = root.minimax;

Vmi, = LowerBound( root, threshold );

Vm,x = UpperBound( root, threshold ); }

return( ~, ); }

/* Compute Vmm. UpperBound calculates V~x similarly. */

int LowerBound( node, threshold ) (

for( i = i; i <= MAX VALUES; i++ )

if( node.lneeded~ i ] < threshold

return( i ); }

/* Expand a position. Parameters are a pointer to parent node, which son of /* the parent is being expanded, and the MINNODE/MAXNODE type of node. Expand( node, son, type ) (

node.nextp[ son ] = new = GetStorage();

w = GenerateMoves( movelist[] ); for( move = i; move <= w; move++ ) [

new.moves[ move ] = movelist[ move ]; new.nextp[ move ] = NULL; MakeMove( movelist[ move ] );

/* minimax value of this node */ /* values of sub-trees */ /* moves from this position */

/* pointers to other nodes */

Takes a CN threshold as parameter. */

/* loop until convergence */

*/ */


new.values[ move ] = EvaluatePosition(); RetractMove( movelist[ move ] );

} Sort( new.values[] ); /* Sort movelist to put best moves first. */ ComputeCN( new, type ); /* Re-calculate CN and minimax value. */

/* DecreaseRoot strategy. Descend tree to find node to expand. IncreaseRoot */ /* is similar with MAXNODE and MINNODE roles reversed. */

DecreaseRoot( node, threshold, type, move ) {

if( move != NULL ) /* Descend the tree. */ MakeMove( move );

if( type == MINNODE ) {

best = NULL;

for each son of node {

if( son.minimax <= V,~ ) continue;

if( TERMINAL( son ) ) {

Expand( node, son, type ); goto done;

}

/* At MINNODES, take the node with the */

/* smallest conspiracy number for V~, */

/* Exclude values outside the */ /* range we are interested in.*/ /* Must have a CN of i, which */ /* means it is the smallest. */

/* Alternate implementation is to replace the following state- */ /* ment with a call to DecreaseRoot and then goto done, similar */ /* to type == MAXNODE case. */

if( son.lneeded[ Vma ] < threshold ) /* Otherwise, find interior */ { /* node with smallest CN. */

best = son; threshold = 3on.~needed[ V,~ ];

} }

if( best != NULL ) /* Search node with minimum conspirators. */ DecreaseRoot( node.nextp[ best ], threshold,

MAXNODE, node.moves[ best ] ); else Print( "Should never happen" );

}

else /* type == MAXNODE */ /* At MAXNODEs, take the first terminal */

{ /* node or, if all are interior, the */ for each son of node /* left-most son greater than V,~. */ {

if( son.minimax <= V.~ ) continue;

if( TERMINAL( node ) )

Expand( node, son, type );

else DecreaseRoot( node.nextp[ son ], threshold,

MINNODE, node.moves[ son ] ); goto done;

}

Print( "Should never happen" ); }

done: if( move != NULL )

RetractMove( move ); ComputeCN( node, type );

/* Ascend the tree. */

/* Compute new conspiracy numbers for this node */

84 J. SCHAEFFER

ComputeCN( node, type ) {

/* For this node, calculate node.minimax, node.Tneeded, and node.$needed */ /* depending on whether the type is a MAXNODE or MINNODE. Use the form- */ /* ulas given in section 2 of this paper. */

l

ACKNOWLEDGEMENT

Norbert Klingbeil and Robert Enns built a version of conspiracy numbers to search random trees. Klingbeil also created the CONSPIRE program. Lisa Lister has done some work on the theoretical aspects of conspiracy numbers.

This work was supported by Natural Sciences and Engineering Research Council of Canada grant A8173.

REFERENCES

1. H.J.. Berliner, The B* tree search algorithm: A best-first proof procedure, Artificial Intelligence 12 (1979) 23-40.

2. H.J. Berliner, Private communication, Noordwijkerhout, Netherlands (1987). 3. D. Kopec and I. Bratko, The Bratko--Kopec experiment: A comparison of human and

computer performance in chess, in: M.R.B. Clarke, ed., Advances in Computer Chess 3, (Pergamon, Oxford, 1982) 57-72.

4. T.A. Marsland, A. Reinefeld and J. Schaeffer, Low overhead alternatives to SSS*, Artificial Intelligence 31 (1987) 185-199.

5. D.A. McAllester, A new procedure for growing mini-max trees, Tech. Rept., Artificial Intelligence Laboratory, MIT, Cambridge, MA (1985); revised version: Conspiracy numbers for min-max search, Artificial Intelligence 35 (1988) 287-310.

6. A.J. Palay, Searching with Probabilities (Pitman, Marshfield, MA, 1985). 7. F. Reinfeld, Win at Chess (Dover, New York, 1945). 8. C.E. Shannon, Programming a computer or playing chess, Philos. Mag. (7) 41 (1950) 256-275. 9. D.J. Slate and L.R. Atkin, CHESS 4.5: The Northwestern University chess program, in: P.W.

Frey, ed., Chess Skill in Man and Machine, (Springer, New York, 1977) 82-118.

conspiracy numbers

Documents