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

improved implementation of Romberg integration #30

Open
stevengj opened this issue Dec 8, 2020 · 4 comments
Open

improved implementation of Romberg integration #30

stevengj opened this issue Dec 8, 2020 · 4 comments

Comments

@stevengj
Copy link
Member

stevengj commented Dec 8, 2020

I posted an implementation on discourse (https://discourse.julialang.org/t/romberg-jl-simple-romberg-integration-in-julia/39313/8?u=stevengj) using Richardson.jl that is much more general (is not restricted to power-of-two sizes), seems to be more accurate than your current code, and is vastly simpler. I'm not sure if you would be interested in adopting it here?

My implementation could be sped up by inlining the sum calls and a few other tweaks, if necessary

@dextorious
Copy link
Collaborator

I responded on Discourse, but I do like the algorithm quite a bit. I'll leave this open for now as a reminder to benchmark it later.

@stevengj
Copy link
Member Author

stevengj commented Dec 24, 2020

Note that the priority of my implementation is more about accuracy and generality than performance, though the performance of the code now in Romberg.jl isn't too bad (but still a bit slower than yours, maybe a factor of 2 IIRC).

(My sense is that usually the computation of the integrand is the limiting factor in performance for quadrature routines, not the integration code itself.)

@dextorious
Copy link
Collaborator

Your sense is no doubt correct in general, but I wrote this package to explicitly address the case where you have presampled data and can't cheaply re-evaluate it at different points.

I haven't looked at the final Romberg.jl code yet, but from what I saw in the Discourse thread it I thought it could be made quite a bit faster still. It could be quite interesting if it could match or surpass the classic implementation. And even if that's not the case, I might just add a RombergAccurate or RombergGeneral method that calls Romberg.jl.

@stevengj
Copy link
Member Author

stevengj commented Dec 28, 2020

I wrote this package to explicitly address the case where you have presampled data and can't cheaply re-evaluate it at different points.

Even in that case, obtaining the data (e.g. from parsing a CSV file, or measurements, or from a finite-difference simulation) is probably more expensive than the quadrature. I find it hard to imagine a situation where you are generating discretely sampled data so rapidly that the performance of the quadrature is the rate-limiting step.

I haven't looked at the final Romberg.jl code yet, but from what I saw in the Discourse thread it I thought it could be made quite a bit faster still.

The final code is quite a bit faster.

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