Junxiao Song

@biasbb 训练的时候一个batch就是采样一个batch_size的数据并更新模型，在现在代码里的默认参数下和已经进行的对局次数是一样的。后面那个问题的回答也是肯定的。

我电脑 i5-4590, GPU: GTX750, 我自己的实验都是基于最开始的Theano的版本跑的，tensorflow的版本只简单跑了下确认逻辑的正确性，在性能方面也没有经验。 PS：如果有什么改进性能方面的发现和建议，欢迎反馈~

时间主要集中在get_move_probs这一步是合理的，因为调用一次就会执行400次MCTS playout。可能还得进一步深入才能看到有没有什么可以优化的地方。

关于GPU不比CPU快这个问题，我觉得可能有两个方面的原因： 1、AlphaZero训练本身就有很大一部分运算是需要在cpu上进行的，频繁的在cpu和gpu之间交换数据本身也会有一定开销。 2、我们跑的棋盘很小，而且我用的网络本身也很浅，所以网络forward计算这部分运算放到GPU上带来的收益可能都被额外的数据传输开销抵掉了。 如果棋盘大一些（但相比于一般的图像其实还是很小的），同时用比较深的网络的话，那时候用GPU可能才能发挥更大的作用。

代码里其实也是算的平均值，只是用了增量计算的形式，如果你展开的话，会发现计算公式如下： Q = ((n-1)*Q_old + leaf_value)/n

这个c_puct是用来控制MCTS探索与利用的平衡的，我不是很确定合法动作数量减少之后是否有必要调整它，因为根据AlphaZero论文的话，在应对3种合法动作数量差异很大的棋类时也没有调整这个参数。但是如果要调整的话，我的建议是可以适当减小试试，因为目前的取值5对c_puct这个参数而言是相对比较大的一个设置

You can change the board size, i.e., self.board_width and self.board_height, in the file train.py. But for large board size, say 15 or 19, the computation burden is not affordable for...

你说的应该是下面这一句吧，这边用exp是因为self.action_fc本身是log之后的probability self.entropy = tf.negative(tf.reduce_mean(tf.reduce_sum(tf.exp(self.action_fc) * self.action_fc, 1)))

并行化应该是能够加速的，在issue #13 里有同学提到 “用了一个进程负责 self-play 和 training的部分, 另外4个进程只负责self-play的部分”，供参考；另外要实现MCTS并行加速的话可能需要用到virtual loss的trick，论文里有描述；另外issue #35 里的同学在尝试并行化，没准你们可以交流

你可以把模型参数提取出来，一般是numpy array的list，或者是dict，具体的方式可能需要根据你具体使用的框架对应查一下，然后你就可以随意操作这些参数啊