-
Notifications
You must be signed in to change notification settings - Fork 603
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
Allow qml.cond
to fallback to the Python interpreter if a compiler is not available and there are no MCMs
#6016
Conversation
…nterpreter if a compiler is not available.
…is not available and there are no MCMs
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #6016 +/- ##
==========================================
+ Coverage 99.52% 99.65% +0.13%
==========================================
Files 430 430
Lines 41835 41436 -399
==========================================
- Hits 41637 41295 -342
+ Misses 198 141 -57 ☔ View full report in Codecov by Sentry. |
[sc-69157] |
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.
Nice work! I don't have good visibility into whether and how this will interact with existing PennyLane cond though.
Co-authored-by: Christina Lee <[email protected]>
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.
Thanks @PietropaoloFrisoni, I've just resolved the conflicts! |
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.
Looks great! Very exciting to expand qml.cond
😄
…into `CondCallable` (#6063) **Context:** For 'historical reasons', the captured version (see sc-66774) and the non-captured version (see sc-69157) of `qml.cond` have a different style, which is rather uneven. The purpose of this story is to incorporate them in such a way that the implementation is more similar to the one in Catalyst. Or, to make another example, the implementation of `qml.for_loop` in PL (see sc-66736 and sc-69432). The purpose is not to change/add functionalities, but rather to unify the code structure so that it is more elegant. **Description of the Change:** As above. **Benefits:** Better and cleaner structure, more similar to Catalyst. **Possible Drawbacks:** None that I can think of right now directly due to this PR (we just moved some code). **Related GitHub Issues:** None **Related Shortcut Stories:** [sc-70342]
Context:
In Catalyst,
catalyst.cond
will seamlessly fallback to Python interpretation when@qjit
is not present. However,qml.cond
will instead raise an error when@qjit
is not present and the condition is not a mid-circuit measurement, which is not ideal.Description of the Change:
When
@qjit
is not present and the conditional does not contain a mid-circuit measurement,qml.cond
will now simply execute the conditional in standard Python.qml.cond
can be optionally used in decorator mode (matching the behaviour ofcatalyst.cond
).Benefits:
This will allow the same code to work with and without
@qjit
, without needing to modify the workflow.This will also allow templates and operation decompositions to use
qml.cond
internally, with no changes for standard Python execution, but with conditionals captured automatically when using@qjit
.Possible Drawbacks:
Not a drawback per se, more of a note, but the
CondCallable
class introduced in this PR might be needed (and extended) to support capturing for conditional statements as JAXPR primitives(?). It is based on the equivalent classes from Catalyst.Introduces an additional decorator UI. This is not documented for now, but it will easily allow existing Catalyst code to port from using
catalyst.cond
toqml.cond
.Related GitHub Issues: n/a