Advanced Topics

PSU CS410/510GAMES Lecture 5
May 2, 2002

• ID: Iterative Deepening (again)
  • Ideas: Hard to predict search time. Need to order moves well.
  • Implementation: Use ID to time limit. Note convergence of root value? Use ttable to order moves effectively (via values from previous iteration).
  • Problem: Want to leverage transposition table to decrease search, but how?
  • Idea: Horizon effect is a nightmare. Search deeper where it matters
  • Implementation: AB already prunes out-of-bounds leaves. Use secondary heuristic to estimate accuracy of primary heuristic ("quietness"), extend search where necessary.
  • Problem: Hard to build/tune.
• Putting it all together: zero-window search
  • Idea: Could prove a known value quickly.
  • Implementation: Start the AB window closed on some guessed value. At some point, may find that no line achieves this value. Can track "fail-low" vs. "fail-high".
  • Advantage: Goes very fast if you have good estimates.
  • Disadvantage: Goes very slowly if you have bad estimates.
  • Modern implementation: MTD(f) [Plaat 1996]
• Search Extensions
  • Quiescence search
    • Horizon Effect is classic problem; don't stop in middle of exchange and guess
    • Determine quiescence by seperate heuristics or by variance in root value
  • Principal Variation Search (PVS) = Korf: ``best-first minimax''
    • Idea: trust eval in interior of tree to prune ``bad'' moves early
    • Trick: always extend (leftmost) path determining root value (variant of AB)
    • Suffers from ``early mistake'' problem: fix by depth cutoff (common), weighting, sampling, etc.
• Shape of game space
• Openings
  • Sometimes a good-looking early move goes bad way later
  • In clocked games, want to not waste clock on known positions
  • Human players have (often vast) opening books
  • Computer opening book problems:
    • Human-generated books have bugs: opening traps or ``cooks'' [no learning = repeatable cooks]
    • Human-generated books have commentary and analysis: ``sympathy'' problem of dumping program into not-understood position
    • Strictly ``by the book'' deals poorly with transpositions, falling out of and back into book, irrelevant moves, etc.
      • Transposition table helps: implementation technique is to store book positions irremovably in t-table
        • Would prefer position classes, but...
        • Can explicitly indicate successor, or try to "rig" things by giving bonus in evaluation function for staying in book
    • Sympathy problem means transition to middle game not smooth (why am I here? What's in the t-table?)
  • When are we in middle game?
    • When out of book
    • When significant event happens (e.g. castling, material exchange)
    • When eff. branching factor goes up
• Endgames
  • When are we in the endgame?
    • When material is small
    • When branching factor becomes large
    • When terminal nodes are reached
  • Traditional endgame approach: programmed knowledge
    • Trades human work for generality
    • ``Theorem Proving'' approach
    • Problem: pattern matching
  • Which endgame positions are reachable? Who knows?
    • Idea: if game is monotonic in material, work backward = ``Retrograde analysis''
    • Dynamic programming technique: explore until conversion
    • Requires huge database (chess 5-piece = 150M positions)
    • Can profitably be calculated in parallel
  • Endgame oddities: chess
    • Discoveries: certain endgames are nonintuitive. Effective consequences?
    • Transition from middle game not always smooth: sacrifice to known (database or heuristic) win