Fix "AttributeError" thrown when processing multiple subgraphs induced by custom gradient definitions - #268
Open
nothingstopsme wants to merge 1 commit into
Open
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
…d by custom gradient definitions When converting a graph containing custom gradient definitions, there is a stage where the op node sequence is updated to reflect extracted subgraph structures (nodes belonging to subgraphs are removed while subgraphs are added). However, since such updates are conducted sequentially (i.e. one subgraph after another), if there are multiple subgraphs, the op node sequence will start to contain a mix of op nodes and subgraphs after the addition of the 1st subgraph, which the update procedure can not handle properly as it treats every item in the op node sequence as just a op node. Specifically, when the update procedure modifies the values of "control_inputs" attributes on all items in the op node sequence that do not belong to the curently targeted subgraph, and encounters an item of the type "_Subgraph" instead of "_OpNode", "AttributeError" will be raised due to the fact that "control_inputs" in "_Subgraph" is defined as a read-only property This fix introduces a check to see whether "control_inputs" is a read-only property or not before a write to it, and skipping the update attempt if True. Note that this skip in effect does not alter the existing behaviour, though, as the property "control_inputs" of "_Subgraph" is set to always return an empty tuple without backing variables (i.e. it remains unchanged no matter what)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This tiny patch is intended to fix the problem described in the title, which is probably best explained with an example as follows.
Considering this simple case:
The conversion starts with generating a full graph depicted by
func()and all op nodes involved:Since there are 2 calls to
my_op(), which defines its own custom gradient, 2 subgraphs grouping associated nodes are extracted from the full graph:Then the process goes on to update
nodesto reflect the subgraph structures, supposedly resulting in:Surprisingly, it turns out that tf2jax fails to convert this example and raises
AttributeErrorat the converting stage above. This is because_Subgraph.rewrite()(defined in "tf2jax/_src/tf2jax.py"), which is the function responsible for manipulatingnodesand subgraph substitution, treats every item innodesas just a op node of the type_OpNode; however, this is not true after the addition of the 1st subgraph_Subgraph(name='IdentityN')tonodes, when the content ofnodesbecomesTherefore, as the subsequent call to
_Subgraph.rewrite()on the 2nd subgraph_Subgraph(name='IdentityN_1')attempts to modify an attribute that is editable on_OpNodebut read-only on_Subgraphwhile iteratingnodes, anAttributeErrorexception occurs.This fix takes into account the fact that
nodescould be a mix of op nodes and subgraphs, and adds checks to avoid invalid attribute/property write attempts.