Implement Nested Sampling (and Bayesian Evidence Calculations)

[vandalt]

Hi!

I recently tried to play with nested sampling in Radvel and so far it's working pretty well. If this gets merged eventually, it would fix #149.

Things already done

The PR includes the following:

• Prior transform (inverse CDF) method implemented for most prior distributions.
• Prior transform method implemented for the Posterior class. It iterates over free parameters and applies the inverse CDF of their prior to the unit cube.
• A check_proper_priors() method for Posterior, performing some checks to make sure there are no "improper" priors, and that each parameter has only one prior.
• A draft example copying the K2-24 one but with nested sampling (dynesty) instead of MCMC. This is just a temporary example I used for development. Another one could be used to make tutorials more diverse.

Things left to do

Some things I was wondering and/or that are still left to do:

• [ ] Should there be a nested sampling module similar to the MCMC one that wraps the sampler and provides utility function? If so should it aim to support a single sampler among dynesty, Ultranest, etc., or more than one? Another option would be to simply provide prior transforms and let users run the sampler themselves. The main upside of a dedicated module is probably integration in the CLI interface.
• [ ] How should joint/non-finite/multiple priors be handled? See note below.
• [x] Some priors still don't have a transform implemented, either because they were tricky (see my last point) or because I had never used them and did not look into them yet for this quick draft PR.
• [ ] The check_proper_priors() method is never run automatically for now. It could be run on every prior_transform call, integrated into a nested_sampling.py module, or documented clearly in the tutorial to let users run it just once before running the sampler.
• [ ] There is no nested sampling/prior documentation yet.
• [ ] I still need to write a proper nested sampling tutorial

Question(s) about priors

One thing I found tricky is how to handle certain priors that don't directly depend on one parameter or that complement other priors (e.g. ecc < 1, K > 0). Some avenues I thought about to handle those are:

• Using truncated distributions when the parameter is explicitly defined anyways (e.g. instead of no prior on K and K > 0, use ModifiedJeffeys, HardBounds, a log parametrization, etc.)
• Using a "2D" prior when the parameter is defined as a function of others. For example, replace uniform priors on se{cos}w + EccentricityPrior by a "unit disk" prior (see e.g. the exoplanet package)
• A generic way to handle multiple priors on the same parameters or on dependent parameters. I see two ways of doing this:
  • Incorporating the "extra" priors in the likelihood so that they return -inf when the parameter is out of bounds (this is what juliet does with the modelOK attribute I think)
  • A generic way to combine priors when building the model. I'm not sure how this would work for inverse CDFs yet though.

I'm open to any comments/suggestions about all of the above of course.

Thank you!

[vandalt]

Marking as ready for review, as I have WIP tutorials and I think the questions in the PR will determine the remaining development work.

[bjfultn]

This appears to be failing CI but it makes it a little unclear because its a cross-fork PR. Do the tests pass for you if you manually run them as defined in the travis.yaml file?

[vandalt]

Hi @bjfultn,

Most were passing when I ran it manually. However I will re-run them and add new ones once the PR is complete.

To finish the PR, I still need to address the points with check boxes above. I made the PR ready for review to get feedback/opinions on these implementation details, but we can turn it back to draft to avoid confusion. If there are no preferences regarding the checklist above, I'll tackle those tasks to the best of my knowledge and we can then discuss it in a final review.

[bjfultn]

I think you should choose one nested sampler implementation and run with it. I don't think its necessary to support multiple implementations.

I think it would be good to have some nested sampler documentation and a tutorial before deploying this to production. In that documentation there should be some explanation about the advantages and disadvantages of using nested sampling over differential evolution and the situations where its appropriate.

I like your ideas for priors but I have two comments, 1) We should not remove or drastically change the way the existing priors. Backwards compatibility is important. You should add new priors where necessary, even if they are sort of duplicates of ones we have already. and 2) Make sure that it is made clear in the tutorial the importance of appropriate priors when using nested sampling. I think that it would be good to run the check_proper_priors() method just before nested sampling starts and have it error out with an explanation to the user that they need to make adjustments to their priors. I don't think we should adjust our existing priors to work with nested sampling if they don't already.