no problem. :)
just run the following algorithm:
i) get MC "estimates" for each move.
ii) partition the list into "good looking moves"
and "bad looking moves" based upon the
estimated probability of earning a win.
iii) compare the top move pairwise with the rest
of the "good looking moves" to see if it
satisfies a student t-test at some reasonable
value. if it does, play it.
iv) drop anything from the bottom move list that
satisfies a t-test as being worse than all of
the moves from the "top move" list.
repeat i)-iv) until you play a move.
s.
--- Brian Slesinsky <[EMAIL PROTECTED]> wrote:
> On 3/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> wrote:
> >
> > The problem in Computer Go is the search of the
> best move that can be found.
> >
> > First, Since a computer prgram, or a player cannot
> consider every possible
> > moves, they usually has a move selecting function
> which select a sub set of
> > the all possible moves. The moves for
> consideration selected by a computer
> > program, by a player, or by a pro player may not
> contain the true best move.
>
> A computer can consider every possible next move at
> the first ply, so
> that would include the best move. I assume you mean
> that only a
> subset of the full move tree can be visited, and a
> sequence of moves
> that justifies the best move may not be visited, so
> it may not be
> recognized.
>
> But to pick the best move, it's "only" necessary to
> recognize the
> weaknesses in all the other moves. In many cases
> these weaknesses can
> be recognized using move sequences that are far less
> than perfect
> play. The tricky part seems to be sequences can
> only be evaluated
> with perfect play for many moves such as ladders.
> It's unclear how
> often such perfection is required to pick the best
> move.
>
> > Thus, one starts with an imperfect subset of moves
> and an imperfect
> > evaluation function and feed them to a search
> algorithm (alpha-beta, for
> > example). In general, the higher are the merit
> probabilities, the more
> > effective is the search.
>
> With UTC, if I understand correctly, it would
> eventually try every
> possible sequence, but of course not within the time
> limit, so it
> isn't clear that it starts with an "imperfect subset
> of moves" that is
> separate from the other factors.
>
> > Postulation: For a given function merit
> probability and a given evaluation
> > merit probability the move merit probability
> function approaches a constant
> > value for large enough search scope.
> >
> > That is beyond certain value of the search scope,
> the move merit
> > probabability function won't improve anymore.
>
> I think what you're saying is that it should be
> possible to derive a
> formula for when a search should stop so that the
> program can save
> time for future moves?
>
> - Brian
> _______________________________________________
> computer-go mailing list
> [email protected]
>
http://www.computer-go.org/mailman/listinfo/computer-go/
>
____________________________________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
