Hi Rémi and Aja, This paper is very interesting, thank you very much for sharing it with the list.
Shared articles like this are a great resource for hobby computer-go enthusiasts like myself, who don't have access to university libraries. I hope other authors will consider doing the same (and hopefully updating the excellent literature list on www.citeulike.org/group/5884/library). Okay, enough on this. Reading this paper got me thinking once more on what is useful board information to maintain incrementally versus recalculating every time you need it. In particular, the article mentions a two-liberty strategy to be used as a feature for move-selection. It is almost for free to detect and efficiently maintain atari information for every string and find the last liberty. That allows to implement the features 2-6 in the list. What is not completely clear to me is how to classify and detect cases where a capture also results in self-atari, but that is a corner case and perhaps not that important. It is less obvious to me how to efficiently detect when strings are down to two liberties, and how to implement feature 7. I know that some people maintain lists of liberties, which would also allow you to maintain a liberty count. But this is, relatively speaking, much more expensive than detecting/maintaining atari/last liberties. Are there more efficient incremental alternatives, or is this typically done "on demand"? Also for feature 7, the illustration in the paper labels the one liberty that actually kills the group, and not the other liberty that would result in an atari (but not kill the group). I am assuming this intentional. But, how does one chose between the two liberties efficiently? I mean, without actually playing it out (that is computationally expensive)? Or is playing it out just the most straightforward way? Thanks in advance for any insights, René
_______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
