¿Existe una técnica estándar para depurar programas MCMC?


11

La depuración de programas MCMC es notoriamente difícil. La dificultad surge debido a varios problemas, algunos de los cuales son:

(a) Naturaleza cíclica del algoritmo

Dibujamos iterativamente parámetros condicionales a todos los demás parámetros. Por lo tanto, si una implementación no funciona correctamente, es difícil aislar el error ya que el problema puede estar en cualquier parte del muestreador iterativo.

(b) La respuesta correcta no se conoce necesariamente.

No tenemos forma de saber si hemos logrado la convergencia. Hasta cierto punto, esto puede mitigarse probando el código en datos simulados.

A la luz de los problemas anteriores, me preguntaba si existe una técnica estándar que pueda usarse para depurar programas MCMC.

Editar

Quería compartir el enfoque que uso para depurar mis propios programas. Yo, por supuesto, hago todas las cosas que PeterR mencionó. Además de eso, realizo las siguientes pruebas utilizando datos simulados:

  1. Inicie todos los parámetros a partir de valores verdaderos y vea si la muestra diverge demasiado de los valores verdaderos.

  2. Tengo banderas para cada parámetro en mi muestra iterativa que determina si estoy dibujando ese parámetro en la muestra iterativa. Por ejemplo, si un indicador 'gen_param1' se establece en verdadero, entonces dibujo 'param1' de su condicional completo en el muestreador iterativo. Si esto se establece en falso, entonces 'param1' se establece en su valor verdadero.

Una vez que termine de escribir la muestra, pruebo el programa usando la siguiente receta:

  • Establezca el indicador de generación para un parámetro en verdadero y todo lo demás en falso y evalúe la convergencia con respecto al valor verdadero.
  • Establezca el indicador de generación para otro parámetro junto con el primero y nuevamente evalúe la convergencia.

Los pasos anteriores me han sido increíblemente útiles.

Respuestas:


10

Práctica de programación estándar:

  • al depurar, ejecute la simulación con fuentes fijas de aleatoriedad (es decir, la misma semilla) para que cualquier cambio se deba a cambios en el código y no a números aleatorios diferentes.
  • pruebe su código en un modelo (o varios modelos) donde se conoce la respuesta.
  • adopta buenos hábitos de programación para que introduzcas menos errores.
  • Piensa mucho y mucho tiempo en las respuestas que obtienes, si tienen sentido, etc.

¡Te deseo buena suerte y mucho café!


3

Tengo una anécdota deprimente y no muy específica para compartir aquí. Pasé algún tiempo como compañero de trabajo de un investigador estadístico de MT. Si quieres ver un modelo realmente grande y complejo, no busques más.

Me estaba poniendo en el campo de entrenamiento de la PNL para su propia diversión. Soy, en general, el tipo de programador que vive y muere según la prueba de la unidad y el depurador. Cuando era joven en Symbolics, me sorprendió el aforismo: "la programación está depurando un búfer de editor vacío". (Algo así como entrenar un modelo de perceptrón).

Entonces, le pregunté, '¿cómo prueba y depura estas cosas?' Él respondió: "Lo has hecho bien la primera vez. Lo piensas detenidamente (en su caso, a menudo en papel) con mucho cuidado, y lo codificas con mucho cuidado. Porque cuando lo haces mal, las posibilidades de aislar el problema son muy delgado."


He escuchado esta anécdota antes (¿quizás también de usted?). Me llegó a casa, y desde que lo escuché por primera vez, se ha hecho realidad en múltiples ocasiones (es decir, la dificultad de aislar el problema).
redmoskito

3

Buenos consejos en la respuesta de PeterR; No tengo más consejos para la depuración real, pero encontré un procedimiento muy útil para probar si su código podría tener un error. Se describe en este documento:

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

Esencialmente, la idea es tener dos simulaciones: una es su MCMC para inferir (presumiblemente) los parámetros de su modelo. El segundo simulador simplemente muestrea parámetros del anterior. Generan datos a partir de los parámetros de ambos simuladores y calculan una estadística de prueba que compara las distribuciones conjuntas de parámetros y datos. Si el código MCMC muestrea correctamente los parámetros de la parte posterior, entonces el estadístico de prueba tendrá una distribución de N (0,1). El código para calcular la estadística de prueba está disponible.


Un enfoque relacionado se puede encontrar en Cook et al. (2006; stat.columbia.edu/~gelman/research/published/… ). He utilizado el enfoque de Cook et al. En dos ocasiones, y me han impresionado los resultados. No he usado el enfoque de Geweke, pero según Cook et al., "El enfoque de Geweke tiene la ventaja de que solo se necesita realizar una replicación ... Una desventaja es que requiere alterar el software para ser probado". También dicen que el enfoque de Geweke requiere antecedentes con variación finita, mientras que el de ellos no.
jmtroos
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.