-
Notifications
You must be signed in to change notification settings - Fork 39
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
Adds Catalyst specification files. #566
Adds Catalyst specification files. #566
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #566 +/- ##
=======================================
Coverage 98.69% 98.69%
=======================================
Files 167 167
Lines 23813 23819 +6
=======================================
+ Hits 23502 23508 +6
Misses 311 311 ☔ View full report in Codecov by Sentry. |
f28a489
to
bb5e941
Compare
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 job so far! I left some comments.
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 for this @erick-xanadu, I've left a few suggestions.
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.
Thank you @erick-xanadu! I have a few minor comments, but it looks good to me.
1bb8d0c
to
a3d2f6f
Compare
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 good to me!
3dbefaa
to
0a4dfce
Compare
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.
Small comment, but otherwise looks good to me.
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 @erick-xanadu! 🎉
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 👍
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.
Still looks good to me, but I left a few comments.
Hi @erick-xanadu, please merge the master in your branch one more time, and also update the _version.py file. So far, _version_ = "0.34.0-dev17" needs to be updated to _version_ = "0.34.0-dev18" |
I have a question for the team, among the gates that the lightning device lists as "supported" (that is PL will not currently decompose them, full list here) but doesn't have native kernel support for (should correspond to this list), which gates would you rather see decomposed via Generally this choice will be up to the device developer in our framework, although the compiler may choose to override that preference if needed. The preference is expressed in the TOML file via the I think it comes down to the following operations:
The kind of decisions that could be made for example is "StatePrep would generate a huge matrix, maybe decomposition is better here" and "ISWAP is small gate, it is best implement as a matrix", but we'll leave the partition up to you. |
For a start
That said, decomposition is sometimes necessary to transform multi-parameter gates into single-parameter gates for the adjoint method. I would also add we could quickly add kernels for most of these to get better performance, i.e. avoid decomposition and useless flops. |
Thank you @vincentmr, appreciate the list, let's go with that for now :)
We are happy to update our pipeline whenever new kernels become available!
That's true we have considered this as well, we are going to force decomposition if required by differentiation (hence the device spec is only a preference). |
@vincentmr I will be updating the files to the following preference then:
EDIT: Moved |
@vincentmr @AmintorDusko the PR appears to be in the final state. At least according to the discussion that I have followed. What I was told by @dime10 and from the discussions
|
On second thought (sorry ...), due to the lack of support for control values and because their matrix representation can grow large with many controls, I think it would be best to put |
Not a problem @vincentmr, happy to make the change: 159f6a8 |
@vincentmr @erick-xanadu Sorry to come back to this, but from the information you provided above I think |
Hi all, I'm manually overriding the merge of this onto master to overcome the dev version script CI failure. |
It is natively supported if all control values are |
@dime10 and @vincentmr I don't think we should worry too much about where gates live for the time being. A lot of behaviour is overriden by Catalyst and this includes ControlledQubitUnitary. With the current behaviour, if ControlledQubitUnitary inherits from I think this is a bit too future thinking and there is no reason why we can't move this gate from one list to the other in the future as well. Happy to make any changes though. |
You're right, I didn't realize |
@erick-xanadu and @dime10 I think you know better than me which list it should go in at this point. I wanted to point out limitations in the current implementation and if there are any doubt on your side feel free to ask. On that I'll let you decide and stamp this PR with approval. Cheers. |
Context: The following files improve the compatibility between pennylane-lightning and catalyst. The initial motivation behind these files was a way to distinguish gates which are allowed in pennylane-lightning's of
qml.Device
but are implemented in the C/C++ library viaapplyMatrix
. Without theseapplyMatrix
gates, catalyst had to rely on decomposition rules which yielded an initially unexpected (but not unsurprising behaviour). For example,OrbitalRotation
would be decomposed into more than 50 gates as opposed to being applied as a matrix. With these files, catalyst can now specify custom decomposition rules for gates which are applied viaapplyMatrix
and match pennylane-lightning's behaviour more closely. Please see ADR 73 for the details.Description of the Change: Adds initial configuration files for
lightning.qubit
andlightning.kokkos
.Benefits: Better compatibility between pennylane-lightning and catalyst.
Related GitHub Issues: PennyLaneAI/catalyst#369
[sc-46426]