关于本书Tensorflow5.2.1节中的问题

[guoxixi1982]

书中4.4.3节讲述了滑动平均技术。书中99页中用到这个技术时有一段代码如下：

感觉这段代码怪怪的，tf.control_dependecies这个是用来进行控制依赖的，本意应该是让 操作variables_averges_op开始执行时确保train_op这个操作已经执行完成。查了下control_dependecies的功能，感觉应该写成 with tf.control_dependencies([train_op]): sess.run(variables_averages_op)

才比较符合滑动平均的逻辑，对书中注释和代码中提到的tf.no_op和tf.group也感到很费解，能不能请老师给解释下啊，感觉滑动平均还是很重要的。

[perhapszzy]

其实control_dependecies和group的目的都是为了让这两个操作一起被运行，所以形式其实不是那么重要。

[guoxixi1982]

啊？怎么又是一起执行了啊，越看与糊涂了。

按照逻辑应该是先执行train_op，确保变量被BP算法更新后，再来执行variables_averges_op才对啊。

是不是我对tf.control_dependecies（）本身的功能理解有误啊，比如 写成tf.control_dependecies（a, b, c），是不是说先a 执行完毕，才能执行b, b执行完才行执行c ? 这么写就是指定了abc的执行顺序？

如果不用tf.control_dependecies来约束，那a，b, c三者就可以同时执行了，我的理解对吗？

[perhapszzy]

一起执行这里我指的是“都会被运行”，而不是时间上一起运行。严格来说应该是先运行优化train_step，再运行活动平均才能保证滑动平均计算的准确性。但因为我们会运行非常多轮迭代，所以对于这样的顺序要求也就不严格了。

[guoxixi1982]

看了您的回复我更加糊涂了

[nowgood]

我是这样理解的，如果不对还请指教。 tf.group(a, b) 和 tf.control_dependecies(a, b) 在 a, b 之间没有依赖关系的话， 不保证 a，b 的执行顺序。但如果 a, b之间已经有了依赖关系，那么 a，b的执行顺序是确定的，下面通过下程序说明

# A, B没有依赖关系
import tensorflow as tf
x = tf.Variable(1)
A = tf.assign(x, 1)
B = tf.assign(x, 2)
group = tf.group(A, B)
with tf.Session().as_default():
    tf.global_variables_initializer().run()
    group.run()
    print(x.eval())
# 运行几次，输出结果是变化的

# A 与 B 存在依赖关系
import tensorflow as tf
x = tf.Variable(1)
A = tf.assign(x, 1)
B = tf.assign(A, 2)
group = tf.group(A, B)
with tf.Session().as_default():
    tf.global_variables_initializer().run()
    group.run()
    print(x.eval())
# 运行几次，输出不变

交叉熵中使用的 average_y = inference(x, variable_averages, weights1, biases1, weights2, biases2)中包含 variable_averages， 所以 train_step 依赖于 variables_averges_op, 所以variables_averges_op自会先执行， train_step后执行。

一般思考方式为 应该是先执行train_op，确保变量被BP算法更新后，再来执行variables_averges_op；也可以解释为在下一次前向传播之前要先对系数进行滑动平均：）

[nowgood]

@guoxixi1982

[caicloud-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[caicloud-bot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten /remove-lifecycle stale

[caicloud-bot]

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

/close