-
Notifications
You must be signed in to change notification settings - Fork 40
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
[Frontend] Make tests toml-schema independent #712
Conversation
Good point, we could just make it compatible with both. I was just going to move to version 2 entirely once the PR is merged. I'm happy with this as well though. Note there are several other tests that need this update though :) |
@dime10 , are there? I think I changed the device which is used by several tests, and can't see other places. |
Have a look at the test_decomposition and test_quantum_control lit tests |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #712 +/- ##
=======================================
Coverage 98.07% 98.07%
=======================================
Files 70 70
Lines 9599 9601 +2
Branches 754 756 +2
=======================================
+ Hits 9414 9416 +2
Misses 151 151
Partials 34 34 ☔ View full report in Codecov by Sentry. |
@dime10 right, thanks! I have made these tests toml-independent. It required some further code reshaping, could you please review? |
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 I think this PR is almost good to go. The only thing I would ask to restrict the utils/toml
module to be more focused on interacting with the toml file format, rather than including functionality related to device capabilities (it is a utility module after all).
frontend/catalyst/utils/toml.py
Outdated
return set(operations_no_adj) | ||
|
||
|
||
def validate_device_capabilities( |
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.
This module is just here to abstract away interacting with a TOML file right (and abstracting away from schema differences)? Validating device capabilities once the toml file has been processed then seems unrelated to interacting with the toml format. In that case I would prefer having this in the catalyst/device
submodule, along with some of the other functions that don't interact with the toml file (I'm not 100% where the boundary should be the, probably anything that requires the device instance).
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.
Done.
I personally think that it is not possible to find a perfect locations for code in Python+OOP style, so I am trying to focus on observable things only, like cyclic dependencies. The problem is in the fact that in this style we define types and methods simultaneously when we define classes (one per module), which forces some hierarchy. In practice, in contrast, we often need to process several equally-important types using a single algorithm. For my projects I (1) limit usage of "normal" classes (2) create types.py
for all mypy types and dataclases (3) group functions in -py files trying to localize groups of cyclic deps among functions one per file.
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.
What about get_device_toml_config and get_device_capabilities, their code seems to be operating primarily on the device, and then call into toml functions like read_toml_file and load_device_capabilities?
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.
Done
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.
Where?
Co-authored-by: David Ittah <dime10@users.noreply.github.com>
Co-authored-by: David Ittah <dime10@users.noreply.github.com>
…ode; Add a todo notice
* Catalyst tests now manipulate device capabilities rather than text configurations files. | ||
[(#712)](https://github.com/PennyLaneAI/catalyst/pull/712) |
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.
Reading this entry it sounds like it only concerns tests. Typically we exclude changelog entries for test-only, ci-only, doc-only, and repo-only changes.
Maybe the refactor can be mentioned in internal changes though? 🤔 New features, improvements, bug fixes should all be observable by the user in the distributed release in some way.
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.
ok done
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.
I don't think the commit changed anything?
frontend/catalyst/utils/toml.py
Outdated
return set(operations_no_adj) | ||
|
||
|
||
def validate_device_capabilities( |
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.
What about get_device_toml_config and get_device_capabilities, their code seems to be operating primarily on the device, and then call into toml functions like read_toml_file and load_device_capabilities?
**Context:** Catalyst needs to deal with operations which are not supported by the target device. This PR addresses decomposition-to-matrix branch. **Description of the Change:** We read gates to be decomposed to matrix from the device capabilities (which in turn are described in the device toml file). [sc-62011] **Benefits:** Device authors gain control over the decomposition strategies **Possible Drawbacks:** **Related GitHub Issues:** Requires #712 --------- Co-authored-by: lillian542 <38584660+lillian542@users.noreply.github.com>
**Context:** Having a proper encoding for the device capabilites, we implement the main part of program verification in this PR. **Description of the Change:** [sc-55558] [sc-60607] [sc-60648] * [x] Verify that no MCM (measure op) is present in the call * [ ] Verify that no callbacks are present in the call tree (future: verify that callbacks have custom vjp or are io callbacks) * [x] Verify that no state or variance is returned from the QNode. (Double check if Lightning Adjoint supports this!) * [x] adjoint diff method: Does the Tape only contain operations deemed differentiable by the QJITDevice from the TOML spec? * [x] parameter-shit method: Does the Tape only contain operations that support the 2-term parameter shift rule? **Benefits:** **Possible Drawbacks:** **Related GitHub Issues:** The following PRs need to be merged before this one: - #609 Introduces device capabilities. - #712 Makes toml-independent tests possible. --------- Co-authored-by: David Ittah <dime10@users.noreply.github.com> Co-authored-by: lillian542 <38584660+lillian542@users.noreply.github.com> Co-authored-by: Lillian <lillian542@gmail.com>
Context: Transition to the quantum device config schema 2
Description of the Change: Solve a regarding toml schema 2 udpate in tests by switching our test custom devices from toml text manipulations to the device capability manipulations
Benefits:
catalyst.utils.toml
.Possible Drawbacks:
Related GitHub Issues:
PennyLaneAI/pennylane-lightning#642