2012-07-07 14 views
6

Como el título de este post dice, cuando trato de ejecutar código y datos que funcionan bien en WinBUGS de R usando BRugsFit (con coda=T), me sale estos errores:OpenBUGS no logra converger en el modelo que converge en WinBUGS. ¿Límite de precisión?

Error in glm.fit(x = structure(c(1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, : 
    NA/NaN/Inf in foreign function call (arg 1) 
In addition: Warning messages: 
1: glm.fit: algorithm did not converge 
2: glm.fit: algorithm did not converge 
3: glm.fit: algorithm did not converge 
4: glm.fit: algorithm did not converge 
5: step size truncated due to divergence 

Cuando hago tail() en el objeto coda, obtengo los mismos números una y otra vez. Por otro lado, cuando ejecuto WinBUGS, guardo la coda y la cargo en R, obtengo una variación estocástica, como era de esperar, y ninguna advertencia sobre la convergencia.

Aquí está mi modelo (utiliza el truco de 'unos' para encontrar los posteriores para los parámetros de una distribución Logistic-Makeham).

model { 
    for(i in 1:n){ 
      ones[i]<-1; 
      # here I pre-calculate two quantities that occur several times 
      # in the PDF, to save a little processing time 
      expbx[i] <- exp(b*x[i]); expbx1[i]<- 1/(1+sd*(expbx[i]-1)); 
      # below is the actual PDF 
      p[i]<-(c+a*expbx[i]*expbx1[i])*exp(-c*x[i])*pow(expbx1[i],1/s); 
      # the ones trick 
      ones[i]~dbern(p[i]); 
    } 
b~dunif(0,1); d~dexp(1); c~dexp(1); s.raw~dflat(); 
    # a (lambda) parametrized this way because it comes out more accurate 
    # s forced to be > 0 
    a<-b*d; s<-abs(s.raw); 
    # NOT a standard deviation, just s times d, to save processing time 
    sd<-s*d; 
    # I save all the parameters I'm interested in to one vector, for convenient 
    # viewing of them all in the same window. 
    out[1]<-a; out[2]<-b; out[3]<-c; out[4]<-s; out[5]<-d; 
} 

Aquí es un ejemplo típico de mis datos:

list(n= 148 ,x=c(1246,1175,1048,1169,1043,802,543,719,1296,817,1122,542,839,443,1536,700,834,232,596,1096,1118,957,974,1031,1149,1044,1108, 
519,677,569,952,1243,970,1736,1262,1026,979,1543,1029,761,533,540,511,1150,1589,1169,1029,1248,1572,638,731,525,968,1467,1596,1077,712,1603,1 
203,991,37,1775,893,993,913,1487,1186,1381,977,1247,857,786,615,733,1206,1059,1508,569,1205,754,886,1099,843,599,780,1294,1603,1242,883,1320, 
507,1097,1193,218,1362,1181,1118,453,1291,972,787,1061,1097,1100,1117,1174,596,1305,1071,940,919,999,1209,1043,1161,1016,1025,750,423,732, 
1389,907,1184,1275,944,1209,1073,1098,1348,976,817,557,211,961,880,1039,1287,736,1400,1757,1355,977,198,689,853,1251,767,768)) 

... y típico ensu (yo uso 4 cadenas, adelgazamiento, 20 Burnin 2000, 20000 iteraciones)

list(d=0.001738,b=0.0009672,c=0.002451,s.raw=0.001511) 
list(d=0.006217,b=0.005596,c=0.00777,s.raw=0.007019) 
list(d=1.504E-05,b=4.825E-06,c=2.172E-07,s.raw=6.104E-05) 
list(d=0.3011,b=0.03552,c=0.1274,s.raw=0.2549) 

¿OpenBUGS simplemente se redondea a menos dígitos significativos que WinBUGS, y si es así, tal vez hay una configuración que puedo cambiar para que deje de hacer eso?

+1

+1, solo para la categoría de pregunta. Me alegra ver a alguien aplicando BUGS. – duffymo

+2

¿Has probado JAGS? En general, para problemas incluso un poco difíciles, los samplers de caja negra como BUGS pueden ser muy sensibles ... –

+0

Estoy dispuesto a intentarlo. ¿Se vuelve demasiado relajante? WinBUGS tiene una autocorrelación bastante horrible sin esa característica. Además, ¿replicar la funcionalidad de cadenas múltiples de WinBUGS en JAGS es tan simple como hacer múltiples ejecuciones de JAGS y luego combinarlas en una coda de forma manual? – f1r3br4nd

Respuesta

1

Mi respuesta tentativa a esto parece ser una combinación de ...

  • establecer el argumento format para bugsInits() y bugsData() comandos para fg.
  • Parametrización de la distribución anterior de modo que si el parámetro es muy pequeño (en los dos dígitos negativos en la escala de registro) se está muestreando el recíproco (o alguna otra transformación apropiada).
  • Simplemente usando grandes intervalos de adelgazamiento (en mi caso, 80) y MUCHAS iteraciones. OpenBUGS actualmente no admite el exceso de relajación, y eso es todo.
  • Si algunas de las variables son categóricas, no intente incluirlas en el mismo resumen que las variables continuas.

Para el respondedor quien sugirió apagar el exceso de relajación: el problema es que no puedo convertirlo en , y sin ella, las iteraciones tener para siempre. Pero parece ser la única opción en este momento. Me gustaría que el manual de WinBUGS fuera más específico sobre lo que significa usar esta característica con precaución. Bueno, supongo que eventualmente necesitaré leer el periódico que citan. Pero, dado que esto ni siquiera está disponible en OpenBUGS, es semi-discutible en este momento.

Dejaré mi pregunta abierta por un tiempo, en caso de que alguien tenga una respuesta mejor o más detallada que la que he podido proponer.

Cuestiones relacionadas