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" <[email protected]> > To: [email protected] > Subject: [Computer-go] Anomalies in MCTS > Message-ID: <[email protected]> > 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. _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
