Devolución del burning

[imendez]

Hola, cuando se estima con BSR estaría bien que se devolvieran las simulaciones correspondientes al burning (de forma separada a la cadena válida), para poder comprobar si el mcmc.burnin especificado es razonable.

Por cierto, este parámetro de configuración ¿no debería terminar en "g", mcmc.burning?

Un saludo.

[Pedro Gea]

MMS sólo canaliza la definición del modelo a BSR y sus resultados de nuevo a MMS, de modo que quizá lo más oportuno para sugerir mejoras en el estimador es dirigirse a ​TOLProject que es el que gestiona el estimador BSR (paquete BysMcmc).
De todos modos canalizaremos estas necesidades y sugerencias.

Lo que llamamos burning en realidad es ​burn-in quizá lo que haría falta es poner la I mayúscula.

Este burn-in consiste en descartar esas simulaciones que se usan para preparar el sistema, y por esa razón simplemente se descartan.

Quizá lo que se anda buscando son unos cambios para no usar un burn-in a priori, o incluso ni siquiera un número de simulaciones fijado de antemano, sino condicionar estas decisiones a determinados criterios o diagnósticos.

[josp]

La diagnosis de convergencia es algo que se hace despues de generar la cadena, así que no tiene mucho sentido ese valor especificado a priori. Es un error de diseño del API de nuestros samplers.

Idealmente BSR y cualquier otro sampler debería incorporar mecanismos de monitorización de convergencia en caliente, de forma tal que esta pueda ser detenida cuando se haya alcanzado la convergencia.

En cuanto al caso que propone Iván esto puede lograrse indicando que descarte 0 ó 1 (en caso de que 0 sea inválido).

El mecanismo de monitorización de convergencia es algo que debería hacerse desde el sampler ya sea interno o mediante un evento que invoque una rutina externa.