-
Notifications
You must be signed in to change notification settings - Fork 16
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
Comments
Not sure. I think it could work. But if we use the 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... |
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 Thoughts? |
I would be extremely grateful for such a PR @lukashergt .
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 learnt recently that there is actually a (rather unappetising) term for this in developer circles. |
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
The text was updated successfully, but these errors were encountered: