Existe-t-il une technique standard pour déboguer les programmes MCMC?


11

Le débogage des programmes MCMC est notoirement difficile. La difficulté survient en raison de plusieurs problèmes dont certains sont:

a) Nature cyclique de l'algorithme

Nous dessinons itérativement des paramètres conditionnels à tous les autres paramètres. Ainsi, si une implémentation ne fonctionne pas correctement, il est difficile d'isoler le bogue car le problème peut se trouver n'importe où dans l'échantillonneur itératif.

b) La bonne réponse n'est pas nécessairement connue.

Nous n'avons aucun moyen de dire si nous avons atteint la convergence. Dans une certaine mesure, cela peut être atténué en testant le code sur des données simulées.

À la lumière des problèmes ci-dessus, je me demandais s'il existe une technique standard qui peut être utilisée pour déboguer les programmes MCMC.

Éditer

Je voulais partager l'approche que j'utilise pour déboguer mes propres programmes. Je fais, bien sûr, toutes les choses que PeterR a mentionnées. En dehors de ceux-ci, j'effectue les tests suivants en utilisant des données simulées:

  1. Démarrez tous les paramètres à partir des valeurs vraies et voyez si l'échantillonneur diverge trop loin des valeurs vraies.

  2. J'ai des drapeaux pour chaque paramètre dans mon échantillonneur itératif qui détermine si je dessine ce paramètre dans l'échantillonneur itératif. Par exemple, si un indicateur 'gen_param1' est défini sur true, je dessine 'param1' de son conditionnel complet dans l'échantillonneur itératif. Si ce paramètre est défini sur false, «param1» est défini sur sa valeur vraie.

Une fois que j'ai fini d'écrire l'échantillonneur, je teste le programme en utilisant la recette suivante:

  • Définissez l'indicateur de génération pour un paramètre sur true et tout le reste sur false et évaluez la convergence par rapport à la valeur vraie.
  • Définissez l'indicateur de génération pour un autre paramètre conjointement avec le premier et évaluez à nouveau la convergence.

Les étapes ci-dessus m'ont été extrêmement utiles.

Réponses:


10

Pratique de programmation standard:

  • lors du débogage, exécutez la simulation avec des sources fixes de caractère aléatoire (c'est-à-dire la même valeur de départ) afin que tout changement soit dû à des changements de code et non à des nombres aléatoires différents.
  • essayez votre code sur un modèle (ou plusieurs modèles) dont la réponse EST connue.
  • adoptez de bonnes habitudes de programmation afin d'introduire moins de bogues.
  • réfléchissez très longuement aux réponses que vous obtenez, si elles ont un sens, etc.

Je vous souhaite bonne chance et beaucoup de café!


3

J'ai une anecdote déprimante et peu spécifique à partager ici. J'ai passé un certain temps en tant que collègue d'un chercheur statistique MT. Si vous voulez voir un modèle vraiment grand et complexe, ne cherchez pas plus loin.

Il me faisait passer le bootcamp de la PNL pour son propre amusement. Je suis, en général, le genre de programmeur qui vit et meurt par le test unitaire et le débogueur. En tant que jeune chez Symbolics, j'ai été frappé par l'aphorisme, «la programmation débogue un tampon d'édition vide». (Un peu comme entraîner un modèle de perceptron.)

Alors, je lui ai demandé: «Comment testez-vous et déboguez-vous ces trucs». Il a répondu: "Vous avez bien compris la première fois. Vous y réfléchissez très attentivement (dans son cas, souvent sur papier) et vous le codez très soigneusement. Parce que lorsque vous vous trompez, les chances d'isoler le problème sont très mince."


J'ai déjà entendu cette anecdote (peut-être aussi de votre part?). Cela m'a frappé chez moi, et depuis que je l'ai entendu pour la première fois, cela s'est produit à plusieurs reprises (c'est-à-dire la difficulté d'isoler le problème).
redmoskito

3

Bons conseils dans la réponse de PeterR; Je n'ai pas d'autres conseils pour le débogage, mais j'ai trouvé une procédure très utile pour tester si votre code pouvait avoir un bogue. Il est décrit dans cet article:

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

L'idée est essentiellement d'avoir deux simulations: l'une étant votre MCMC pour déduire (vraisemblablement) les paramètres de votre modèle. Le deuxième simulateur échantillonne simplement les paramètres de l'ancien. Ils génèrent des données à partir des paramètres des deux simulateurs et calculent une statistique de test comparant les distributions conjointes des paramètres et des données. Si le code MCMC échantillonne correctement les paramètres de la partie postérieure, alors la statistique de test aura une distribution de N (0,1). Le code pour calculer la statistique de test est disponible.


Une approche connexe peut être trouvée dans Cook et al. (2006; stat.columbia.edu/~gelman/research/published/… ). J'ai utilisé l'approche de Cook et al. À deux reprises et j'ai été impressionné par les résultats. Je n'ai pas utilisé l'approche de Geweke, mais selon Cook et al., "L'approche de Geweke a l'avantage qu'une seule réplication doit être effectuée ... Un inconvénient est qu'elle nécessite de modifier le logiciel à tester." Ils disent également que l'approche de Geweke nécessite des a priori à variance finie, contrairement à la leur.
jmtroos
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.