- Notifications
You must be signed in to change notification settings - Fork200
Correct conversion discreteoperator.to_sparse() when constrained#1974
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:master
Are you sure you want to change the base?
Conversation
codecovbot commentedJan 5, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@## master #1974 +/- ##==========================================- Coverage 84.47% 84.47% -0.01%========================================== Files 314 314 Lines 19057 19075 +18 Branches 2387 2391 +4 ==========================================+ Hits 16099 16113 +14- Misses 2199 2201 +2- Partials 759 761 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
shouldnt the conversion from vector to integer just fail if the constraint is violated? |
I mean if get_conn returns a state outside the Hilbert space one should just error or ignore it ? |
Indeed, that is what happens currently. It would be nice if we could automatically make the operators work in the chosen subspace. |
I am not sure we should do this... at first sight it makes the code harder to read, adding another layer of logic we don't really need... I think we should just error and it should be the job of the operator to make sure it acts correctly on the given (constrained) hilbert space ! |
Yeah, I'm also unsure. Though automatic stuff is very handy sometimes... |
…e operator is not diagonal.The fix is to remove the connected entries that violate the constraint.
f1a0f5d
to5faa17f
Comparef6a2477
to6e593ca
Compare
Uh oh!
There was an error while loading.Please reload this page.
[Sketch PR: leaving this here to avoid forgetting]
if the operator is not diagonal.
The fix is to remove the connected entries that violate the constraint.
I'm not sure we should merge this, as it would mean that calculations in full summation would not differ from Monte Carlo, because the full summation would correctly respect the constraint even in the connected components but not the Monte Carlo...
Needs some thought and design to fix it in Monte Carlo as well.