-
-
Notifications
You must be signed in to change notification settings - Fork 30
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
wrap MCintegration.jl #202
Conversation
I guess you can seed your rng to control convergence, but QMC might also be helpful numericalEFT/MCIntegration.jl#53 |
Project.toml
Outdated
@@ -7,6 +7,7 @@ version = "4.1.0" | |||
CommonSolve = "38540f10-b2f7-11e9-35d8-d573e4eb0ff2" | |||
HCubature = "19dc6840-f33b-545b-b366-655c7e3ffd49" | |||
LinearAlgebra = "37e2e46d-f89d-539d-b4ee-838fcccc9c8e" | |||
MCIntegration = "ea1e2de9-7db7-4b42-91ee-0cd1bf6df167" | |||
MonteCarloIntegration = "4886b29c-78c9-11e9-0a6e-41e1f4161f7b" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's move the MonteCarloIntegration one to an extension now. It's insufficient in most tests so we should just always use the better method by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's leave it to a another pr since the goal in this pr is to wrap MCIntegration, which is not feature-equivalent to MonteCarloIntegration. It would also be breaking
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 sounds good.
Make the tolerances a bit lower? If that's not helping then its stopping heuristic may be incorrect. |
There are actually a few interface errors that I just haven't had time to fix. Hoping to look into it sometime these holidays |
I'm the developer of MCIntegration.jl. Thank you for considering our package. If you need any help to fix the interface errors, please let me know :-) |
@kunyuan Thank you for your interest! Other than what was mentioned before, support for a batching interface compatible with user parallelization on, e.g., shared memory, the GPU, distributed memory, etc... would be very useful. I see there is already an issue for it (numericalEFT/MCIntegration.jl#29) and I can add that QuadGK.jl has a batching interface that could be used for guidance. |
@ChrisRackauckas @frankier The interface issues will be resolved by numericalEFT/MCIntegration.jl#55. @ChrisRackauckas I saw numericalEFT/MCIntegration.jl#51 so I moved MCIntegration functionality to an extension. It will be easy and non-breaking to migrate it to a dependency as soon as it is ready. |
That's good thanks. Yeah, until MPI is an extension in MCIntegration.jl it probably cannot be brought in as a standard dependency since MPI.jl can cause build problems on some platforms. |
@ChrisRackauckas I think everything is fixed now. Should I merge? |
Fixes #194
This pr adds a VEGASMC algorithm from MCIntegration.jl
This library supports:
This library doesn't support:
I think some of the tests may not pass due to underconvergence, which happens randomly due to MC sampling.