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

Specify initial evaluation points [Feature Req.] #30

Open
agerlach opened this issue Jul 20, 2020 · 4 comments
Open

Specify initial evaluation points [Feature Req.] #30

agerlach opened this issue Jul 20, 2020 · 4 comments

Comments

@agerlach
Copy link
Collaborator

agerlach commented Jul 20, 2020

For DiffEqUncertainty expectation() applications, distributions that are narrow relative to the support can lead to incorrect results via Quadrature as the integrand is not sampled at points w/ non-zero (numerically) joint pdf values.

B/c we know the pdf, it would advantageous to "seed" or initialize any adaptive quadrature methods w/ the mean and/or random samples from the distribution.

E.g. for a simple linear system, u'=p*u, with uncertain IC,

u0_dist = [truncated(Normal(3.0,2.0),-1000,1000)]

will produce expectations of 0

while

u0_dist = [truncated(Normal(3.0,2.0),3-1000,3+1000)]

produces the correct result. The reason being that the midpoint of the integration domain is used as initial quadrature points in most algorithms supported.

@lxvm
Copy link
Collaborator

lxvm commented Oct 30, 2023

@agerlach I agree that localized integrands can be very difficult for quadrature schemes to resolve without any prior information, however I don't think this issue can be fixed at the level of Integrals.jl. In particular, not all libraries used by Integrals.jl support breakpoints for the interval of integration. Did DiffEqUncertainty.jl end up making a fix, such as breaking up the integration domain into cubes refined about the peaked distribution?

I would like to attempt fixing related issues like #41 and #160, possibly with a solution like AsDomain from DomainSets.jl. However, I don't think there is ever going to be a universal fix, since not all algorithms and domain discretizations are compatible.

@agerlach
Copy link
Collaborator Author

I agree completely. When Chris and I started this package we had some discussions about develop new scheme to support some other work. Hence this issue. PR #188 extends the interface to add support for this w/ CUBA.

@lxvm
Copy link
Collaborator

lxvm commented Nov 1, 2023

Interesting! I didn't know that Cuba supported features like that. I wonder if the information about initial points could be specified with more expressive domain types that have "special" points. For example, QuadGK.jl has something similar where the user provides an interval with breakpoints (a, b, c...) that is used to partition the interval. In that case, QuadGK clusters points about the breakpoints.

@agerlach
Copy link
Collaborator Author

agerlach commented Nov 1, 2023

One issue with these Cuba features is it is not readily obvious of how to use them. Cuba.jl just mimics the Cuba C library docs and those are sparse on details. E.g., when trying to use the peakfinder option with Divonne, the best resource I could find to figure out how to actually use it was the pythons bindings for Cuba.

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