Some probable causes:
1) UCT converges with exploration term 0 for binary-valued spaces, but not ternary. 2) Modeling jigo as 50% wins is not a valid model of a ternary-valued space. 3) Search is bounded by memory, so interesting alternatives are pruned. From: [email protected] [mailto:[email protected]] On Behalf Of René van de Veerdonk Sent: Thursday, March 31, 2011 12:45 PM To: [email protected] Subject: Re: [Computer-go] 7.0 Komi and weird deep search result 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, <[email protected]> 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 [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
