Esiste una tecnica standard per il debug dei programmi MCMC?


11

Il debug dei programmi MCMC è notoriamente difficile. La difficoltà sorge a causa di diversi problemi, alcuni dei quali sono:

(a) Natura ciclica dell'algoritmo

Disegniamo in modo iterativo parametri condizionali su tutti gli altri parametri. Pertanto, se un'implementazione non funziona correttamente, è difficile isolare il bug poiché il problema può trovarsi ovunque nel campionatore iterativo.

(b) La risposta corretta non è necessariamente conosciuta.

Non abbiamo modo di dire se abbiamo raggiunto la convergenza. In una certa misura ciò può essere mitigato testando il codice su dati simulati.

Alla luce dei problemi di cui sopra, mi chiedevo se esiste una tecnica standard che può essere utilizzata per il debug dei programmi MCMC.

modificare

Volevo condividere l'approccio che uso per eseguire il debug dei miei programmi. Ovviamente, faccio tutte le cose che PeterR ha menzionato. Oltre a questi, eseguo i seguenti test utilizzando dati simulati:

  1. Avviare tutti i parametri dai valori reali e vedere se il campionatore differisce troppo dai valori reali.

  2. Ho flag per ogni parametro nel mio campionatore iterativo che determina se sto disegnando quel parametro nel campionatore iterativo. Ad esempio, se un flag 'gen_param1' è impostato su true, allora traggo 'param1' dal suo condizionale completo nel campionatore iterativo. Se questo è impostato su false, allora 'param1' è impostato sul suo valore vero.

Una volta terminato di scrivere il campionatore, collaudo il programma usando la seguente ricetta:

  • Impostare il flag di generazione per un parametro su true e tutto il resto su false e valutare la convergenza rispetto al valore vero.
  • Impostare il flag di generazione per un altro parametro insieme al primo e valutare nuovamente la convergenza.

I passaggi precedenti sono stati incredibilmente utili per me.

Risposte:


10

Pratica di programmazione standard:

  • durante il debug eseguire la simulazione con fonti fisse di casualità (ovvero lo stesso seed) in modo che eventuali modifiche siano dovute a modifiche del codice e non a numeri casuali diversi.
  • prova il tuo codice su un modello (o più modelli) in cui è nota la risposta.
  • adottare buone abitudini di programmazione in modo da introdurre meno bug.
  • pensa molto e a lungo alle risposte che ottieni, se hanno senso, ecc.

Ti auguro buona fortuna e tanto caffè!


3

Ho un aneddoto deprimente e non molto specifico da condividere qui. Ho trascorso un po 'di tempo come collaboratore di un ricercatore statistico di MT. Se vuoi vedere un modello davvero grande, complesso, non cercare oltre.

Mi stava sottoponendo al bootcamp della PNL per suo divertimento. Sono, in generale, il tipo di programmatore che vive e muore dal test unitario e dal debugger. Da giovane alla Symbolics, sono stato colpito dall'aforisma, "la programmazione sta eseguendo il debug di un buffer editor vuoto". (Un po 'come allenare un modello perceptron.)

Quindi, gli ho chiesto: "Come testare ed eseguire il debug di questa roba." La sua risposta è stata: "Lo capisci bene la prima volta. Lo pensi attentamente (nel suo caso, spesso sulla carta) molto attentamente, e lo codice molto attentamente. Perché quando sbagli, le possibilità di isolare il problema sono molto magro."


Ho già sentito questo aneddoto (forse anche da te?). Mi ha colpito a casa, e dalla prima volta che l'ho sentito, si è avverato in più occasioni (cioè la difficoltà di isolare il problema).
Redmoskito

3

Buoni consigli nella risposta di PeterR; Non ho ulteriori suggerimenti per il debug effettivo, ma ho trovato un procedimento molto utile per verificare se il tuo codice potrebbe avere un bug. È descritto in questo documento:

http://pubs.amstat.org/doi/abs/10.1198/016214504000001132

In sostanza l'idea è di avere due simulazioni: una è la tua MCMC per inferire (presumibilmente) i parametri del tuo modello. Il secondo simulatore campiona semplicemente i parametri del precedente. Generano dati dai parametri di entrambi i simulatori e calcolano una statistica di prova confrontando le distribuzioni congiunte di parametri e dati. Se il codice MCMC campiona correttamente i parametri dal posteriore, la statistica del test avrà una distribuzione di N (0,1). È disponibile il codice per il calcolo della statistica del test.


Un approccio correlato può essere trovato in Cook et al. (2006; stat.columbia.edu/~gelman/research/published/… ). Ho usato l'approccio di Cook et al. In due occasioni e sono rimasto colpito dai risultati. Non ho usato l'approccio di Geweke, ma secondo Cook et al. "L'approccio di Geweke ha il vantaggio di dover eseguire solo una replica ... Uno svantaggio è che richiede un'alterazione del software da testare". Dicono anche che l'approccio di Geweke richiede che i priori abbiano una varianza finita, mentre i loro non lo fanno.
jmtroos
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.