Add TransformTrace, TransformTracer and TransformInterpreter classes for transforming PLxPR
#6389
Conversation
…AI/pennylane into plxpr-interpreter-base
Co-authored-by: David Wierichs <[email protected]>
**Context:** See EPIC: [[P1] Update PennyLane GitHub repo README content positioning for researchers](https://app.shortcut.com/xanaduai/epic/76283/p1-update-content-in-pennylane-github-repository-readme?cf_workflow=500000005&ct_workflow=all&group_by=none) --------- Co-authored-by: Josh Izaac <[email protected]> Co-authored-by: ixfoduap <[email protected]>
**Context:** Follow up PR addressing the `-0.01%` project code coverage issue that slipped through the cracks in #6530. **Description of the Change:** Removed the relevant check because it was being exclusively tested by a removed unit test (associated with `qml.shadows.shadow_expval`), Here's the old test that was removed which was testing that logic branch: ```python ... def test_non_shadow_error(self): """Test that an exception is raised when the decorated QNode does not return shadows""" dev = qml.device("default.qubit", wires=1, shots=100) @partial(qml.shadows.shadow_expval, H=qml.PauliZ(0)) @qml.qnode(dev) def circuit(): qml.Hadamard(0) return qml.expval(qml.PauliZ(0)) msg = "Tape measurement must be ClassicalShadowMP, got 'ExpectationMP'" with pytest.raises(ValueError, match=msg): circuit() ... ``` **Benefits:** Better code coverage. **Possible Drawbacks:** None. [sc-77485]
mudit2812
changed the title
TransformTrace, TransformTracer and TransformTraceInterpreter classes for transforming PLxPRTransformTrace, TransformTracer and TransformInterpreter classes for transforming PLxPR
| self._is_informative, | ||
| self._final_transform, | ||
| ) | ||
| ) | ||
| return qnode | ||
|
|
||
| def custom_plxpr_transform(self, fn): |
There was a problem hiding this comment.
Why not just set during initialization?
I know this is how we are doing this type of syntax with custom qnode transform, but I still find that API very confusing. Keeping that confusing syntax was a heated battle I lost over the cost of change. We don't have the cost of change here, so I'd really not like to carry over bad design decisions.
There was a problem hiding this comment.
Chatted offline. This is a good idea, I'm changing the implementation to reflect this.
This is something I've thought about for some time. There are cases where we can either only build the transform using Interpreters, or cases where using Interpreters will be more efficient/easy. For now, I want to focus on transforms that can be implemented using When we reworked transforms, a major factor for that was to standardize how to define transforms. If we start looking into having different implementations for transforms with program capture, that will likely cause issues down the line by making transforms harder to maintain. Nevertheless, this is an ongoing project so we have the flexibility of making changes at a whim. If we decide later that it is fine to have multiple types of transforms, or to only have Interpreter-based transforms, then we can make that change as needed. I'm going to try to be more vigilant about issues that come up with final-style transforms and try to avoid getting married to |
This PR adds 3 new classes to
qml.captureto facilitate transforming PLxPR natively without the need to first createQuantumScripts.TransformInterpreterwill be used to evaluate PLxPR for the purposes of applying transforms.TransformInterpreterwill useTransformTraceandTransformTracerto transform primitives that are being evaluated.TransformDispatcher,TransformContainer, andTransformProgram.qml.captureto give a detailed explanation of how the framework for applying transforms natively to PLxPR works.qml.capture.enable()andqml.capture.disable()to dispatch tojaxwhen using pennylane classes with capture enabled, and toautogradwhen capture is disabled. This assumes that users won't be silly and try to usepennylane.numpywith capture enabled.[sc-75560]