-
Notifications
You must be signed in to change notification settings - Fork 3
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
new sampler: drghmc #39
Conversation
Codecov Report
@@ Coverage Diff @@
## main #39 +/- ##
==========================================
+ Coverage 98.01% 98.59% +0.57%
==========================================
Files 11 12 +1
Lines 302 426 +124
==========================================
+ Hits 296 420 +124
Misses 6 6
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to start a review, but I'd be much more comfortable if @WardBrian or @jsoules could chime in on the Python and hopefully @modichirag will chime in on the algrorithm.
Sorry there are so many comments, but given this is your first PR, a lot of this stuff's coming up for the first time. Most of my comments are on doc and doc style. Usually you want the doc to be thorough enough to suggest tests.
You are going to need to add a bunch more unit tests to cover all the code. You really want to get this up to 100% test coverage including testing all the exceptional edge cases are throwing the right type of exception.
bayes_kit/drghmc.py
Outdated
|
||
detailed_balance = ( | ||
(logp_prop - logp_cur) | ||
+ (hastings_prop - hastings_cur) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure this is the right way around? Usually the density ratio and Hastings corrections are reversed in numerator and denominator.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure this is the right away around.
These lines of code implement the equation below, taken from your paper with Chirag. The key thing to note is that
Thus I match my code to the paper's equation:
-
logp_prop
=$\pi(y)$ -
logp_cur
=$\pi(x)$ -
hastings_prop
=$\prod_i [1 - \widetilde{\alpha}_i(y) ]$ -
hastings_cur
=$\prod_i [1 - \widetilde{\alpha}_i(x) ]$
bayes_kit/drghmc.py
Outdated
detailed_balance = ( | ||
(logp_prop - logp_cur) | ||
+ (hastings_prop - hastings_cur) | ||
+ (pdr_prop - pdr_cur) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[question]
Why is the probabilistic delayed rejection a difference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The equation below is the acceptance probability for probabilistic delayed rejection, taken from your paper with Chirag. In it,
Afte rejection, another proposal is made with probability
This acceptance probability includes a term in the numerator and denominator,
Thanks for the (super detailed!) feedback. I plan to:
FYI: over the next few weeks I will be prioritizing my actual research project so progress on these changes will be a bit slower. However, I am still excited to continue working on this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not to beat up on you further, but here's some additional notes. (I started this last night, apologies for anything repetitive/inconsistent.)
Feel free to let me know if you'd like clarifications or suggestions for anything!
I have addressed every comment by (1) resolving it after incorporating the feedback or (2) responding with a question or clarifying what I meant. Feel free to resolve the comment if, after my response, there is nothing left to discuss. A few more questions:
|
1a. theta and rho are fine with me The point is that if we have draws of multiple variables, we can throw some of the variables away to get marginal draws from the remaining variable. Usually we only care about the theta draws for downstream Bayesian inference. (theta, rho) is just the phase space (no "extended") and it's conventional to just use the pair and not try to reduce to a single variable.
|
All comments are addressed, code coverage is 100%, everything is properly formatted and typed (thanks to @WardBrian for help on this) and all tests are passing (except for specific functions in test_iat or test_drghmc that sometimes fails depending on the rng seed). I would love some more feedback: what else is needed for this PR to be merged? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, Gilad:
Given this is your first big PR, I went at it pretty hard in terms of how to formulate documentation. This is a lot of little changes, but none of them really touch code.
I'm just listing this as a Comment so that you don't need my approval to merge, but I'm happy to look at again if you'd like more feedback.
For external reinforcement of the ideas I'm trying to lay out, you can see Google's doc guide for Python: https://google.github.io/styleguide/pyguide.html#s3.8-comments-and-docstrings
A couple general questions/notes:
|
My two cents:
I think 88 characters is good for code and comments
I tend to focus more on it being one (preferably simple) sentence rather than exactly one line. I think the spirit of the guideline is just that there should be a summary to start |
…ce(), rename stepsizes to step_sizes, rename stepcounts to step_counts, change list type to sequence type.
Yesterday I met with @WardBrian (huge thank you!) to finalize some changes, summarized below, that address the remaining comments from @bob-carpenter :
I am now formatting the code + updating my tests. Afterwards, can @bob-carpenter review it one last time to confirm it is ready to merge? |
Yes, happy to review. Just let me know when it's ready. This is something where it's probably good for both me and @WardBrian to review for the sampler and Python style respectively. |
Quick question: for typing reasons, In the documentation should I refer to these as lists or sequences? The term list is simple to understand, but the term sequence is more technically precise. For example, should the error message read "expected |
I would use "sequence" in the written doc (not capitalized---common nouns are never capitalized in English). The type will show up in the doc as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When @gil2rok and I sat down to discuss the remaining issues we already discussed the Python style (e.g. #42).
The few comments I think I would leave at this point end up going against some of the things @bob-carpenter suggested earlier, so I am happy to accept this PR if he is and have a separate discussion on certain conventions later, since they're more about the entire repo than this PR
(@gil2rok : Your tests are raising a type error currently, which should probably be fixed before actually merging 😉 ) |
@WardBrian I am aware of the type issues! I am fixing them on my local machine and also updating the tests. I should push these changes to the repo later today! |
@WardBrian says:
@WardBrian is better than me at Python, so if he has conflicting advice w.r.t. Python, you should go with his suggestions. |
Tests are updated and passing (except for stochasticity that makes them occasionally fail). All files are properly formatted, code coverage is 100%, and all comments are addressed. @WardBrian: are there any Python style changes you would recommend, as per Bob's comment above? If not, is there anything else to do before merging this pull request? |
I am happy with the PR as it stands now. The things I have in mind are more about conventions around e.g. input checking or error handling that would apply to both this but also the existing code in the repo. I'd like to discuss it (at some point), but a follow on PR would be necessary in either case (either to align the rest of the repo to what was done here, or to adjust this code to whatever we decide) |
Very excited the pull request was merged! @bob-carpenter We should also change the README to include DRGHMC. Is it all right if I make that change? |
Yes, please do change the README. You can just push that w/o review. |
Implemented sampler for (Probabilistic) Delayed Rejection Generalized HMC with basic test.
This pull request is a cleaner version of my previous pull request #38 , which contained a messy commit history.