On Thu, Jun 16, 2011 at 2:24 PM, Matthew Woodcraft <[email protected]>wrote:
> Don Dailey wrote: > > There is some truth in that. It's possible that Zen is tuned up to play > > really well at this time control but did one or more things that also > make > > it not possible to play much better no matter how much extra time it has. > > But that seems like a real stretch to me. > > I think you should not find a situation like that at all surprising. > > For example, in the 'scalability' study organised by Don Dailey, it > turned out that the normal build of Mogo 'flattened out' well within the > range of the study, but that recompiling it to use double-precision > floating point numbers let it scale further. > In general I am assuming that the program is correctly implemented. I am also assuming that "scalability" by definition means more CPU power and enough memory to drive it. If your MCTS program is playing tricks to age out nodes not used much then of course it's not really a proper scalability test. That was happening with Mogo in that test. But yes, it's easy to make a program not scale. When I talk about this type of thing I'm almost always speaking theoretically - I'm assuming the implementation is not seriously flawed in such a way as to artificially prevent scalability whether intended or not. Zen could be seriously screwed up in this regard, I have no idea. The concept I'm trying to refute isn't whether some particular program is not scaling but the concept that "MCTS don't scale", as if the whole concept is seriously broken. That was directly implied by the comment someone made that we are at the "converge point" of the "scaling law" where more thinking time benefits little. That could be true for any given program, but it's pure nonsense when presented as if it represents the state of where we at now. Reports of the death of MCTS have been greatly exaggerated :-) Don > > There are many opportunities in a Go program for similar effects to > appear. > > > (NB, the question isn't whether that build of Zen plays no better 'no > matter how much extra time it has', but whether it plays no better given > a small number of time doublings.) > > -M- > _______________________________________________ > 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
