Skip to content
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

Explore Bessel.jl for Chebychev coeffs #74

Open
goerz opened this issue Mar 25, 2024 · 5 comments
Open

Explore Bessel.jl for Chebychev coeffs #74

goerz opened this issue Mar 25, 2024 · 5 comments

Comments

@goerz
Copy link
Member

goerz commented Mar 25, 2024

This might make the calculation of coefficients significantly faster:

See https://discourse.julialang.org/t/matrix-exponential-vector-for-various-scales/112022/17

@Fe-r-oz
Copy link

Fe-r-oz commented May 12, 2024

Do we need to normalize the spellings of Chebychev to Chebyshev in QuantumPropagators.jl ?

@goerz
Copy link
Member Author

goerz commented May 12, 2024

No, I always spell it Chebychev, and that will be the canonical spelling inside this package.

@Fe-r-oz
Copy link

Fe-r-oz commented May 13, 2024

Alrighty!

I am excited to explore Bessel.jl for chebychev coeff!

As you mentioned we have to use Bessel.jl instead of (besselj) from SpecialFunctions.jl, as it is typically 2-12x faster than specialfunction.jl implementations. Bessel.jl also have same names etc. besselj

Screenshot from 2024-05-13 08-22-16

if I recall correctly, the regular exponential just uses the modified Bessel function (besseli instead of bessel) and you kill the i in the definition of c and in the final phase factor

It seems that regular exponential uses besselj instead of besseli,, so there might be no need to kill i in c and phase factor, right?

Screenshot from 2024-05-13 08-31-12

@goerz
Copy link
Member Author

goerz commented May 13, 2024

To really "explore" this would require proper benchmarking in realistic settings. I have a WIP benchmarking repository that isn't quite ready to be pushed. Since the coefficients can typically be reused a lot, they are very unlikely to be a bottleneck in any optimization. Still, at some point, it would be nice to quantify it a bit more. This issue is more of a note to myself to look at this when my benchmarking code is in better shape. I don't think looking into this would be a good use of your time.

@Fe-r-oz
Copy link

Fe-r-oz commented May 13, 2024

Sounds good! I enjoyed your talk at Yao Community Call, that was comprehensive!

Looking forward to the workshop tutorial!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants