adaptive PTMCMC #10
adaptive PTMCMC #10
Conversation
bobverity
commented
Jan 10, 2025
bobverity
commented
- Implemented adaptive updates to w_prop_sd for each temperature
- Improved coupling swap acceptance calculation (via Rao–Blackwellization)
- Added user-input flags to set burn-in and sampling iterations
…ved swap acceptance calculation. Added user-input flags to set burn-in and sampling iterations
| @@ -24,127 +24,38 @@ MCMC::MCMC( | |||
| const Parameters& params, | |||
| const Model& model, | |||
| ProposalEngine& proposal_engine, | |||
| int n_burn_iters, | |||
There was a problem hiding this comment.
If we are passing these in as arguments, I wonder if they should just go into Parameters along with all the other parameters?
| MCMC::TemperatureLevel::TemperatureLevel() | ||
| : beta(0.0), | ||
| particle_ptr(NULL), | ||
| loglike(-9999), | ||
| logprior(-9999) | ||
| logprior(-9999), | ||
| w_prop_sd(1.0) |
There was a problem hiding this comment.
Do we need to pay attention at all to how we initialise the proposal standard deviation? I know we have also changed from the log-titre approach to the reflected normal approach and not sure what is a decent value. I guess the parameter will get moved towards the correct value by the adaptive updates, but probably we want to be vaguely in a good region in order to avoid wasting burn iterations?
| // Robbins-Monroe positive update | ||
| if (adaptive_on) { | ||
| temp_level.w_prop_sd = std::exp( std::log(temp_level.w_prop_sd) + (1.0 - params.target_acceptance) / sqrt(ix + 1.0) ); | ||
| temp_level.w_prop_sd = (temp_level.w_prop_sd > 1.0 ? 1.0 : temp_level.w_prop_sd); |
There was a problem hiding this comment.
I don't think we need the parenthesis around the ternary operator?
| } | ||
|
|
||
| swap_rate_cumul(j-1) += (A < 0.0 ? std::exp(A) : 1.0); |
There was a problem hiding this comment.
One question about this ... since we are computing exponential of the log acceptance probability, this becomes the "expected" acceptance rate, rather than the observed rate -- correct? Is this actually preferable than just recording the actually observed rate? The observed rate is noiser but that noise is meaningful as it reflects the number of actual updates. With a sufficient number of iterations, I guess the two approaches would converage?
| int n_burn_iters = 100; // Number of iterations in burn-in phase | ||
| int n_sample_iters = 900; // Number of iterations in sampling phase | ||
| int n_temps = 5; // Number of temperature levels for PT-MCMC | ||
| double target_acceptance = 0.44; // Target acceptance rate per MCMC rung |
There was a problem hiding this comment.
This maybe doesn't need to be a parameter, but could be a global constant? Or might we want to tune this?
