Estimación WLogit con Priors

[Iván Robles]

Buenos días,

una duda sobre las estimaciones con Wlogit.

Antes, en las estimaciones con BSR, si teníamos una combinación lineal, pero metíamos un prior en los inputs problematicos, se eliminaban las combinaciones lineales. Por ejemplo, si se metía un input que fuera todo cero con un prior no había problema.

Con WLogit, al hacer lo mismo, nos da un error de cholesky. ¿En esta nueva tecnología se eliminan las combinaciones lineales al introducir un prior?¿Hay alguna forma de eliminar las comnbinaciones lineales (que no implique el no meterlas)?

Si necesitais algún ejemplo os lo intentamos aislar.

Un cordial saludo

[Víctor de Buen Remiro]

Aunque no existe ningún estimador en TOL que se llame WLogit, al menos que yo sepa, entiendo que te refieres a la clase @WgtLogit del paquete QltvRespModel.

La presencia de un prior en sí misma no garantiza nada sobre la solubilidad de un modelo, pues depende de la forma tanto del modelo como del prior, pero suele obrar como dices a poco cuidado que se ponga. De hecho yo tengo ejemplos que lo demuestran, por lo que si en vuestro caso no funciona correctamente habría que verlo con detalle.

En QltvRespModel::@WgtLogit, o más exactamente en la clase base QltvRespModel::@WgtLogit de la que hereda, se hace uso de Cholesky exclusivamente a la hora de calcular la matriz de covarianzas de la distribución asintótica en el caso de la estimación máximo-verosímil, la cual es la inversa del opuesto del hessiano, es decir, no se usa para la búsqueda del punto óptimo o moda, sino para el momento de segundo orden, por lo que en principio se podría hacer uso del modelo sin problemas técnicos. Otra cosa es la fiabilidad del modelo desde el punto de vista estadístico que yo diría que es nula en tanto no se determinen las causas del problema.

En la página oficial del paquete se puede ver la forma del hessiano del modelo booleano general y del logit en particular.

El método de Cholesky puede fallar por diferentes causas que se pueden resumir en que la matriz a descomponer no es simétrica definida positiva, o, aun siéndolo, está tan cerca de no serlo que es numéricamente imposible efectuar el algoritmo con aritmética discreta.

Esto se puede deber a un fallo de diseño, a un problema de escalado que dé lugar a pérdida de precisión o a otros motivos, pero es imposible aventurar la causa exacta sin ver los datos.

[Iván Robles]

Adjuntamos un archivo para probarlo

[Víctor de Buen Remiro]

(In [3058]) Fixes #1065
La metodología estaba bien pero no había que dar un error sino un warning cuando la X sea singular, pues efectivamente el prior podría arreglarlo