-
Notifications
You must be signed in to change notification settings - Fork 14
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
Support for expected values in the XIR interpreter #49
Conversation
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.
Great addition. This made me think a bit more about what we should do with parameterized operators and symbolic handling. I'll put some thought into this, since currently it's not really that usable (for example, the way parameterized operators cannot be used here).
Thanks for the comments, @thisac! Let me know if you have any other queries. |
* Clarify that Jet is also a Python library * Improve CudaScopedDevice comments * Add changelog entry and set development release to 0.2.1 * Save changes to README * Move PR #49 changelog entry to 0.2.1 release * Add citations to README and Sphinx documentation * Add changelog entry for citations
Context:
One of the most common measurements applied to PennyLane circuits is
expval()
- taking the expected value of an observable in the context of a quantum circuit. This PR introduces support for interpretingexpval
statements in XIR programs using Jet.Description of the Change:
Scale
decorator class is introduced to linearly scale the_data()
representation of an existing gate.expval
statements usingCircuit.take_expected_value()
.Benefits:
Possible Drawbacks:
Parameterized operators are not supported in
expval
statements. This is partially due to the fact that the interpreter has no means of evaluating prefactors that reference one or more operator parameters. It is also unclear how the parameters of an operator should be specified in expected value statements. For example:or
User-defined gates are not supported in
operator
statements. In principle, this should be possible; however, the implementation burden is relatively high and the benefit of supporting such a use case is questionable.Related GitHub Issues:
None.