-
Notifications
You must be signed in to change notification settings - Fork 215
Metrics init scope #382
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
Metrics init scope #382
Conversation
…e CTORs to the access methods defined in Metric, which is now an Interface.
For the op changes, you're probably going to want to wait for #378 and then rebase onto it. The local generation is "correct" in that it matches what we have, but some of the ops are misclassified. |
Hey @JimClarke5 , can you please rebase this PR? There has been some breaking change as we have upgraded to TF2.6.0, including a new signature for |
Ok, I will change BatchMatMul to MatMul as I found an error in Framework MatMul while testing Optimize minimize |
…e CTORs to the access methods defined in Metric, which is now an Interface.
… instead of org.tensorflow.op.train.BatchMatMul
…itScope # Conflicts: # tensorflow-core/tensorflow-core-api/src/gen/java/org/tensorflow/op/data/DirectedInterleaveDataset.java # tensorflow-core/tensorflow-core-api/src/gen/java/org/tensorflow/op/math/CompareAndBitpack.java # tensorflow-core/tensorflow-core-api/src/gen/java/org/tensorflow/op/summary/WriteHistogramSummary.java # tensorflow-core/tensorflow-core-api/src/gen/java/org/tensorflow/op/train/BatchMatMul.java # tensorflow-core/tensorflow-core-api/src/gen/resources/ops.pb # tensorflow-framework/src/main/java/org/tensorflow/framework/op/FrameworkOps.java
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
@JimClarke5 , that PR contains the commits of the TF2.6 upgrade, can you please rebase your branch so that only your commits remain? Thanks |
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
@karllessard see if this is better. I am still getting the dreaded |
@JimClarke5 , is there anything you want to update in this PR, since we just merged a few others PRs from @rnett (#376 and #302 ). If your code don't depend nor would benefit from these changes, then I'll start reviewing it, thanks! |
…e CTORs to the access methods defined in Metric, which is now an Interface.
… instead of org.tensorflow.op.train.BatchMatMul
@karllessard There was nothing specific that I needed from the recent checkins, but I did a rebase of |
Operand<? extends TNumber> labels, | ||
Operand<? extends TNumber> predictions, | ||
Class<U> resultType) { | ||
init(tf); |
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.
Just throwing an idea here but instead of remembering to call init(tf)
before doing any work in a given metric, would it make sense to have the BaseMetric
interception the call first, calling init
and then an abstract protected method implemented by subclasses where the initialization is assumed to be completed? (e.g. doCall
)
If you think that's a good idea but don't want to do it now, we can still merge without it
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.
Do you mean moving the call
method to BaseMetric
and then calling a new abstract method in the subclass?
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.
Also, it is not just this method, there are also result
, resetStates
that call init(tf)
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 what I meant, so you don't have to call init(tf)
everywhere in the subclasses. Again, that's just a suggestion.
protected void setTF(Ops tf) { | ||
checkIsGraph(tf); | ||
this.tf = tf; | ||
} |
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.
Do BaseMetric
still needs to store and instance of Ops
since it is already available in most endpoints? I can't see a case where it is needed in this PR (but it is not obvious to search in a PR neither)
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.
I believe that once the Metric
's variables are created, then subsequent operations would have to use the same Graph
to manipulate them. That is why I am storing it. Let me know if my understanding is wrong.
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.
Is there a unit test showing how the metrics are manipulated then after initialization?
All right @JimClarke5 , let's merge this and we can review my previous comments later with another PR if required, not really important. Thanks! |
This is a refactoring of
org.tensorflow.framework.metrics
to use the latest merge for initScope.In all the metric classes, the
Ops
parameter was moved out of the CTORs and moved to the access methods defined in a newMetric
interface. The oldMetric
logic was moved to a new classBaseMetric
.None of each metric's logic was changed.
The advantage of this change is that the metrics can be constructed before the
Ops
is created, which is the case when defining aModel
. The initScope feature facilitates this by removing the variable initialization obstacle.A side effect of this push, is that many of the generated operations in
tensorflow-core
did not match what was stored in the master repository, so there is over a thousand files changed in that module. Based on what @rnett told me, the locally generated code was correct, but we should verify this.There were a few changes in other packages to fix JavaDoc issues.