[Computer-go] 7.0 Komi and weird deep search result

valkyria at phmp.se valkyria at phmp.se
Fri Apr 1 01:28:45 PDT 2011


Quoting Michael Williams <michaelwilliams75 at gmail.com>:

> I wonder what would happen if you counted jigo as a loss for both players...

Interesting, it would then avoid all lines that are likely to lead to  
a draw. The problem is that it then not be able to see any difference  
between a jigo and a loss which may be a problem in a position which  
is a clear jigo. What happens deeper in the tree does not matter, if  
there is only a few jigo candidate moves and many losing moves, the  
program will often pick a losing move.

So I think jigo must be evaluated at least better than losing perhaps  
something like 25% or so. But then I need to program some more because  
it would change how I update the tree, and that part of the program is  
quite messy with all the AMAF updating and so on.

The question is: should jigo be counted balanced for both players or  
should one perhaps bias the randomized winner for jigo playout. For  
example if the program is winning 60% at root then jigo would count as  
win in only 40% of the cases for the color of program in the playouts.  
This would perhaps drive the program more towards winning lines when  
it wins and towards jigo when it loses.

Magnus




>
>
>
> On Thu, Mar 31, 2011 at 6:33 PM, Willemien <wilemien at gmail.com> wrote:
>
>> instead of randomsing a jigo maybe it is an idea to count all outcomes
>> double
>>
>> - count a win as 2 W
>> - count a loss as 2 L
>> this gives the option to
>> - count a jigo as 1 W  and 1 L
>>
>>
>>
>> On Thu, Mar 31, 2011 at 6:06 PM,  <valkyria at phmp.se> wrote:
>> > I used to have "solved"-flags in the tree, but the implementation was so
>> > messy and caused bugs in interactions with other messy stuff so I removed
>> it
>> > and was happy.
>> >
>> > I guess introducing some other kind of exploration might be better. Or
>> maybe
>> > value jigo as just a little better than losing rather than as 50% but
>> then
>> > my simple solution currently is not good enough I would have to change
>> > datatypes and rewrite a lot.
>> >
>> > -Magnus
>> >
>> > Quoting René van de Veerdonk <rene.vandeveerdonk at gmail.com>:
>> >
>> >> Magnus,
>> >>
>> >> If you reach a final node, you can mark it as "solved", and never
>> explored
>> >> it again. Shouldn't that solve your symptoms? It appears from your
>> >> description that you do not have such a feature in your tree-search.
>> >>
>> >> René
>> >>
>> >> On Thu, Mar 31, 2011 at 8:42 AM, <valkyria at phmp.se> wrote:
>> >>
>> >>> I did not want to spend a lot of time changing Valkyria completely for
>> >>> integer komi so I made a very simple hack to cope with the fact that I
>> am
>> >>> using integers and booleans for all computations of wins/losses in
>> >>> Valkyria.
>> >>> The hack is that every time a jigo occurs in a playout I randomize
>> which
>> >>> player should win which means the change is very minor to the program.
>> >>> Thus
>> >>> I d not to model jigo more than in a statiscal sense.
>> >>>
>> >>> I am doing some very deep searches to see what could be good moves for
>> >>> the
>> >>> most important lines in the opening book. I am using the 7.5 komi book
>> >>> because it is the most developed, but it may be that a 5.5 book is
>> better
>> >>> if
>> >>> black is favored by 7.0 komi.
>> >>>
>> >>> Anyway I just looked at a deep search spending 10hours of search, where
>> >>> old
>> >>> branches of the tree is cut off every time the program runs out of
>> >>> memory.
>> >>> (Which may also be a part of the problem). It turned out that search
>> >>> stuck
>> >>> to a PV and played to the end over and over again with considering
>> other
>> >>> alternatives. Valkyria uses exploration = 0. The game it played over
>> and
>> >>> over was 80 ply deep thanks to a small kofight and all move looks
>> >>> reasonable
>> >>> although sometimes some moves look a little odd. It does search
>> >>> alternatives
>> >>> a little bit in each position but it seems to quickly lock onto
>> something
>> >>> giving 50% for sure.
>> >>>
>> >>> My question: Is this normal? Without Jigo this would not be possible
>> >>> because a deep variation to the absolute end of the game would be a
>> clear
>> >>> loss for one side and then as the score goes down to 0 the search will
>> >>> explore many alternatives.
>> >>>
>> >>> Could it be that playing alternative moves in this search were all too
>> >>> risky so that search converges on a very long but guaranteed risk free
>> >>> jigo?
>> >>>
>> >>> I see this as a problem because if this happens a lot the program seems
>> >>> not
>> >>> really to search all options probably. It could be that my program has
>> a
>> >>> bug
>> >>> or twoo that causes this problem, so therefor I am curious if anyone
>> >>> could
>> >>> reflect on it or have some experience.
>> >>>
>> >>> I believe chess programs uses something call "contempt" to avoid
>> drawing
>> >>> too much (I think espeically against weaker opponents).
>> >>>
>> >>> Best
>> >>> Magnus
>> >>> _______________________________________________
>> >>> Computer-go mailing list
>> >>> Computer-go at dvandva.org
>> >>> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>> >>>
>> >>
>> >
>> >
>> > _______________________________________________
>> > Computer-go mailing list
>> > Computer-go at dvandva.org
>> > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>> >
>> _______________________________________________
>> Computer-go mailing list
>> Computer-go at dvandva.org
>> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>>
>





More information about the Computer-go mailing list