Best-First and Depth-First Minimax Search in Practice

Best-First and Depth-First Minimax Search in Practice

Best-First and Depth-First Minimax Search in Practice Aske Plaat, Erasmus University, [email protected] Jonathan Schaeffer, University of Alberta, [email protected] Wim Pijls, Erasmus University, [email protected] Arie de Bruin, Erasmus University, [email protected] Erasmus University, University of Alberta, Department of Computer Science, Department of Computing Science, Room H4-31, P.O. Box 1738, 615 General Services Building, 3000 DR Rotterdam, Edmonton, Alberta, The Netherlands Canada T6G 2H1 Abstract Most practitioners use a variant of the Alpha-Beta algorithm, a simple depth-®rst pro- cedure, for searching minimax trees. SSS*, with its best-®rst search strategy, reportedly offers the potential for more ef®cient search. However, the complex formulation of the al- gorithm and its alleged excessive memory requirements preclude its use in practice. For two decades, the search ef®ciency of ªsmartº best-®rst SSS* has cast doubt on the effectiveness of ªdumbº depth-®rst Alpha-Beta. This paper presents a simple framework for calling Alpha-Beta that allows us to create a variety of algorithms, including SSS* and DUAL*. In effect, we formulate a best-®rst algorithm using depth-®rst search. Expressed in this framework SSS* is just a special case of Alpha-Beta, solving all of the perceived drawbacks of the algorithm. In practice, Alpha-Beta variants typically evaluate less nodes than SSS*. A new instance of this framework, MTD(ƒ), out-performs SSS* and NegaScout, the Alpha-Beta variant of choice by practitioners. 1 Introduction Game playing is one of the classic problems of arti®cial intelligence. Searching for the best move in a zero-sum game is known as minimax search. The study of minimax search algorithms has created ideas that have proved useful in many search domains. For example, this research extends to single-agent search, such as iterative deepening (IDA*) [11], real-time search (RTA*) [12] and bidirectional search [14]. Although two-agent search has many more application areas, the best-known is undoubtedly game playing, the application that we shall be using in this paper. Over the last thirty years, most practitioners used depth-®rst search algorithms based on Alpha-Beta [10] for their game-playing programs. There is an exponential gap in the size of trees built by best-case and worst-case Alpha-Beta. This led to numerous enhancements to the basic algorithm, including iterative deepening, transposition tables, the history heuristic and narrow search windows (see for example [31] for an assessment). Although best-®rst approaches have been successful in other search domains, minimax search in practice has been almost exclusively based on depth-®rst strategies. Best-®rst approaches were more complex and reportedly required more memory, both being serious impediments to their general acceptance. SSS*, a best-®rst algorithm, will provably never build larger trees than Alpha-Beta and generally builds signi®cantly smaller trees [4, 9, 16, 26, 33]. Despite the potential, the algorithm remains largely ignored in practice. This paper presents the surprising result that best-®rst SSS* can be reformulated as a special case of depth-®rst Alpha-Beta. Consequently, SSS* is now easily implemented in existing Alpha-Beta-based game-playing programs, solving all of the perceived drawbacks of the algorithm. Experiments conducted with three tournament-quality game-playing programs show that in practice SSS* requires as much memory as Alpha-Beta. When given identical memory resources, SSS* does not evaluate signi®cantly less nodes than Alpha-Beta. It is typically out-performed by NegaScout [8, 28, 26], the current depth-®rst Alpha-Beta variant of choice. In effect the reasons for ignoring SSS* have been eliminated, but the reasons for using it are gone too! The ideas at the basis of the SSS* reformulation are generalized to create a framework for best-®rst ®xed-depth minimax search that is based on depth-®rst null-window Alpha-Beta calls. A number of other algorithms in the literature, including DUAL* and C*, are just special cases of this framework. A new instance of this framework, MTD(ƒ), out-performs all other minimax search algorithms. In the new framework, SSS* is equivalent to a special case of Alpha-Beta and it is out- performed by other Alpha-Beta variants (both best-®rst and depth-®rst). In light of this, we believe that SSS* should now become a footnote in the history of game-tree search. 2 Null-Window Search and Memory In the Alpha-Beta procedure, a node is searched with a search window. It is well-known that the narrower the search window, the more nodes can be cutoff [16]. The narrowest window possible is the null window, where α = β 1 (assuming integer-valued leaves). Many people have noted that null-window search has a great potential for creating ef®cient search algorithms [1, 5, 6, 8, 19, 30]. The widely used NegaScout algorithm derives its superiority over Alpha- Beta from null-window search [8, 20, 26]. A number of algorithms have been proposed that are solely based on null-window search, such as C* [6, 34] and Alpha Bounding [30]. Knuth and Moore have shown that the return value g of an Alpha-Beta search with window α, β i h can be one of three things [10]: 1. α < g < β. g is equal to the minimax value ƒ of the game tree G. 2. g ≤ α (failing low). g is an upper bound on the minimax value ƒ of G, or ƒ ≤ g. 3. g ≥ β (failing high). g is a lower bound on the minimax value ƒ of G, or ƒ ≥ g. Knuth and Moore have shown that the essential part of the search tree that proves the minimax value is the minimal tree [10]. For a minimax tree of uniform width w and depth d, it has / c d / e d / e bd 2 d 2 d 2 w + w 1 leaves, or, its size is O(w ). If Alpha-Beta returns an upper bound, then its / e value is de®ned by a max solution tree, in a sense one half of a minimal tree, of size O(wdd 2 ). If Alpha-Beta returns a lower bound, then its value is de®ned by a min solution tree, the other / c half of a minimal tree, of size O(wbd 2 ). The theoretical background for these statements can be found in [7, 13, 25, 33]. A single null-window search will never return the true minimax value ƒ, but only a bound on it (which may happen to coincide with ƒ, but this cannot be inferred from the result of the null- window call). A fail low results in an upper bound, denoted by ƒ+. A fail high returns a lower bound, denoted by ƒ . Algorithms like C* and Alpha Bounding use multiple null-window calls to generate bounds to home in on the minimax value. A potential problem with these repetitive calls is that they re-expand previously searched nodes. For NegaScout it appears that the gains of the tighter bounds out-weigh the costs of re-expansions, compared to a single wide-window Alpha-Beta call [21]. An idea to prevent the re-expansion of previously searched nodes is to store them in memory. It is often said that since minimax trees are of exponential size, this approach is infeasible since it needs exponentially growing amounts of memory [9, 18, 29]. For game-playing programs an obvious choice is to use a transposition table for storage [31]. Originally the transposition table was introduced to prevent the search of transpositions in the search space. A transposition is a node with more than one parent, a position that can be reached via several move sequences. Today, transposition tables are often used in combination with iterative deepening [16]. The main bene®t of this combination is to improve the quality of move ordering [15]. Storing information from previous searches is another use of the transposition table. The only difference with preventing the search of transpositions is that now the table entries are nodes from a previous search pass; there is no difference as far as the table itself is concerned. The basic idea is that it is possible to store the search tree in the transposition table. Some background explaining in greater detail why the transposition table is a suitable structure for storing search or solution trees, and why it gives correct results in algorithms doing repetitive null-window searches, can be found in [7, 25]. Since recursive null-window Alpha-Beta calls return only bounds, storing the previous search results comes down to storing a max or a min solution tree. We have shown in [25] that although the search information that must be stored is indeed of exponential size, it is much less than what is often assumed. For the search depths typically reached by tournament- quality game-playing programs, the search information ®ts comfortably in today's memories. Projections of tomorrow's search depths and memory sizes show that this situation will persist in the foreseeable future. 3 A Framework for Best-First Search The concept of null-window Alpha-Beta search was introduced by Pearl with his proof-procedure Test [20]. Since we use memory to store intermediate search information, we have named our framework Memory-enhanced Test, or MT. As proof procedure we use a standard null-window Alpha-Beta procedure for use with transposition tables. The code can be found in ®gure 1. So far, we have discussed the following two mechanisms to be used in building ef®cient algorithms: (1) null-window searches cutoff more nodes than wide search windows, and (2) transposition tables can be used to glue multiple Alpha-Beta passes together.

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    12 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us