[computer-go] Floating komi

[Hideki Kato]

Don Dailey: <47CE9E73.5080100 at cox.net>:
>
>
>Hideki Kato wrote:
>> I'd like to give here an example to make things clear.
>>
>> The conditions are:
>> 1) Using digitizing scheme that maps real score to [0,1] (or [-1,1]) 
>> so that the program cannot distinguish losing/winning by 0.5 or 10.5 
>> pt at all.
>> 2) Playouts include some foolish moves (usually with low 
>> but not zero probability), not to connect large groups in atari 
>> position for example, due to hold its randomness.
>> 3) The position is at early endgame where there are no moves that 
>> gain greater than 2 pt, for example, in perfect play.
>> 4) Black is behind by 0.5 pt.
>>
>> The playouts may return winning but gambling move (perhaps with low 
>> probability) under above conditions, especialy in case of the number 
>> of playouts is small which is usually true on 19x19, and UCT will 
>> choose it.
>>
>> The question is, which is better to keep 0.5 pt behind or to play 
>> gambling moves (here I mean such moves that B will lose many pts if W 
>> will answer correctly) with expecting W's (stupid) mistakes?
>>
>>   
>The assumption is that you suddenly cannot trust MC to do what it does
>best even though you did for the entire game up until this point.   MC
>of course will choose the "gambling" move.      The whole concept of MC
>is to do what is most likely to produce a win.      
>
>We should think twice before asking it to choose the moves that produces
>the more sure loss.    We are the ones that have a bias about this, not
>the MC programs.  

Whatever the 'concept' of MC is, I just will improve its weakness by 
any means.  MC is just a method, IMHO, to evaluate a position better 
than to use a static function.  # I'm just an engineer :).

>> In addition to above, there is one more issue to consider. If the 
>> playout has a systematic error, nakade for example, it's not good to 
>> keep 0.5 pt ahead.  Having more margin is clearly better.
>>   
>I believe nakade is a strawman.    There are lots of things MC does
>better and lot's of things it does less well.    You can always find
>positions that are hard or easy for your program to solve, but it isn't
>intrinsic to this issue.     I don't think you should weaken this
>concept of playing for the best winning chances for the very few
>positions where MC programs take longer to resolve the endgame and there
>is a slight chance that it will win if it just happens to be enough to
>cover the exact situation.   Because this is no solution - it is at best
>a patch and would only work in some cases.   If I could do something
>that didn't hurt the program in other ways, but might help certain
>positions once in a while,  I would go for it.     I've been in game
>programming a long time - if you have a problem with certain types of
>positions you really want a pointed solution that has little or no
>impact on other positions.   You don't want to be going back and forth
>fixing things up but you want to solve the problem as correctly as
>possible the first time.       I'll call this principle, "every solution
>has a side effect" but this is a pretty bad side effect.    (I can't
>tell you how many times I "fixed" something in my chess program with
>some evaluation change only to find that I broke many other things at
>the same time.)

Although I'm afraid my English skill is enough to understand such a 
long paragraph correctly (shorter is better :), I believe it's just a 
choice.  Some are good at developing an essential solution but not 
all.  As I know I'm worse at that, I just do what I can.

It was developped for the First UEC Cup that features 
Japanese rules which count seki differently so that all MC programs 
need to have some margin.  Rémi introduced a fixed margin by changing 
komi for Crazy Stone and I've developed a dynamic one.  Do you 
say we have to wait until we will develop an essential solution?

-Hideki

>- Don
>
>
>
>> The idea of floating komi helps above two.  I'd like to emphasize that 
>> I know it's not a universal solution.  As it seems, however, very hard 
>> to solve nakade problem, it could be a pracitical solution.
>>
>> -Hideki
>> --
>> gg at nue.ci.i.u-tokyo.ac.jp (Kato)
>> _______________________________________________
>> 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/
--
gg at nue.ci.i.u-tokyo.ac.jp (Kato)