OpenBUGS не может сходиться на модели, сходящейся в WinBUGS. Предел точности?
Как говорится в заголовке этого поста, когда я пытаюсь запустить код и данные, которые отлично работают в WinBUGS из R, используя BRugsFit
(с coda=T
) Я получаю эти ошибки:
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
Когда я делаю tail()
на объекте coda я получаю одни и те же числа снова и снова. С другой стороны, когда я запускаю WinBUGS, сохраняю код и загружаю его в R, я получаю некоторую случайную вариацию, как я и ожидал, и никаких предупреждений о сходимости.
Вот моя модель (она использует "хитрость", чтобы найти постеры для параметров дистрибутива 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;
}
Вот типичный пример моих данных:
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 ))
... и типичные начальные единицы (я использую 4 цепочки, прореживание 20, запись 2000, 20000 итераций)
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 просто округляет до меньшего числа значащих цифр, чем WinBUGS, и если да, возможно, есть параметр, который я могу изменить, чтобы он прекратил это делать?
1 ответ
Мой предварительный ответ на это, кажется, какая-то комбинация...
- Настройка
format
аргумент в пользуbugsInits()
а такжеbugsData()
команды дляfg
, - Параметризация предыдущего распределения такова, что, если параметр очень мал (в отрицательных двузначных числах на логарифмической шкале), производится выборка обратного (или некоторого другого подходящего преобразования).
- Просто используя большие интервалы прореживания (в моем случае 80) и МНОГО итераций. OpenBUGS в настоящее время не поддерживает чрезмерное расслабление, вот и все.
- Если некоторые переменные являются категориальными, не пытайтесь включать их в ту же сводку, что и непрерывные переменные.
Респонденту, который предложил отключить чрезмерное расслабление: проблема в том, что я не могу включить его, и без него итерации будут длиться вечно. Но это, кажется, единственный выбор в настоящее время. Я хотел бы, чтобы руководство WinBUGS было более конкретным о том, что подразумевается под использованием этой функции с осторожностью. Ну да ладно, думаю, мне в конечном итоге нужно будет прочитать статью, которую они цитируют. Но, поскольку это даже не доступно в OpenBUGS, на данный момент это полумут.
Я оставлю свой вопрос открытым некоторое время, на случай, если у кого-то будет более или более подробный ответ, чем я смог придумать.