Inconsistent Naming with different input shapes

[ppwwyyxx]

Install from binary pip package

1. Which pip package you installed. CPU only for Linux
2. The output from python -c "import tensorflow; print(tensorflow.version)": 0.7.0

Steps to reproduce

Run the following code:

import tensorflow as tf

a = tf.placeholder(tf.float32, name='haha', shape=[128, 20, 20, 20])
c = tf.nn.moments(a, axes=[0])[0]
print c.name

with tf.Graph().as_default():
    a = tf.placeholder(tf.float32, name='haha', shape=[None, 20, 20, 20])
    c = tf.nn.moments(a, axes=[0])[0]
    print c.name

It prints:

moments/Squeeze:0
moments/Squeeze_1:0

In short, with different input shapes, the op returns a variable with different names.
I'm not sure whether this is expected to happen, or something to be fixed. IMHO, this could cause some problems because one may use a fixed batch size for training, and a None batch size for inference. Getting a different name make it harder to manage variable load & restore.

[vrv]

The reason is that moments produces a slightly different graph when the input shape is known (it can be pre-computed). When it's unknown, the code introduces a "squeeze" operator that isn't normally there, in the same op scope as the final mean, so there's a name collision and we increment by 1.

@vincentvanhoucke: can we/ should we make moments() return a consistent name for the returned tuples?

[vincentvanhoucke]

These are the names of the ops, not the variables, so it won't be an issue for save and restore.
We should try to provide stable names for endpoints of composite ops though, that seems sane, even if users should definitely not rely on that naming to be stable over time. I'm working on updates to moments() for v0.8, I'll put that on my list of requirements.

[ppwwyyxx]

I agree that usually ops won't be an issue for save and restore. But what happen to me is that I'm using ExponentialMovingAverage on c, then there will be a variable that inherit the inconsistent name from c, and then cause problems for save/restore.
BTW, this is how the non-official batch normalization mentioned in #1122 works (take moving average on mean/var).

[vincentvanhoucke]

A fix for this has been checked in and should make its way to github shortly.

[oanoelsis]

is it fixed now? I have a same problem about tf.saver.restore() with different batch size train time and inference time. and i want to know this is the reason or not.