>> You probably don't understand how UCT works. UCT balances exploration >> with exploitation. The UCT tree WILL explore B1, but will explore it >> with low frequency. That is unless the tree actually throws out 1 >> point eye moves (in which case it is not properly scalable and broken in >> some sense.) >> > > > It was my understanding that most UCT programs would not consider b1, since > they use the same move-generation for the MC playouts as for the UCT tree, > and that forbids filling your own eyes. "Broken in some sense", as you say, > although probably playing a bit stronger for it. > > If the move is considered at all, I have no problems believing that UCT will > eventually find it. That much I understand of UCT. > > Sorry if I confused practical implementations and the abstract. As to > publishing my findings, I need to make some real ones first, and then be sure > of them. I have some ideas I am pursuing, but things go slowly when I only > have some of my spare time for this project. When I do, it may be on a web > page, or maybe just on this list - I am not in the game to publish academic > papers. More to learn things myself, and if possible to add my small > contribution to a field I find interesting. > > I suspect that many UCT programs do actually prune some moves in the tree such as 1 point eyes, but that of course depends on the implementation details for each program. My own program does this simply because it seems pragmatic to do at practical playing levels and I fully understand that I give up scalability at the higher levels. Of course I assume that the levels I would benefit from are too high to be practical. I could very well be mistaken about this and it's a possible explanation for why FatMan peaked out in the study (latest results show that it's still improving but very slowly.) I will have to say I was lazy and didn't test this. Of course the eye rule or something like it must be applied in the play-outs, but in the tree to be "fully" scalable you must not prune permanently.
I think most of us are interested in producing the strongest practical playing program so it's very easy to confuse, as you say, the practical from the abstract. I think what will eventually happen is that as programs improve, the weakness we observe will get corrected. There is no law that forbids us from fixing issues such as slow recognition of relatively basic nakade positions and of course I simply make the point that in a truly scalable program you are guaranteed a general strength increase as you go deeper, including handling of these kinds of positions. Every problem eventually goes away but I make no claim that it will happen as fast as we wish it would. I remind everyone that even in chess, it's possible to find or construct positions that make programs look like fools, but it's another thing entirely to be able to beat these programs. Should someone find some clever solution to the nakade problem, it's no guarantee that it will actually make the program stronger, as someone recently pointed out. As Gian-Carlo pointed out, what seems like a serious failing to us may not represent a serious failing in some idealistic sense (it may not have the impact on play WE think it should be.) I can say that I have known chess players that were stronger than myself who were totally deficient in areas of play that astounded me, yet they could get results. So what we think is important, again as Gian-Carlo points out, may not matter as much as we think. The Chess programs of a few years ago were remarkable examples of that - they were incredibly naive and laughable at one point in the early days and from our twisted point of view it was unbelievable because they were playing a few hundred ELO higher than you would expect. - Don > - Heikki > > > _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
