>> * Collect a set of problem positions where the current strongest >> programs mess up. >> * Use each of these as the start position, instead of an empty board, >> in your scaling study. >> >> (In other words, don't let the programs play the style of game they want >> to play, but force them to start outside their comfort zone. >> >> If Hideki is right, you should see very little improvement for each >> doubling. > > Darrent, at least one program that can correctly manage those positions > is requred for your plan, isn't it?
Maybe; I was hoping forcing them to start when the problem position is already on the board would be enough. But even a weaker traditional style program may be helpful? In my sm9 team experiments I introduced GnuGo as a team member. It doesn't suggest moves, but it has to agree with the MCTS programs before a node can be considered a terminal node. Situations where GnuGo disagrees with all the stronger MCTS programs are common, and the subset of those where GnuGo is correct are rare. But it does happen sometimes. Darren >> This has its own bias: the selection of problems. However, it could make >> for an interesting and educational grudge match: >> In the red corner, those who agree that scaling won't get you much >> further, hunt for some really great problem positions. >> In the blue corner, those who disagree, scrounge even more CPU power to >> see if just one more doubling will give a breakthrough. -- Darren Cook, Software Researcher/Developer http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
