Hi!
I forgot two important points:
On Thu, Feb 11, 2010 at 01:06:34PM +0100, Petr Baudis wrote:
> > On the other hand, 9 handicaps are supposedly giving an advantage of 90 to
> > 120 points, so my natural thought would be that the bot would give itself at
> > least a negative komi of that many points ?
> >
> > I can't figure out well how komi is determined at first move.
>
> extra_komi = 7.5 * handicap_stones_count
>
> Then it is linearly decreased until it hits 0 at move 200.
The amount of extra komi applied is determined at the tree leaf where
it is applied. That is, it's 1 - current_move_number / 200 in tree root, but
deeper in the tree, it's 1 - (current_move_number + node_depth) / 200.
This ensures some kind of sanity especially when reusing older trees,
the values have well defined characteristics.
> This is the most naive implementation. In practice, neither extra_komi
> determination nor its application throughout the game should be linear,
> probably. There is a lot of experiments to be done. :-)
>
> > In relation with the previous question, I'm wondering how komi is determined
> > and what its value is for every handicap game ( as black and as white). Is
> > there a specific value for each ( before first move is played) or is it only
> > determined by the way it was programmed and the programmer's preferences ?
Dynamic komi is used only in games where the program is black. I have
found that it does not work well at all when the program is white, it
played too slow moves, then found itself hopelessly behind when it was
too late to do anything about it. But I also think UCT without dynamic
komi plays a lot worse as black than white in high handicap games, so
the problem to solve is not as big (if indeed any).
--
Petr "Pasky" Baudis
A great many people think they are thinking when they are merely
rearranging their prejudices. -- William James
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
