Existe uma técnica padrão para depurar programas MCMC?


11

A depuração de programas MCMC é notoriamente difícil. A dificuldade surge devido a vários problemas, alguns dos quais são:

a) Natureza cíclica do algoritmo

Iterativamente, desenhamos parâmetros condicionais para todos os outros parâmetros. Portanto, se uma implementação não estiver funcionando corretamente, é difícil isolar o bug, pois o problema pode estar em qualquer lugar no amostrador iterativo.

(b) A resposta correta não é necessariamente conhecida.

Não temos como saber se alcançamos convergência. Até certo ponto, isso pode ser atenuado testando o código em dados simulados.

À luz dos problemas acima, fiquei pensando se existe uma técnica padrão que possa ser usada para depurar programas do MCMC.

Editar

Eu queria compartilhar a abordagem usada para depurar meus próprios programas. Obviamente, faço todas as coisas que PeterR mencionou. Além desses, eu realizo os seguintes testes usando dados simulados:

  1. Inicie todos os parâmetros a partir de valores reais e veja se o amostrador diverge muito dos valores reais.

  2. Eu tenho sinalizadores para cada parâmetro no meu amostrador iterativo que determina se estou desenhando esse parâmetro no amostrador iterativo. Por exemplo, se um sinalizador 'gen_param1' estiver definido como true, eu desenho 'param1' de sua condição total no amostrador iterativo. Se estiver definido como false, 'param1' será definido como seu valor verdadeiro.

Depois de terminar de escrever o amostrador, testei o programa usando a seguinte receita:

  • Defina o sinalizador de geração para um parâmetro como true e todo o resto como false e avalie a convergência em relação ao valor true.
  • Defina o sinalizador de geração para outro parâmetro em conjunto com o primeiro e avalie novamente a convergência.

Os passos acima foram incrivelmente úteis para mim.

Respostas:


10

Prática padrão de programação:

  • ao depurar, execute a simulação com fontes fixas de aleatoriedade (ou seja, a mesma semente), para que quaisquer alterações sejam devidas a alterações de código e não a números aleatórios diferentes.
  • tente seu código em um modelo (ou vários modelos) em que a resposta é conhecida.
  • adote bons hábitos de programação para introduzir menos erros.
  • pense muito e demoradamente sobre as respostas que você obtém, se elas fazem sentido etc.

Desejo-lhe boa sorte e muito café!


3

Eu tenho uma anedota deprimente e não muito específica para compartilhar aqui. Passei algum tempo como colega de trabalho de um pesquisador estatístico de MT. Se você quiser ver um modelo realmente grande e complexo, não procure mais.

Ele estava me colocando no campo de treinamento da PNL para sua própria diversão. Eu sou, em geral, o tipo de programador que vive e morre pelo teste de unidade e pelo depurador. Quando jovem na Symbolics, fiquei impressionado com o aforismo: "a programação está depurando um buffer de editor vazio". (Mais ou menos como treinar um modelo de perceptron.)

Então, perguntei a ele: 'como você testa e depura essas coisas'. Ele respondeu: "Você acertou na primeira vez. Você pensa sobre isso (no caso dele, muitas vezes no papel) com muito cuidado e codifica com muito cuidado. Porque quando você erra, as chances de isolar o problema são grandes. muito magro."


Já ouvi essa anedota antes (talvez também de você?). Ele chegou em casa para mim e, desde a primeira vez que o ouvi, tornou-se realidade em várias ocasiões (ou seja, a dificuldade de isolar o problema).
redmoskito

3

Boas dicas na resposta de PeterR; Não tenho mais dicas para a depuração real, mas encontrei um procedimento muito útil para testar se o seu código poderia ter um bug. É descrito neste artigo:

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

Essencialmente, a idéia é ter duas simulações: uma sendo o seu MCMC para inferir (presumivelmente) os parâmetros do seu modelo. O segundo simulador simplesmente faz uma amostra de parâmetros do anterior. Eles geram dados a partir dos parâmetros de ambos os simuladores e calculam uma estatística de teste comparando as distribuições conjuntas de parâmetros e dados. Se o código MCMC fizer uma amostragem correta dos parâmetros da parte posterior, a estatística do teste terá uma distribuição de N (0,1). O código para calcular a estatística de teste está disponível.


Uma abordagem relacionada pode ser encontrada em Cook et al. (2006; stat.columbia.edu/~gelman/research/published/… ). Eu usei a abordagem de Cook et al. Em duas ocasiões e fiquei impressionado com os resultados. Eu não usei a abordagem de Geweke, mas, de acordo com Cook et al., "A abordagem de Geweke tem a vantagem de que apenas uma replicação precisa ser executada ... Uma desvantagem é que exige a alteração do software a ser testado". Eles também dizem que a abordagem de Geweke exige prioros com variância finita, enquanto a abordagem deles não.
jmtroos
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.