Newsgroups: comp.ai.games
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!spool.mu.edu!torn!watserv2.uwaterloo.ca!undergrad.math.uwaterloo.ca!eadengle
From: eadengle@watcgl.uwaterloo.ca (Ed "Cynwrig" Dengler)
Subject: Re: 'lookahead vs. evaluation' or pruning in general
Message-ID: <D7AJAL.5As@undergrad.math.uwaterloo.ca>
Keywords: lookahead evaluation pruning
Sender: news@undergrad.math.uwaterloo.ca (news spool owner)
Nntp-Posting-Host: cgl.uwaterloo.ca
Organization: University of Waterloo
References: <3mj43i$300@ucthpx.uct.ac.za> <3musin$o0m@inferno.mpx.com.au> <D78LK9.EGE@undergrad.math.uwaterloo.ca> <will-1904951303230001@willsmac.cs.su.oz.au>
Date: Wed, 19 Apr 1995 16:32:44 GMT
Lines: 76

Greetings!

In article <will-1904951303230001@willsmac.cs.su.oz.au>,
Will Uther <will@cs.su.oz.au> wrote:
>> P.S. As an interesting observation, lookahead and evaluation seem to be
>> very complementary types of information about a position, but which seem
>> to be handled separately on most of todays programs.  Guided lookahead should
>> be able to simplify an evaluation function (since "in the future" results
>> would not have to be explicitely coded) while an appropriate evaluation
>> function should be able to provide the guidance needed.  However, most Go
>> and Chess programs work on the two as separate entities, which is where
>> the problems of "combinatorial explosion" comes about (as an example of how
>> to reduce the explosion, expert human players seem to consider only the
>> "correct" moves, and by doing so, prune out much useless search).
>
>Hi,
>
>Actually, there are many examples of people using the evaluation function
>to guide search and aid pruning.

To make the overall general point, the methods described below all suffer
from "combinatorial explosion" since they still generate an exponentially
growing tree.

>Probably the most well known is the fact that if you order the game-tree
>search at any level, so that the best moves are searched first, then
>Alpha-Beta pruning gives it's largest speedup.  As the evaluation function
>is only approximate then this order is only approximate in the real world
>(how come noones written an oracle yet - Lots of AI algorithms work so
>much better with them...) but it can give a dramatic speed-up in
>look-ahead.  Using stronger pruning, eg 'minimal window' pruning, can
>speed this up even more IF the ordering is good - but will slow it down
>otherwise.
>
>The idea of 'evaluating' the entire tree at the current depth before
>searching one deeper, 'iterative deepening', can also be useful.  It's
>similar to doing breadth-first, rather than depth-first, search in the
>game tree, but still allowing pruning.

All of the above are provably equivalent to min-max.  While they improve
upon the standard min-max algorithm, they are nowhere near the necessary
"risky" pruning strategies used by people (ie. where a pruning can occur
at multiple different levels, including the first).  Most evaluation
algorithms cannot be compared at different levels of the tree (to see this,
take any Chess or Othello algorithm derived from tweaking and compare the
evaluations at two adjacent levels.  You will typically notice huge
differences).

>I don't know much about game tree pruning that is not admissible.  Maybe
>someone else knows more about these methods.  I do know that there has
>been some interesting work on concentrating the search to separate the
>best move rather than work out just how bad the others are.  Anyone know
>more about these methods?

Most of the work in this area (such as A*) has tended to concentrate on
either a single agent (ie. no opponent) or where the tree can be searched
to the end (eg. I tried to implement B* search for an Othello program,
which failed since some searches would concentrate entirely on trying to
prove the best move was actually the best, even though the game still had
40-50 empty spaces to fill and would never reach the end in the time allowed).

There has been a bit more research into real-time searches which must provide
an adequate search in a given time limit (which is why iterative deepening
was first employed), but many of these deal more with the continuous domain
of robotic motion rather than game playing.

>
>\x/ill         :-}
>
>-- 
>     William Uther           will@cs.su.oz.au or http://www.cs.su.oz.au/~will/
>"Nothing is so smiple it     Basser Dept. of Computer Science
> can't be stuffed up"        University of Sydney, Australia

Ed

