为了实现UCT算法,需要在内存中构建一棵博弈树,http://www.win7xz.com/,博弈树的每个节点是博弈过程中的一个局面。
一个显而易见的方法是――构建树形的数据结构,每个节点保存3类信息:1)该节点所代表的局面。2)局面信息(当前收益值与被尝试次数)。3)子节点的索引。
出于以下两个考虑,我并没有用这个方法。
1)尽可能地减少内存占用。
2)细究之,围棋博弈过程中产生的拓扑结构并非树,而是图――不同分支下的局面亦可能重合,尽管这种菱形重合的频率是很小的。
我用了一个哈希表来保存必要的信息,而只在逻辑上存在树形(包含少量的菱形重合)的数据结构,xp系统下载。哈希表的表项保存两类信息:1)哈希值。2)局面信息。由于采用的哈希算法重合率极低,我假定不同局面的哈希值是不会重合的――即使有重合,番茄花园xp系统下载,在UCT这样的概率算法中亦无伤大雅。在这个哈希表中,哈希值不但是局面的索引信息,而且是局面的唯一标记。
两种方法优劣不明。
这里贴一下前文中所述的UCT算法:
1) 从博弈树的根点开始向下搜索,执行2)。
2)遇到节点a后,若a存在从未评估过的子节点,执行3),否则执行4)。
3)
通过MonteCarlo方法评估该子节点,得到收益值后更新该子节点至根节点路径上所有节点的平均收益值,执行1)。
4) 计算每个子节点的UCB值,雨林木风xp系统下载,将UCB值最高的子节点作为节点a,执行2)。
5) 算法可随时终止,通常达到给定时间或尝试次数后终止。
根节点下平均收益值最高的子节点作为算法的输出。
在步骤2)中,也就是要判断子节点存不存在于哈希表中。在步骤3)和4)中,则需要更新哈希表中的局面信息。
最后提一下我采用的哈希算法――zobrist
hashing,这个真是哈希棋类游戏局面的利器啊,维基百科zobrist hashing词条:。