Why do we still use Lanczos for c ≠ integer?

[dlfivefifty]

Cholesky should always be faster. otherwise we've done something seriously wrong!

@tsgut @ioannisPApapadopoulos @DanielVandH

[ioannisPApapadopoulos]

I do not think we do. Looking at https://github.com/JuliaApproximation/SemiclassicalOrthogonalPolynomials.jl/blob/a1e4c3e65f164bc55f97f3574eb0da3ca62468ff/src/SemiclassicalOrthogonalPolynomials.jl#L133 it seems it only uses Lanczos if c is not an integer?

[dlfivefifty]

That's what I meant

[TSGut]

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.

[dlfivefifty]

you just approximate (t-x)^c by a polynomial

[TSGut]

Well, as long as what you mean is to reach $P^{a,b,c}(x)$ with $c$ a general real, we ladder to $P^{a,b,\lfloor c \rfloor}(x)$ as now and then from there use decomposition methods on the Clenshaw-computed remaining weight $(tI-X)^{c-\lfloor c \rfloor}$. Otherwise it will be unstable for high $c$.

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.

[dlfivefifty]

what makes you think lanczos is stable for high $c$?

[TSGut]

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. 😂