Adjusting the winrate to 50% is unsound. Especially in handicap games
when the bot takes black.
Intuitively it means going "head to head" with a stronger opponent,
which is not the most promising course of action.
The main reason to adjust the komi is to give the bot some criteria of
success when "objectively" every move is a win or every move is a loss.
"Sacrificing" winrate is actually not very good in any case. But if a
komi burden can be placed on the bot without a significant drop of the
winrate that actually represents an added layer of safety.
Stefan
Am 14.09.2010 13:03, schrieb Willemien:
If you use "whole number" komi and your program treads draws at 1/2
wins 1/2 losses (or what is maybe easier a draw and a loss, and treat
wins as 2 wins and losses as 2 losses )
then the winrate at the right komi should be 50%
so if the real winrate is far below (-25%) or above (75% +) this you
need to adjust the komi
The problem is that your program needs to do something with draws.
(and the normal UCB formulas don't work)
On Tue, Sep 14, 2010 at 10:28 AM, Stefan Kaitschick
<[email protected] <mailto:[email protected]>>
wrote:
The usual way to use the opponents time, if it is used at all, is
to guess the opponents move, and do a normal search on that
presumption.
If the guess was correct, then the search results can be used,
otherwise they are thrown away.
This is probably the most reasonable way, but ofcourse the
effectiveness is not so great.
Getting back to the the dreaded topic of dynamic komi, I would
like to suggest an alternate way of using this time:
Do a normal move search at several different komi levels, each
with a fraction of the normal number of positions.
It's not about finding the best move, only about estimating the
winrate at different komi levels.
This komi vs winrate profile could then be used to determine komi
for the next search.
Basically adjust the komi to the largest value that avoids a
significant drop from the winrate at regular komi.
The standard approach probably goes for a certain winrate that
must be maintained, but that way it's impossible to say how much
additional risk is actually beeing taken.
Stefan
_______________________________________________
Computer-go mailing list
[email protected] <mailto:[email protected]>
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
