[Computer-go] Anomalies in MCTS

Cameron Browne cameron.browne at btinternet.com
Mon Feb 4 04:30:02 PST 2013


Hi Ingo,

You might try some of the RAVE counter-examples, such as the following position from Martin Mueller (White to move):
http://www.cameronius.com/research/go-rave-blunder-1.pdf 

It's a seki position in which FUEGO chooses the correct move B2 without RAVE, but the incorrect move D9 with RAVE enabled.

Not sure whether this will translate to the bizarre MC behaviour that you're looking for, but it's worth a shot. As I understand it, RAVE fails here because the key move wins if played immediately but loses in most cases if played further down the line, hence the accumulated RAVE values initially disguise the actual first-move value. Perhaps you might see a similar effect related to the number of MC runs, i.e. additional (wrong) information hides the correct value? 

Regards,
Cameron 


> Date: Mon, 04 Feb 2013 10:51:11 +0100
> From: "Ingo Alth?fer" <3-Hirn-Verlag at gmx.de>
> To: computer-go at dvandva.org
> Subject: [Computer-go] Anomalies in MCTS
> Message-ID: <20130204095111.108540 at gmx.net>
> Content-Type: text/plain; charset="utf-8"
> 
> Hello,
> 
> Wesley Turner and me are analysing "pure Monte Carlo" (without
> tree search component) in (artificial) simple games.  Let MC(k) be 
> the version where each candidate move gets exactly k simulations. We 
> found examples where for instance MC(8) performs better than MC(16), 
> but for k to infinity pure Monte Carlo plays perfectly.
> 
> Question to the MCTS programmers (in Go): Do you have example
> positions where MCTS makes good move proposals for short run times
> and bad proposals for medium long run times? (Of course for time to
> infinity it should converge to good moves.)
> 
> Cheers, Ingo.




More information about the Computer-go mailing list