Verständnis von Metropolis-Hastings mit asymmetrischer Angebotsverteilung


13

Ich habe versucht, den Metropolis-Hastings-Algorithmus zu verstehen, um einen Code zum Schätzen der Parameter eines Modells zu schreiben (dh f(x)=einx ). Laut Bibliographie hat der Metropolis-Hastings-Algorithmus die folgenden Schritte:

  • Generiere Y.tq(y|xt)
  • Xt+1={Y.t,mit wahrscheinlichkeitρ(xt,Y.t),xt,mit wahrscheinlichkeit1-ρ(xt,Y.t),

wobei ρ(x,y)=Mindest(f(y)f(x)q(x|y)q(y|x),1)

Wie möchte ich ein paar Fragen stellen:

  • Die Bibliographie besagt, dass wenn eine symmetrische Verteilung ist, das Verhältnis q ( x | y ) / q ( y | x ) 1 wird und der Algorithmus Metropolis heißt. Ist das korrekt? Der einzige Unterschied zwischen Metropolis und Metropolis-Hastings besteht darin, dass die erste eine symmetrische Verteilung verwendet. Was ist mit "Random Walk" Metropolis (-Hastings)? Wie unterscheidet es sich von den anderen beiden?qq(x|y)/q(y|x)
  • Der größte Teil des Beispielcodes, den ich online finde, verwendet eine Gaußsche Angebotsverteilung und daher ist ρ ( x , y ) = min ( f ( y ) / f ( x ) , 1 ) wobei f ( y ) / f ( x )qρ(x,y)=min(f(y)/f(x),1)f(y)/f(x)ist das Wahrscheinlichkeitsverhältnis. Was ist, wenn die Angebotsverteilung eine Poisson-Verteilung ist? Ich denke, ich verstehe rational, warum dieses Verhältnis bei Verwendung einer asymmetrischen Verteilung nicht zu 1 wird, aber ich bin nicht ganz sicher, ob ich es mathematisch verstehe oder wie ich es mit Code implementieren soll. Könnte mir jemand einen einfachen Code (C, Python, R, Pseudo-Code oder was auch immer Sie bevorzugen) für den Metropolis-Hastings-Algorithmus mit einer nicht symmetrischen Angebotsverteilung geben?

1
Ich habe mich gerade an einen ausgezeichneten Blog-Beitrag zu einem verwandten Thema erinnert. Vielleicht hilft das: darrenjw.wordpress.com/2012/06/04/…
joint_p

Antworten:


19

Die Bibliographie besagt, dass wenn q eine symmetrische Verteilung ist, das Verhältnis q (x | y) / q (y | x) 1 wird und der Algorithmus Metropolis heißt. Ist das korrekt?

Ja das ist korrekt. Der Metropolis-Algorithmus ist ein Sonderfall des MH-Algorithmus.

Was ist mit "Random Walk" Metropolis (-Hastings)? Wie unterscheidet es sich von den anderen beiden?

Bei einem zufälligen Durchgang wird die Angebotsverteilung nach jedem Schritt auf den Wert neu zentriert, der zuletzt von der Kette generiert wurde. Im Allgemeinen ist die Angebotsverteilung bei einem zufälligen Spaziergang Gauß'sch. In diesem Fall erfüllt dieser zufällige Spaziergang die Symmetrieanforderung und der Algorithmus ist Metropolis. Ich nehme an, Sie könnten einen "Pseudo" -Zufallsrundgang mit einer asymmetrischen Verteilung durchführen, der dazu führen würde, dass die Vorschläge zu stark in die entgegengesetzte Richtung des Versatzes driften (eine linksversetzte Verteilung würde die Vorschläge nach rechts begünstigen). Ich bin nicht sicher, warum Sie dies tun würden, aber Sie könnten und es wäre ein Metropolis-Hastings-Algorithmus (dh erfordern Sie den zusätzlichen Verhältnis-Ausdruck).

Wie unterscheidet es sich von den anderen beiden?

In einem nicht zufälligen Walk-Algorithmus sind die Angebotsverteilungen festgelegt. In der Zufallsvariante ändert sich das Zentrum der Angebotsverteilung bei jeder Iteration.

Was ist, wenn die Angebotsverteilung eine Poisson-Verteilung ist?

Dann müssen Sie MH anstelle von Metropolis verwenden. Vermutlich wäre dies ein Beispiel für eine diskrete Verteilung, ansonsten würden Sie keine diskrete Funktion verwenden, um Ihre Vorschläge zu generieren.

In jedem Fall möchten Sie, wenn die Stichprobenverteilung abgeschnitten ist oder Sie die Abweichung bereits kennen, wahrscheinlich eine asymmetrische Stichprobenverteilung verwenden und müssen daher Metropolen-Hastings verwenden.

Könnte mir jemand ein einfaches Code-Beispiel geben (C, Python, R, Pseudo-Code oder was auch immer Sie bevorzugen)?

Hier ist die Metropole:

Metropolis <- function(F_sample # distribution we want to sample
                      , F_prop  # proposal distribution 
                      , I=1e5   # iterations
               ){
  y = rep(NA,T)
  y[1] = 0    # starting location for random walk
  accepted = c(1)

  for(t in 2:I)    {
    #y.prop <- rnorm(1, y[t-1], sqrt(sigma2) ) # random walk proposal
    y.prop <- F_prop(y[t-1]) # implementation assumes a random walk. 
                             # discard this input for a fixed proposal distribution

    # We work with the log-likelihoods for numeric stability.
    logR = sum(log(F_sample(y.prop))) -
           sum(log(F_sample(y[t-1])))    

    R = exp(logR)

    u <- runif(1)        ## uniform variable to determine acceptance
    if(u < R){           ## accept the new value
      y[t] = y.prop
      accepted = c(accepted,1)
    }    
    else{
      y[t] = y[t-1]      ## reject the new value
      accepted = c(accepted,0)
    }    
  }
  return(list(y, accepted))
}

Lassen Sie uns versuchen, mit diesem Beispiel eine bimodale Verteilung zu erstellen. Lassen Sie uns zuerst sehen, was passiert, wenn wir einen zufälligen Spaziergang für unseren Propsal verwenden:

set.seed(100)

test = function(x){dnorm(x,-5,1)+dnorm(x,7,3)}

# random walk
response1 <- Metropolis(F_sample = test
                       ,F_prop = function(x){rnorm(1, x, sqrt(0.5) )}
                      ,I=1e5
                       )
y_trace1 = response1[[1]]; accpt_1 = response1[[2]]
mean(accpt_1) # acceptance rate without considering burn-in
# 0.85585   not bad

# looks about how we'd expect
plot(density(y_trace1))
abline(v=-5);abline(v=7) # Highlight the approximate modes of the true distribution

Bildbeschreibung hier eingeben

Versuchen wir nun, Stichproben mit einer festen Angebotsverteilung zu erstellen und sehen, was passiert:

response2 <- Metropolis(F_sample = test
                            ,F_prop = function(x){rnorm(1, -5, sqrt(0.5) )}
                            ,I=1e5
                       )

y_trace2 = response2[[1]]; accpt_2 = response2[[2]]
mean(accpt_2) # .871, not bad

Das sieht auf den ersten Blick in Ordnung aus, aber wenn wir uns die posteriore Dichte ansehen ...

plot(density(y_trace2))

Bildbeschreibung hier eingeben

wir werden sehen, dass es bei einem lokalen Maximum vollständig stecken bleibt. Dies ist nicht ganz überraschend, da wir unsere Angebotsverteilung dort tatsächlich zentriert haben. Dasselbe passiert, wenn wir dies auf den anderen Modus zentrieren:

response2b <- Metropolis(F_sample = test
                        ,F_prop = function(x){rnorm(1, 7, sqrt(10) )}
                        ,I=1e5
)

plot(density(response2b[[1]]))

Wir können versuchen, unseren Vorschlag zwischen den beiden Modi fallen zu lassen, aber wir müssen die Varianz wirklich hoch einstellen, um eine Chance zu haben, einen von beiden zu erkunden

response3 <- Metropolis(F_sample = test
                        ,F_prop = function(x){rnorm(1, -2, sqrt(10) )}
                        ,I=1e5
)
y_trace3 = response3[[1]]; accpt_3 = response3[[2]]
mean(accpt_3) # .3958! 

Beachten Sie, dass die Auswahl des Zentrums unserer Angebotsverteilung einen erheblichen Einfluss auf die Akzeptanzrate unseres Samplers hat.

plot(density(y_trace3))

Bildbeschreibung hier eingeben

plot(y_trace3) # we really need to set the variance pretty high to catch 
               # the mode at +7. We're still just barely exploring it

Wir bleiben immer noch im engeren der beiden Modi stecken. Lassen Sie uns versuchen, dies direkt zwischen den beiden Modi abzulegen.

response4 <- Metropolis(F_sample = test
                        ,F_prop = function(x){rnorm(1, 1, sqrt(10) )}
                        ,I=1e5
)
y_trace4 = response4[[1]]; accpt_4 = response4[[2]]

plot(density(y_trace1))
lines(density(y_trace4), col='red')

Bildbeschreibung hier eingeben

Schließlich nähern wir uns dem, wonach wir gesucht haben. Wenn wir den Sampler lange genug laufen lassen, können wir theoretisch eine repräsentative Stichprobe aus jeder dieser Angebotsverteilungen erhalten, aber der Zufallsrundgang ergab sehr schnell eine brauchbare Stichprobe, und wir mussten unser Wissen darüber, wie der Posterior angenommen wurde, nutzen um die festen Stichprobenverteilungen auf ein brauchbares Ergebnis abzustimmen (was wir allerdings noch nicht ganz wissen)y_trace4 ).

Ich versuche es später mit einem Beispiel für Metropolen-Hastings. Sie sollten ziemlich leicht verstehen, wie Sie den obigen Code ändern können, um einen Metropolis-Hastings-Algorithmus zu erstellen (Hinweis: Sie müssen nur das zusätzliche Verhältnis zur logRBerechnung hinzufügen ).


Geniale Antwort! Ich danke dir sehr! In meinem Fall habe ich ein 6-7-Parametermodell und ich habe keine Ahnung, wie die hintere Verteilung aussehen könnte (aber sie könnte bimodal sein), da meine Datensätze manchmal völlig unterschiedlich sind. Basierend auf dem, was Sie gesagt haben, kann ich entweder Metropolis (-Hastings) mit einer großen Abweichung in der Angebotsverteilung oder Random Walk Metropolis (-Hastings) mit einer kleinen Abweichung in der Angebotsverteilung verwenden. Unter keinen besonderen Umständen sollte die zweite Lösung schneller zur Zielverteilung konvergieren. Richtig?
AstrOne

Jetzt bezogen auf den Metropolis-Hastings-Code, den ich ersetzen wollte R=exp(logR): R=exp(logR)*(dnorm(y[t-1],y.prop,my_sigma)/dnorm(y.prop,y[t-1],my_sigma))für zufällige und nicht zufällige Lauf-MH. Ist das korrekt?
AstrOne

1
Grundsätzlich, aber wie ich im Code der Metropole erwähne: Sie möchten Ihre Berechnungen im Protokollbereich ausführen. Likelihood-Berechnungen werden in der Regel mit sehr kleinen Werten ausgeführt, sodass Sie im Allgemeinen viel bessere Ergebnisse erzielen, wenn Sie Logarithmen hinzufügen und Ihre Ergebnisse potenzieren, als wenn Sie Rohwerte miteinander multiplizieren.
David Marx

1
Sie müssen sich keine Gedanken über den aktuellen Zustand der Kette machen (d. H yt-1) wenn Sie eine feste Angebotsverteilung verwenden, weil: q(yt|yt-1)=q(yt). Eine feste Angebotsverteilung erzeugt unabhängige Angebote. Wir nehmenyt-1Berücksichtigung im Metropolenverhältnis.
David Marx

1
Sie geben an, dass "In einem Algorithmus für nicht zufälliges Gehen die Angebotsverteilungen fest sind. In der Variante für zufälliges Gehen ändert sich das Zentrum der Angebotsverteilung bei jeder Iteration", was nicht korrekt ist. MH-Versionen, die keine zufälligen Spaziergänge sind, enthalten meist Vorschläge, die vom aktuellen Status der Markov-Kette abhängen und manchmal sogar auf diesen Status zentriert sind. Ein wichtiges Beispiel ist der Langevin-MCMC-Algorithmus. Wenn der Vorschlag festgelegt ist, handelt es sich um einen unabhängigen MH-Algorithmus .
Xi'an,
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.