-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Have IdentityOperator
inherit from UnitaryOperator
and HermitianOperator
instead of Operator
#24910
Conversation
✅ Hi, I am the SymPy bot. I'm here to help you write a release notes entry. Please read the guide on how to write release notes. Your release notes are in good order. Here is what the release notes will look like:
This will be added to https://github.com/sympy/sympy/wiki/Release-Notes-for-1.13. Click here to see the pull request description that was parsed.
Update The release notes on the wiki have been updated. |
IdentityOperator
inherit from UnitaryOperator
IdentityOperator
inherit from UnitaryOperator
instead of Operator
Benchmark results from GitHub Actions Lower numbers are good, higher numbers are bad. A ratio less than 1 Significantly changed benchmark results (PR vs master) Significantly changed benchmark results (master vs previous release) before after ratio
[8bd31f66] [aa3417d2]
<sympy-1.12rc1^0>
- 81.9±3ms 53.3±0.4ms 0.65 integrate.TimeIntegrationRisch02.time_doit_risch(10)
Full benchmark results can be found as artifacts in GitHub Actions |
What about if IdentityOperator have to inherit from HermitianOperator? |
IdentityOperator
inherit from UnitaryOperator
instead of Operator
IdentityOperator
inherit from UnitaryOperator
and HermitianOperator
instead of Operator
Oh, right. Identity is hermitian as well. I've updated to PR to have |
It could be better to avoid subtyping relationship to model intersection properties like |
I might have misunderstood this question. In what scenario would |
Then I would also raise an obvious question why would you want to change the design to achieve that. |
I see vtomole's point - its about consistency of properties. If you write some more generic code and use classes as indicator of properties it is strange that you have to write code like But SymPy is actually not trying to use classes for that purpose (probably because of technical issues, and because more flexibility is needed, see below). As far as I can see it uses I would rather vote for introducing the attributes |
I also had in mind that other logical programing is better than inheritance though. |
Fact check me on this: I'm pretty sure that every unitary matrix is hermitian. If that's true, there is no need for |
I'm sure that they are mathematically unrelated, and counterexamples are easily found
|
I've added |
In the current form of the PR the new attributes |
I've set the
Unfortunately we can't access |
T and S are not (in general) hermitian, so require
|
This has already been done in this PR
This is not neccessary because all these gates inherit from
👍 |
It seems all questions have been answered a month ago. |
Brief description of what is fixed or changed
The Identity operator is unitary. This change is to reflect that.
Release Notes
IdentityOperator
fromOperator
toHermitianOperator
andUnitaryOperator