RE: computer-go: A problem with understanding lookahead

["Joe Berry" <jberry02@xxxxxxxxx>]

Hello!

	In most (if not all) tactical situations you need lookahead to
determine where next to play.  A simple example - your opponent has a
group that is isolated, and the group only has a single 3-space eye.
You need lookahead to determine that if you play on the center point,
you can kill the group.  Now, you might argue that you can implement a
pattern or a heuristic that tells your program to play on the center
point; I would argue that such an approach *is* a form of lookahead,
just one that is hard-coded.

	So, you can code in patterns and/or heuristics to help *optimize* the
lookahead for specific situations, but it is still lookahead.  Where you
need the minimax tree is to address situations where you don't have a
pattern or heuristic.

Joe


> -----Original Message-----
> From: owner-computer-go@xxxxxxxxxxxxxxxxx
> [mailto:owner-computer-go@xxxxxxxxxxxxxxxxx]On Behalf Of GL7: David
> Elsdon
> Sent: Tuesday, January 16, 2001 3:03 PM
> To: computer-go@xxxxxxxxxxxxxxxxx
> Subject: computer-go: A problem with understanding lookahead
>
>
> Hello all,
>
> I have a serious problem with lookahead. I don't understand
> why it works.
> Why should the backed up values of a, say, 7 ply full width
> alpha-beta
> minimax search be any better than the values my evaluation
> function gives
> me by simply evaluating the positions at ply 1. I can
> understand that if
> the end of the game is in sight then lookahead is useful. I can
> understand  that if I use a quiesence measure or some such and only
> evaluate positions when I know that my evaluation function
> will work best
> then lookahead is useful. But if neither of these is the case
> then does
> lookahead help. Is there some way in which the backing up of
> values and
> minimaxing somehow reduces the error in the evaluations.
>
> I really am seriously stuck with this one.
>
> Cheers
>
> David
>