-
Notifications
You must be signed in to change notification settings - Fork 214
Add graph walking functions to Graph and GraphOperation #232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I may need to add a flag to include variables, too. |
The CI seems to be broken again, I'm not having issues running |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a lot of unnecessary formatting changes in this PR. Could you back those out?
tensorflow-core/tensorflow-core-api/src/main/java/org/tensorflow/Graph.java
Outdated
Show resolved
Hide resolved
tensorflow-core/tensorflow-core-api/src/main/java/org/tensorflow/Graph.java
Outdated
Show resolved
Hide resolved
tensorflow-core/tensorflow-core-api/src/main/java/org/tensorflow/Graph.java
Outdated
Show resolved
Hide resolved
} | ||
|
||
if (op.numControlInputs() + op.numInputs() == 0) { | ||
if ((forbiddenBodyOps != null && forbiddenBodyOps.contains(op.type())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initialising these to Collections.emptySet()
internally even if we don't make users do it will make this if a lot less ugly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See one of the other comments, nulls are necessary to distinguish from "only allow the empty set" which would error whenever something is in the body. Optionally we could do that behavior (i.e. allow everything) for the empty set, but imo nulls is clearer (and what if that's what you want?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would we want the behaviour of only allowing the empty set? So you could catch the runtime exception and have different behaviour if there were intermediate nodes?
Anything that implies users have to catch a subclass of RuntimeException
isn't good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's for 0 input intermediate nodes specifically, i.e. things that don't depend on the inputs. Generally Constant
is ok and the others (Placeholder
, Variable
, etc) are ok, but since I'm making it a parameter "none" is an option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. I'm still not sure that the semantics of this is quite right, but given we've not stabilised the API yet lets add it in and use it a bit first before making further decisions.
tensorflow-core/tensorflow-core-api/src/main/java/org/tensorflow/GraphOperation.java
Outdated
Show resolved
Hide resolved
tensorflow-core/tensorflow-core-api/src/main/java/org/tensorflow/GraphOperation.java
Show resolved
Hide resolved
tensorflow-core/tensorflow-core-api/src/main/java/org/tensorflow/GraphOperation.java
Outdated
Show resolved
Hide resolved
tensorflow-core/tensorflow-core-api/src/main/java/org/tensorflow/op/core/Constant.java
Show resolved
Hide resolved
It might be useful to have two extra graph walking functions one which traces all the ops which depend on a set of inputs, and one which traces all the ops which are depended on by a set of outputs. That way you can take any graph and figure out what you need to feed into it for a given output. That's not likely to be in a production system, but it would be super useful when poking a model in jshell. I've had to write ad-hoc things which do that when I was trying to understand the TF 1.x graph structure for saving, and having a supported method would be nice. |
Yeah, I can do that. |
This is due to my auto format on commit, so not really, at least not without it being a big pain. It's google-java-format, though, so it should really have already been done. Imo we should add a format check for PRs in the CI (and format everything existing to match), at least once it's not having time issues. |
tensorflow-core/tensorflow-core-api/src/main/java/org/tensorflow/Graph.java
Outdated
Show resolved
Hide resolved
tensorflow-core/tensorflow-core-api/src/main/java/org/tensorflow/Graph.java
Outdated
Show resolved
Hide resolved
tensorflow-core/tensorflow-core-api/src/main/java/org/tensorflow/Graph.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
tensorflow-core/tensorflow-core-api/src/main/java/org/tensorflow/Graph.java
Outdated
Show resolved
Hide resolved
tensorflow-core/tensorflow-core-api/src/main/java/org/tensorflow/Graph.java
Outdated
Show resolved
Hide resolved
tensorflow-core/tensorflow-core-api/src/main/java/org/tensorflow/GraphOperation.java
Outdated
Show resolved
Hide resolved
* @see #completeSubgraph(Set, Set, boolean) | ||
*/ | ||
public synchronized Set<GraphOperation> completeSubgraph(Set<Operand<?>> inputs, Set<Operand<?>> outputs, | ||
Set<String> allowedNoInputBodyOps, Set<String> forbiddenNoInputBodyOps) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These two last extra parameters obfuscate a bit the overall solution, which would be very simple without them. Why can't we simply include all ops we encounter without this logic, whether they have inputs available or not, and let the caller filter them out after if he needs to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's fine. I don't like how easy it is to end up including things upstream from the inputs in the body then, but I don't see much of a way around it, since we can't just forbid it altogether.
Signed-off-by: Ryan Nett <[email protected]>
Signed-off-by: Ryan Nett <[email protected]>
Signed-off-by: Ryan Nett <[email protected]>
Signed-off-by: Ryan Nett <[email protected]>
Signed-off-by: Ryan Nett <[email protected]>
Signed-off-by: Ryan Nett <[email protected]>
Signed-off-by: Ryan Nett <[email protected]>
Signed-off-by: Ryan Nett <[email protected]>
@rnett looks good, are you done with the changes? If so, can you please check why the quick build has failed? |
It's the javadoc issues in See core failure (that is ignored), framework failure, and the core pom. It's causing all recent PRs to fail the CI. |
Ok, I see. Indeed, the javadoc validation is disabled in the Now what you are saying is that the framework documentation with links to the generated classes fail to pass this validation because it tries to validate the documentation it links to? I was not aware of that but I guess it's possible, @JimClarke5 can we clean up the framework documentation to at least fix the CI build, even if it means to disable these links in it? I will merge this PR then, thanks @rnett ! |
There is a C library for commonmark, but it would need to be extended with a JavaDoc renderer based on the HtmlRenderer. I have done this with Python and am now working on the Java version. I could look at the C version and determine what needs to be done. |
Ok @JimClarke5 I'll let you judge how long it would take but for now the priority is really to fix the CI build so that snapshots get refreshed on Sonatype after merging a PR. Do you think we can simply fix the framework quickly by removing links to the generated ops? |
@karllessard Let me experiment with the CommonMark-cmark library. That would be the quickest fix and incorporate it into SourceWriter.cc |
Couldn't we, for now, just let framework build w/ failing javadocs? W/ a note to fix before the next release or something. |
@karllessard please explain exactly what you mean by “ quickly by removing links to the generated ops?” |
@karllessard As a test, I have been able to transform the markup from api_def_UnsortedSegmentMax.pbtxt
to
The only issue so far is the relative URL I can change SourceWriter.cc to call out to new C methods to handle the JavaDoc rendering and in turn link in the cmark C library. I will also have to add the external cmark source to |
@JimClarke5 , I would say don't put too much effort of this C++ markdown converter because @rnett is working on porting the op generator to Java anyway (#244). Unless Ryan you think that we could use it to convert the documentation as we generate the new ops.pb file? |
I mean, we probably could, but given this is a Java library originally (if I understood things right) it's probably easier to wait. Imo skipping the Javadoc generation on the CI until that's done works fine as an "emergency solution". |
Extracted from #211, adds graph walking and a minimal subgraph function.
Also fixes a bug in Constant where the scope wasn't applied (including device).