[computer-go] Congratulations to AyaMC, GNU, and MonteGNU!

[Joel Veness]

Hi Don,

That is an interesting idea, and I don't see anything wrong with it in
principle.

However, given how slow Goanna is these days, I think I would probably
gain more by spending 1/10 of the time needed for that idea on simple
optimization! :)

Joel

On Tue, Feb 5, 2008 at 2:44 AM, Don Dailey <drdailey at cox.net> wrote:
>
>
>  Joel Veness wrote:
>  > Hi Nick,
>  >
>  > Goanna (agog) timed out annoyingly in that game against GNU.
>  >
>  > I have since implemented a rule: "if after some number of samples you
>  > have a winning probability that is very close to 1.0, just make the
>  > best move right away". There is no need to spend so long thinking in
>  > these ridiculous endgame positions. I made some other changes so that
>  > passing is more highly favored in certain situations, so hopefully
>  > this will be the last time Goanna forfeits a game due to time.
>  >
>  My rule is that if the score if over 0.95  or under -0.95  I allocate
>  some fraction of the time I normally would to that move.   I think my
>  fraction is 1/10.    I always play the move with the most samples,  but
>  for this I make sure than the highest scoring move (even with low
>  samples)  fit's this window.
>
>  I think technically these kinds of algorithms should be applied
>  gradually,  so some function could be applied to the score to determine
>  how soon to stop.    The function should not be linear but should be
>  such that very little reduction is applied unless the score is extremely
>  high or low.      For instance is the score is 80% you might benefit
>  from a slight reduction, but not much.
>
>  To find the right numbers, you would probably need to analyze a LOT of
>  data and see how often you lose (and why) when the score is fairly
>  high.   Probably not worth the effort!
>
>  This function should be fitted to your general time control algorithm
>  too.   If you have rules to shorten the search,  you should definitely
>  balance this by being more aggressive about time allocation earlier in
>  the game.      It would  probably be very difficult to find a good
>  balance but the right algorithms should cause you to lose some games and
>  win some games but to win more than you lose.     If your are too
>  conservative it might seem ok, but that causes you to lose games too,
>  you just don't notice it as much.
>
>  - Don
>
>
>
>
>
>
>
>  > I guess that is what I get from only testing on CGOS. The small time
>  > increment CGOS gives makes a big difference with the high latency I
>  > get due to being based in Sydney, and to the best of my knowledge, KGS
>  > doesn't do the same.
>  >
>  > Joel
>  >
>  > On Tue, Feb 5, 2008 at 1:32 AM, Nick Wedd <nick at maproom.co.uk> wrote:
>  >
>  >> Congratulations to the three winners of yesterday's KGS bot tournament
>  >>  (there was a tie in the Formal division, so three winners).  My report
>  >>  is at http://www.weddslist.com/kgs/past/35/index.html
>  >>
>  >>  Nick
>  >>  --
>  >>  Nick Wedd    nick at maproom.co.uk
>  >>  _______________________________________________
>  >>  computer-go mailing list
>  >>  computer-go at computer-go.org
>  >>  http://www.computer-go.org/mailman/listinfo/computer-go/
>  >>
>  >>
>  > _______________________________________________
>  > computer-go mailing list
>  > computer-go at computer-go.org
>  > http://www.computer-go.org/mailman/listinfo/computer-go/
>  >
>  >
>  _______________________________________________
>  computer-go mailing list
>  computer-go at computer-go.org
>  http://www.computer-go.org/mailman/listinfo/computer-go/
>