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

Do we need .ranges files? #36

Closed
williamjameshandley opened this issue Jul 16, 2019 · 3 comments · Fixed by #80
Closed

Do we need .ranges files? #36

williamjameshandley opened this issue Jul 16, 2019 · 3 comments · Fixed by #80
Milestone

Comments

@williamjameshandley
Copy link
Collaborator

Currently we apply boundary corrections (#35) based on user-specified edges in the MCMCSamples.limits dictionary, often input via a .ranges file. This has the advantage of being unambiguous, but is limited in that it does not control for edge effects that occur for "top-hat distributions."

One alternative that has occurred to me is to use the outermost samples as the definition of the edge of the distribution. We would then never plot the KDE in a region for which there are no samples, which doesn't seem particularly unreasonable, and the edge corrections may be able to handle top-hats as well as hard prior bounds.

This would be very easy to implement for the 1D case, and would obviate the need for xmin and xmax (since they could be read from the samples used to construct the KDE). 2D would require a lot more thought/research, but two-dimensional KDE is generally less damaged by incorrect edge treatments.

Discussion welcome

@lukashergt
Copy link
Collaborator

Not sure. I think it could work.

But if we use the .ranges file the edge effects are less of a problem, right? It's unexpected edges in the posterior that are harder to handle, where the prior range might be less helpful.

Using the outermost samples as edges might be the right thing to use for evidence and KL divergence, though, where we lack prior edges. If we plot those quantities too far out we typically get unphysical bumps...

@lukashergt
Copy link
Collaborator

I am inclined to start a PR for this. I've become sufficiently annoyed having to manually adjust limits for derived parameters that I really would like to have this.

My take on this would be to set the limits to the sample's min and max by default, but to still allow a .ranges file to overwrite these (where None is also an option to put in the file).

Thoughts?

@williamjameshandley
Copy link
Collaborator Author

I would be extremely grateful for such a PR @lukashergt .

My take on this would be to set the limits to the sample's min and max by default, but to still allow a .ranges file to overwrite these (where None is also an option to put in the file).

This sounds ideal. Experimentation will tell whether this is actually the desired behaviour, so best to implement as you suggest, keep installing locally from your branch, and see if that reduces your annoyance.

I've become sufficiently annoyed having to manually adjust limits for derived parameters that I really would like to have this.

I learnt recently that there is actually a (rather unappetising) term for this in developer circles.

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

Successfully merging a pull request may close this issue.

2 participants