Hi all.
I'm running a TF model that is not based on Inception and the new r0.12 is breaking it also. I should note that this model worked perfectly with r0.11.
I'm referencing issue #761 which seems to have the same error message.
Using git hash #7c16e2e and built using Bazel this afternoon (bazel build -c opt //tensorflow/tools/pip_package:build_pip_package)
Here is the error log:
TypeError Traceback (most recent call last)
<ipython-input-13-c788373b2a77> in <module>()
27
28 # Split data because rnn cell needs a list of inputs for the RNN inner loop
---> 29 Xnew = tf.split(0, n_steps, Xnew)
30 # new shape: n_steps * (batch_size, n_hidden)
31
/Users/kevin/anaconda2/lib/python2.7/site-packages/tensorflow/python/ops/array_ops.pyc in split(value, num_or_size_splits, axis, num, name)
1220 if isinstance(num_or_size_splits, six.integer_types):
1221 return gen_array_ops._split(
-> 1222 split_dim=axis, num_split=num_or_size_splits, value=value, name=name)
1223 else:
1224 size_splits = ops.convert_to_tensor(num_or_size_splits)
/Users/kevin/anaconda2/lib/python2.7/site-packages/tensorflow/python/ops/gen_array_ops.pyc in _split(split_dim, value, num_split, name)
3424 """
3425 result = _op_def_lib.apply_op("Split", split_dim=split_dim, value=value,
-> 3426 num_split=num_split, name=name)
3427 return result
3428
/Users/kevin/anaconda2/lib/python2.7/site-packages/tensorflow/python/framework/op_def_library.pyc in apply_op(self, op_type_name, name, **keywords)
507 if input_arg.type != types_pb2.DT_INVALID:
508 raise TypeError("%s expected type of %s." %
--> 509 (prefix, dtypes.as_dtype(input_arg.type).name))
510 else:
511 # Update the maps with the default, if needed.
TypeError: Input 'split_dim' of 'Split' Op has type float32 that does not match expected type of int32.
Not that I understand this code all that well, but I can't help but think that someone swapped the order of the parameters for the split method in line 1174 of array_ops.py.
The documentation clearly indicates the calling order for tf.split should be:
tf.split(split_dim, num_split, value, name='split')
But the actual code indicates:
def split(value, num_or_size_splits, axis=0, num=None, name="split"):
And when I correct the order of parameters to match the documentation, it seems to work better.
Apologies for the instability, there is some churn happening in the API in preparation for the 1.0 release keeping with our intention to follow semantic versioning. As a result, there are currently breaking changes between 0.11 and 0.12 (and will be more for the next release).
See RELEASE.md for a list of changes being made, for example, the change in argument ordering for tf.split, which will not match NumPy.
You might also find the conversion tool at https://github.com/tensorflow/tensorflow/tree/master/tensorflow/tools/compatibility useful to help navigate these API changes.
Hope that helps! Closing this issue out, let us know if your concerns weren't addressed.
I am using Tensorflow 1.5.0rc0 and I still have this issue
I have the same issue. and address the problem by changing the parameter position:
i, j, f, o = tf.split(hidden, 4, axis=1)
Most helpful comment
Not that I understand this code all that well, but I can't help but think that someone swapped the order of the parameters for the split method in line 1174 of array_ops.py.
The documentation clearly indicates the calling order for tf.split should be:
But the actual code indicates:
And when I correct the order of parameters to match the documentation, it seems to work better.