-
Notifications
You must be signed in to change notification settings - Fork 30
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
Refactor device code around capabilities [NFC] #1149
Conversation
.. to no longer take a ProgramFeatures argument, since that information can be deduced from the supplied device.
.. to no longer take a stopping condition argument, since that information can be obtained from the supplied capabilities. Also eliminate the max_expension argument since PL is moving away from it.
.. to not take backend and capability arguments, since those can be computed from the supplied device.
.. instead of legacy-device-style op strings.
.. and remove obsolete device properties.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1149 +/- ##
==========================================
- Coverage 97.88% 97.87% -0.02%
==========================================
Files 76 76
Lines 10863 10847 -16
Branches 1283 1282 -1
==========================================
- Hits 10633 10616 -17
Misses 179 179
- Partials 51 52 +1 ☔ View full report in Codecov by Sentry. |
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.
Apart from the code factor warning, I am happy to approve!
Simplifies device related code around capability checks and decomposition, and eliminates the use of
"Adjoint(*)"
and"C(*)"
declarations in favour of DeviceCapabilities and OperationProperties dataclasses.Includes the following (non-functional) changes:
get_device_capability
signaturecatalyst_decompose
signatureQJITDevice.__init__
signaturepennylane_operation_set
and useDeviceCapabilities
insteadoperations
,observables
, andmeasurement_processes
properties from our device classesSome of the code seems to have been written solely to facilitate testing, which should be avoided.
[sc-67124]