-
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
Matrix/Tensor product between two PauliWords now returns PauliSentence #5054
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #5054 +/- ##
==========================================
- Coverage 99.68% 99.67% -0.02%
==========================================
Files 394 394
Lines 35730 35465 -265
==========================================
- Hits 35619 35351 -268
- Misses 111 114 +3 ☔ View full report in Codecov by Sentry. |
See no significant performance regression in this (admittably) simple test benchmark
|
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.
Existing changes look good to me so far, but it will be missing some docs updates once the Pauli4 PR is merged in.
Looks to me like the examples in the docstring for PauliWord
will need an update for this change, as well as the qml_pauli.rst
file. I guess the exact form of the change might depend on the decision about a deprecation cycle discussed above (and certainly for the Pauli4 PR to merge).
I think it's fine - you also get a I can see it either way. I think it's probably better to have the result be a consistent type instead of simplifying in certain cases and ending up with different possible outcomes (in terms of the type of object). But I wouldn't be opposed to just returning a |
I agree with that, the (marginal) performance increases dont justify that special case. Overall better to have something that just works for a user than something that is complicated to handle and slightly faster here. |
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 @Qottmann, 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 for suggesting this.
I think the only way to really go about this is with a hard breaking change, but it's one that shouldn't particularily influence anyone, and I can see everyone being happy with.
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 @Qottmann!
#5054) Following discussion here](#5017 (comment)) changing the default behavior of products between two `PauliWord` instances. old (see comment in discussion) ~~One thing I am still unsure about at the moment is for pure tensor products (where no coefficient is raised). E.g.~~ ``` pw1 = PauliWord({0:"X"}) pw2 = PauliWord({1:"X"}) ``` ~~I would find it counterintuitive to get a PauliSentence from `pw1 @ pw2` but would expect `PauliWord({0:"X", 1:"X"})`~~
Following discussion here](#5017 (comment)) changing the default behavior of products between two
PauliWord
instances.old (see comment in discussion)
One thing I am still unsure about at the moment is for pure tensor products (where no coefficient is raised). E.g.I would find it counterintuitive to get a PauliSentence frompw1 @ pw2
but would expectPauliWord({0:"X", 1:"X"})