-
Notifications
You must be signed in to change notification settings - Fork 2
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
Notes on LMH implementation #9
Comments
the only problem which cannot be avoided with single-site MH (and which The problem of having a sample with 0 probability is solved in Anglican 75 value (if (< (/ -1. 0.) log-p (/ 1. 0.)) value
76 ;; The retained value is not in support, resample
77 ;; the value from the prior. When the value is
78 ;; resampled, log-p is no longer valid, but log-p
79 ;; of a resampled value is ignored anyway (see
80 ;; `utility' below).
81 (sample* (:dist smp))) Which means that sometimes more than a single site is resampled, which is also true if the control flow of the program changes. It is safe. You can use any addressing for LMH, the only thing you should ensure to keep it sound is that different sample points at run time always get different addresses. Some sampling schemes will be more efficient than others, leading to more reuse and better acceptance rate, but any addressing giving distinct addresses is sound. Regarding acceptance rate and state transition. If you look at the paper by Wood etc A new approach to ..., then there is a derivation of acceptance rate for LMH, making clear that the acceptance rate depends on two transitions:
Because random database (the table of random choices) is collected and maintained between states, the current state reached from the next state is different from the current state reached from the previous-state. Hence, the code from line 93 on ensures that the transition probability is computed correctly by comparing the so-called 'utility' of the next state relative to the current state and of the current state relative to the next state. One trick here is that resampled values do not affect acceptance. This is somewhat unexpected but you can do the derivation and see for yourself. Therefore, utility (lines 133-139) is computed as the sum of log-weight (log-likelihood due to observe) and of log-likelihood of rescored variables only. So the steps to implement LMH, following the code in Anglican, would be
I think that two non-trivial things in the whole (rather short) implementation of LMH in Anglican are the reconstruction of current state from new-state (function 'prev-state') and the way the utility is computed. |
I also found my old notes from early days of developing the current Anglican code base (the notes are relative to Interpreted Anglican). This is the derivation of acceptance rate, which may either help or be misleading :-) but I think the derivation can be re-done easily. The notes mention m!. "m!" was the internal development name of the new version of Anglican (pronounced "embang", embedded anglican).
|
Provide notes about LMH implementation in Anglican and how it can be done in CPProb
The text was updated successfully, but these errors were encountered: