aboutsummaryrefslogtreecommitdiffhomepage
path: root/tensorflow/cc/client
diff options
context:
space:
mode:
authorGravatar Vijay Vasudevan <vrv@google.com>2017-04-10 15:29:15 -0800
committerGravatar TensorFlower Gardener <gardener@tensorflow.org>2017-04-10 16:50:29 -0700
commit24a95ae389e1c76e771ac33d66e0ec40a236260f (patch)
treeaf9c67c7a984af7bae38fa096457cc76e7a3fda3 /tensorflow/cc/client
parent31559fd5317abd10c457575a1718b88b3917446c (diff)
Change Placeholder to support partial shapes and enforce scalar shapes.
Adds tests; testScalar failed before with the original placeholder because it treated [] as "?" instead of scalar. Now you can actually specify [] and it means 'scalar'. Added a backwards compatibility test using a graph_def generated from a previous tf version. RELNOTES: tf.placeholder can represent scalar shapes and partially known shapes accurately. Note, this change can break already buggy programs because it makes placeholder shape handling more consistent across graph serializations. Note: There are some buggy cases where this change can break a buggy pipeline: namely those that serialize a graph using an unknown shape (e.g., [None, 10] in a tf.placeholder, but then reload the graph using import_graph_def and feed it a different shape. Prior to this change, serializing the graph_def loses the [None, 10] shape requirement, so you can feed anything you want. This change makes it so that you serialize the graph with [None, 10], and so when you reload it, it would fail if you fed it a different shape. In these cases, the fix is to correct the original placeholder shape to match what you feed it, which is not a bug in TF but in the user's program. Note 2: A python user that did tf.placeholder(shape=[]) would get scalar checking in the same process due to python shape inference code. However, a C++ user that did Placeholder(shape=[]) would not have gotten scalar shape checking; a C++ program that passed Placeholder(shape=[]) that expects to interpret this as "UnknownShape" would break -- however, that user could have already used an {unknown_shape: true} proto, and should not have expected the legacy behavior. Backwards compatibility: Old graphs that have shape = {} in the proto will also have a graph_def_version <= 21, so the default value of shape prior to this change will be interpreted by new binaries as "UnknownShape" just as before. Forwards compatibility: new graphs will produce, by default, shape={ unknown rank: true}; old binaries will use PartialTensorShape's parsing code to parse that proto into an object whose shape.dims() <= 0, and so these binaries will continue to interpret the default shape as "unknown shape" without crashing and without producing new errors. Fixes #9103 Change: 152751019
Diffstat (limited to 'tensorflow/cc/client')
-rw-r--r--tensorflow/cc/client/client_session_test.cc2
1 files changed, 1 insertions, 1 deletions
diff --git a/tensorflow/cc/client/client_session_test.cc b/tensorflow/cc/client/client_session_test.cc
index 9c0f00f2b1..dfbac9788e 100644
--- a/tensorflow/cc/client/client_session_test.cc
+++ b/tensorflow/cc/client/client_session_test.cc
@@ -49,7 +49,7 @@ TEST(ClientSessionTest, Feed) {
TEST(ClientSessionTest, Extend) {
Scope root = Scope::NewRootScope();
- auto a = Placeholder(root, DT_INT32);
+ auto a = Placeholder(root, DT_INT32, Placeholder::Shape({2}));
auto c = Add(root, a, {2, 2});
ClientSession session(root);
std::vector<Tensor> outputs;