Closed glassnotes closed 8 months ago
@glassnotes this reminds me, I have an idea for merging all the transform decorators, which long term should solve this issue! Plus make it easier for developers, as they no longer need to work out which decorator to use
@josh146 fantastic! that sounds like an even better solution :100:
That was solved with the transform rework :+1:
Feature details
Currently,
@qml.compile
and all related optimization transforms work only on tapes and qfuncs, i.e.,However there are a number of situations where it would be valuable to have them work also on QNodes. For example, suppose we want to compile a QNode after some expansion / decompositions at the device level have happened (e.g., expanding gates from a template).
Or, for computing the specs before/after compilation:
Implementation
Should be able to do something similar to how, e.g.,
qml.transforms.commutation_dag
works, by checking the input type and constructing the tape appropriately.How important would you say this feature is?
1: Not important. Would be nice to have.
Additional information
I will get to implementing this when I can, but it might also be a nice first issue for someone looking to learn more about how transforms work.
(Implementing this would also be a good opportunity to update the optimization transforms to use the new
for op in tape
syntax in lieu offor op in tape.operations + tape.measurements
).