Open vandalt opened 11 months ago
Marking as ready for review, as I have WIP tutorials and I think the questions in the PR will determine the remaining development work.
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?
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.
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.
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:
Posterior
class. It iterates over free parameters and applies the inverse CDF of their prior to the unit cube.check_proper_priors()
method forPosterior
, performing some checks to make sure there are no "improper" priors, and that each parameter has only one prior.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:
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.check_proper_priors()
method is never run automatically for now. It could be run on everyprior_transform
call, integrated into anested_sampling.py
module, or documented clearly in the tutorial to let users run it just once before running the sampler.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:
ModifiedJeffeys
,HardBounds
, a log parametrization, etc.)se{cos}w
+EccentricityPrior
by a "unit disk" prior (see e.g. the exoplanet package)juliet
does with themodelOK
attribute I think)I'm open to any comments/suggestions about all of the above of course.
Thank you!