Tidy classical cotransform part of TransformProgram
#6631
+103
−103
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.
Context:
When trying to improve the organization and structure of our workflow, one major blocker is being able to handle the classical cotransform and argnums component of the transform program. Right now we can't defer adding in the device transforms and gradient preprocessing till inside
qml.execute
, because we have to set the classical component of the transform program in the qnode.One option I am considering is storing
qnode
,args
, andkwargs
on the program and lazily computing args and the classical component, instead of eagerily calculating theargnums
andclassical_cotransforms
. This would allow us to setup the full transform program insideqml.execute
, instead of theQNode
.The main blocker to making this change was understanding what the classical component was actually doing. While figuring that out, I rewrote some of the code to reduce nesting and reduce the amount going on in each individual component. Hopefully this makes it a little easier to understand.
Description of the Change:
Reduces the levels of nesting in
TransformProgram._set_all_classical_jacobians
to make it a little easier to understand.Benefits:
In the future, it will be easier to move components around without breaking things.
Possible Drawbacks:
Maybe an unnecessary waste of time.
Related GitHub Issues: