#605 closed defect (fixed)
Problemas con jerarquías y estimación MLE
Reported by: | Ines Miranda | Owned by: | Pedro Gea |
---|---|---|---|
Priority: | blocker | Milestone: | Release 0.6 |
Component: | Estimation | Keywords: | Estimation, MLE, Jerarquia |
Cc: |
Description
Hola,
al intentar ejecutar una estrategia MLE, obtenemos el siguiente error:
Warning: [84] [@SubresultsAdapterEstimate] No se ha encontrado el parámetro 'TFA_MetSer.MTo.Uni_TTrFa_CFa552_GeoUFe.XX_NPeXX_GOpXX_ClaA1.VC315G_AMCXX_FreDia__FerNacBas.WD1_C__Linear.0' Warning: [85] [@ResultsAdapterMultiMLE::ObtainParameter] Parámetro 'TFA_MetSer.MTo.Uni_TTrFa_CFa552_GeoUFe.XX_NPeXX_GOpXX_ClaA1.VC315G_AMCXX_FreDia__FerNacBas.WD1_C__Linear.0' no estimado. ERROR: [18] [@SubstrategyHyper::_Estimate] No se pueden estimar las jerarquías debido a la presencia de omitidos en los parámetros.
Y la ejecución se detiene. Podríais revisarlo por favor?
A parte de esto, no entendemos:
- Por qué tiene en cuenta las jerarquías en una estimación MLE
- Por qué al desactivar las jerarquías las sigue teniendo en cuenta?
Muchas Gracias,
Change History (9)
comment:1 Changed 14 years ago by
Status: | new → accepted |
---|
comment:2 Changed 14 years ago by
Hola,
MMS no sólo hace una advertencia, da un error: "No se pueden estimar las jerarquías debido a la presencia de omitidos en los parámetros". Si estamos en una estimación MLE, ¿por qué intenta "estimar" las jerarquías?
comment:3 Changed 14 years ago by
Las estrategias de tipo múltiple (MultiMLE y MultiNLO) son incapaces de tratar un modelo (@Model) como un todo y sólo son capaces de tratar cada bloque o submodelo independientemente, usando para cada uno de ellos una sub-estrategia.
La estrategia múltiple de estimación máximo-verosímil (MultiMLE) dispone de varias subestrategias dependiendo de la naturaleza del submodelo (Estimate, LinReg, y GLM: Logit/Probit).
Por las limitaciones de esta estrategia, tanto la información a priori como las relaciones entre parámetros (equivalencias, combinaciones, jerarquías, etc) no pueden considerarse.
Para facilitar una estimación de los hiperparámetros, se realiza una última regresión lineal sobre las jerarquías, donde el output son los parámetros estimados por las otras subestrategias y los parámetros los hiperparámetros.
Hay que entender que esta jerarquía no afecta o influye en los parámetros estimados en los submodelos, lo mismo que los submodelos no se influyen entre sí. Esta estimación de las jerarquías sólo sirve para dar un valor a los hiperparémetros y para observar sus residuos.
Por ejemplo, en el caso de un nodo de de homogeneidad podríamos conocer cual es el promedio de los parámetros estimados y cuánto se alejan de este promedio.
Si se considera innecesario o improcedente, podría obviarse este cálculo. Véase también #22.
comment:4 Changed 14 years ago by
Muchas gracias por la aclaración, no sabía que se hiciera eso.
Vuelvo al problema origen de este ticket: el error de la estimación hace que TOL se detenga y eso no debería ocurrir, ¿verdad?
¿No se podría incluir en las setting de la estrategia MLE si se desean tener en cuenta las jerarquías o no?
Por si sirve de aclaración, nuestra dificultad está en que primero definimos el modelo "completo" (con restricciones, priors y jerarquías) y después hacemos una primera estimación MLE para incluir un AIA en la estimación bayesiana. Es por eso que nos encontramos con este problema.
comment:5 Changed 14 years ago by
Hemos tenido que crear esta función de usuario, que podría ser un método de Model:
Real MMS_Hie_SetActive(NameBlock model, Real isActive)
{
Set sHie = model::GetHierarchies(?);
SetSum(EvalSet(sHie, Real(NameBlock hie)
{ hie::SetIsActive(isActive) }))
};
comment:6 Changed 14 years ago by
Respecto al método equivalente a MMS_Hie_SetActive
entiendo que podría implementarse: model::GetHierarchies.SetIsActive(isActive)
pero no estoy convencido de que tengamos que implementar todas las variantes que se nos puedan ocurrir y quizá debería haber una buena razón o al menos algo que lo diferencie de otros similares que podrían surgir.
La llamada como indicas prácticamente se puede hacer en una línea. Si dispusiéramos de un operador para aplicar un método a los objetos de un conjunto podría incluso quedarse como:
Set model::GetHierarhies(?):/:SetIsActive(isActive); // el operador :/: no existe, claro
comment:7 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
(In [2479]) Se introduce una nueva configuración en la estrategia MultiMLE para evitar la estimación de las jerarquías: _.hyperEstimation
.
Por defecto está activada (a True) de modo que el comportamiento por defecto se mantiene.
Se corrige el error que daba al no poder estimarse la jerarquía por una simple advertencia.
Se evita que ese error (u otro en la subestrategia) detenga TOL, véase #613.
Refs #613
Closes #605
comment:8 Changed 14 years ago by
comment:9 Changed 12 years ago by
Los archivos adjuntos con datos privados se han ubicado en la unidad local B.
El origen del problema es que hay tres inputs que son nulos en el intervalo de estimación.
Si se muestran las trazas de la estimación (configuración
Real _.showTraces = True
) se puede ver como Estimate indica:MMS advierte que no encuentra esos parámetros porque no son estimados y no tiene ninguna valor que ofrecer.
El error encontrado incluso con las jerarquías desactivadas probablemente se debe a que la estimación no se renueva adecuadamente al hacer esos cambios: #470, seguramente si se desactivan las jerarquías y se limpia la estimación antes de ejecutarla de nuevo no aparecerán.