-
Notifications
You must be signed in to change notification settings - Fork 3
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
Why do we still use Lanczos for c ≠ integer? #114
Comments
I do not think we do. Looking at
|
That's what I meant |
It's just a matter of a more subtle implementation. I guess we'd want to go to the integer floor of the given parameters via a hierarchy, then go the final non integer amount as a last step. It should be fine to do that, though it won't be a polynomial modification at the end, so it won't be a banded connection. Not that big of an issue though. The answer to your question is just that it's a bit more subtle and we didn't need it. But I can get that working pretty quickly if we do. |
you just approximate |
Well, as long as what you mean is to reach But both of those parts are implemented. The first is just what SemiclassicalOPs.jl does and the second already works in ClassicalOPs.jl. So it's just a well-placed if condition in SemiclassicalOPs.jl to do this. |
what makes you think lanczos is stable for high |
Fair point but we moved away from Lanczos for specifically that reason. You are likely right that for low c where Lanczos is reasonable you can just call the ClassicalOP.jl convertedop directly. I really would prefer we do it properly though. 😂 |
Cholesky should always be faster. otherwise we've done something seriously wrong!
@TSGut @ioannisPApapadopoulos @DanielVandH
The text was updated successfully, but these errors were encountered: