Confuso con le variazioni MCMC Metropolis-Hastings: Passeggiata casuale, Passeggiata non casuale, Indipendente, Metropoli

Nel corso delle ultime settimane ho cercato di capire l'algoritmo (i) MCMC e Metropolis-Hastings. Ogni volta che penso di capirlo mi rendo conto di sbagliarmi. La maggior parte degli esempi di codice che trovo online implementano qualcosa che non è coerente con la descrizione. vale a dire: dicono di implementare Metropolis-Hastings ma in realtà implementano metropoli a piedi casuali. Altri (quasi sempre) saltano silenziosamente l'implementazione del rapporto di correzione di Hastings perché stanno usando una distribuzione simmetrica della proposta. In realtà, non ho trovato un singolo esempio semplice che calcola il rapporto finora. Questo mi rende ancora più confuso. Qualcuno può darmi esempi di codice (in qualsiasi lingua) di quanto segue:

• Algoritmo Metropolis-Hastings Walk non casuale con calcolo del rapporto di correzione di Hastings (anche se questo finirà per essere 1 quando si utilizza una distribuzione di proposta simmetrica).
• Algoritmo Vanilla Random Walk Metropolis-Hastings.
• Algoritmo Vanilla Independent Metropolis-Hastings.

Non c'è bisogno di fornire gli algoritmi Metropolis perché, se non sbaglio, l'unica differenza tra Metropolis e Metropolis-Hastings è che i primi campionano sempre da una distribuzione simmetrica e quindi non hanno il rapporto di correzione di Hastings. Non è necessario fornire una spiegazione dettagliata degli algoritmi. Capisco le basi ma sono un po 'confuso con tutti i diversi nomi per le diverse varianti dell'algoritmo Metropolis-Hastings ma anche con il modo in cui implementate praticamente il rapporto di correzione di Hastings sull'MH Vanilla non-random-walk. Per favore, non copiare i link incolla che rispondono parzialmente alle mie domande perché molto probabilmente le ho già viste. Quei legami mi hanno portato a questa confusione. Grazie.

Ecco qui - tre esempi. Ho reso il codice molto meno efficiente di quanto sarebbe in una vera applicazione per rendere la logica più chiara (spero).

# We'll assume estimation of a Poisson mean as a function of x
x <- runif(100)
y <- rpois(100,5*x)  # beta = 5 where mean(y[i]) = beta*x[i]

# Prior distribution on log(beta): t(5) with mean 2 
# (Very spread out on original scale; median = 7.4, roughly)
log_prior <- function(log_beta) dt(log_beta-2, 5, log=TRUE)

# Log likelihood
log_lik <- function(log_beta, y, x) sum(dpois(y, exp(log_beta)*x, log=TRUE))

# Random Walk Metropolis-Hastings 
# Proposal is centered at the current value of the parameter

rw_proposal <- function(current) rnorm(1, current, 0.25)
rw_p_proposal_given_current <- function(proposal, current) dnorm(proposal, current, 0.25, log=TRUE)
rw_p_current_given_proposal <- function(current, proposal) dnorm(current, proposal, 0.25, log=TRUE)

rw_alpha <- function(proposal, current) {
   # Due to the structure of the rw proposal distribution, the rw_p_proposal_given_current and
   # rw_p_current_given_proposal terms cancel out, so we don't need to include them - although
   # logically they are still there:  p(prop|curr) = p(curr|prop) for all curr, prop
   exp(log_lik(proposal, y, x) + log_prior(proposal) - log_lik(current, y, x) - log_prior(current))
}

# Independent Metropolis-Hastings
# Note: the proposal is independent of the current value (hence the name), but I maintain the
# parameterization of the functions anyway.  The proposal is not ignorable any more
# when calculation the acceptance probability, as p(curr|prop) != p(prop|curr) in general.

ind_proposal <- function(current) rnorm(1, 2, 1) 
ind_p_proposal_given_current <- function(proposal, current) dnorm(proposal, 2, 1, log=TRUE)
ind_p_current_given_proposal <- function(current, proposal) dnorm(current, 2, 1, log=TRUE)

ind_alpha <- function(proposal, current) {
   exp(log_lik(proposal, y, x)  + log_prior(proposal) + ind_p_current_given_proposal(current, proposal) 
       - log_lik(current, y, x) - log_prior(current) - ind_p_proposal_given_current(proposal, current))
}

# Vanilla Metropolis-Hastings - the independence sampler would do here, but I'll add something
# else for the proposal distribution; a Normal(current, 0.1+abs(current)/5) - symmetric but with a different
# scale depending upon location, so can't ignore the proposal distribution when calculating alpha as
# p(prop|curr) != p(curr|prop) in general

van_proposal <- function(current) rnorm(1, current, 0.1+abs(current)/5)
van_p_proposal_given_current <- function(proposal, current) dnorm(proposal, current, 0.1+abs(current)/5, log=TRUE)
van_p_current_given_proposal <- function(current, proposal) dnorm(current, proposal, 0.1+abs(proposal)/5, log=TRUE)

van_alpha <- function(proposal, current) {
   exp(log_lik(proposal, y, x)  + log_prior(proposal) + ind_p_current_given_proposal(current, proposal) 
       - log_lik(current, y, x) - log_prior(current) - ind_p_proposal_given_current(proposal, current))
}


# Generate the chain
values <- rep(0, 10000) 
u <- runif(length(values))
naccept <- 0
current <- 1  # Initial value
propfunc <- van_proposal  # Substitute ind_proposal or rw_proposal here
alphafunc <- van_alpha    # Substitute ind_alpha or rw_alpha here
for (i in 1:length(values)) {
   proposal <- propfunc(current)
   alpha <- alphafunc(proposal, current)
   if (u[i] < alpha) {
      values[i] <- exp(proposal)
      current <- proposal
      naccept <- naccept + 1
   } else {
      values[i] <- exp(current)
   }
}
naccept / length(values)
summary(values)

Per il campionatore di vaniglia, otteniamo:

> naccept / length(values)
[1] 0.1737
> summary(values)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
  2.843   5.153   5.388   5.378   5.594   6.628 

che è una bassa probabilità di accettazione, ma comunque ... mettere a punto la proposta sarebbe di aiuto o adottarne una diversa. Ecco i risultati della proposta di camminata casuale:

> naccept / length(values)
[1] 0.2902
> summary(values)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
  2.718   5.147   5.369   5.370   5.584   6.781 

Risultati simili, come si potrebbe sperare, e una migliore probabilità di accettazione (puntando a ~ 50% con un parametro).

E, per completezza, il campionatore di indipendenza:

> naccept / length(values)
[1] 0.0684
> summary(values)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
  3.990   5.162   5.391   5.380   5.577   8.802 

Poiché non si "adatta" alla forma del posteriore, tende ad avere la più bassa probabilità di accettazione ed è più difficile sintonizzarsi bene per questo problema.

Nota che in generale preferiremmo proposte con code più grasse, ma questo è un altro argomento.

Vedere:

$q()$${\bf x}$

L' articolo di Wikipedia è una buona lettura complementare. Come puoi vedere, Metropolis ha anche un "rapporto di correzione" ma, come detto sopra, Hastings ha introdotto una modifica che consente distribuzioni di proposte non simmetriche.

L'algoritmo Metropolis è implementato nel pacchetto R mcmcsotto il comando metrop().

Altri esempi di codice:

http://www.mas.ncl.ac.uk/~ndjw1/teaching/sim/metrop/

http://pcl.missouri.edu/jeff/node/322

http://darrenjw.wordpress.com/2010/08/15/metropolis-hastings-mcmc-algorithms/