Now I don't feel so bad -- my UCT prog also sucks ass, only slower.
On 4/13/07, Darren Cook <[EMAIL PROTECTED]> wrote:
>> I've been trying the libego program "out of the box", and am up to >> 200,000 UCT playouts, but still gnugo 3.6 on level 6 is winning 10 out >> of 10. ... > > If 200,000 play-outs is being beat, something is broken. Even > a bad implementation should do better than that. > > Does libego provide a full UCT implementation out of the box? Thanks for the reply Don. I've just reviewed the code again and it seems to be the same algorithm as described at http://senseis.xmp.net/?UCT The way it is implemented differs from the pseudo-code in a few minor ways, but notably: it (libego) maintains a float win-rate for the node, which is updated, rather than storing wins and recalculating win-rate each time. I suppose there could be a rounding error creeping in there. I've tried changing it to use two ints, for total visits and black wins, and then calculate the winning rate on the fly. But it still cannot win a game against gnugo on level 6: it lost 9 out of 9 at 100K playouts, and has lost 4 out of 4 at 500K playouts. Yet there is no major bug: when I played it a game at each of 100K and 500K it played reasonable go, and I could notice that 500K was stronger. Has anyone else tried studying or using libego's UCT implementation? Is there another open source implementation of UCT I can compare against? > One thing that I think most people are doing is related to how you > select a move once you have finished the search. Do you pick the > highest scoring move? ... No, currently it chooses the most visited node, ignoring score. Darren _______________________________________________ computer-go mailing list [EMAIL PROTECTED] http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________ computer-go mailing list [EMAIL PROTECTED] http://www.computer-go.org/mailman/listinfo/computer-go/
