Opened 15 years ago
Closed 15 years ago
#116 closed task (fixed)
Revisión y ampliación del módulo de estimaciones
Reported by: | Pedro Gea | Owned by: | Pedro Gea |
---|---|---|---|
Priority: | major | Milestone: | Estimation 0.5 |
Component: | Estimation | Keywords: | |
Cc: |
Description
Es necesario hacer una revisión del módulo de estimaciones y de la
organización de sus clases:
@MMS.Estimation
@MMS.Strategy (y derivadas)
@MMS.ResultsAdapter (y derivadas)
así como la implementación de nuevas clases para la definición de
estimaciones condicionadas.
Tras ello hay que implementar la persistencia de estos elementos y adecuar
los métodos del contenedor MMS.
Note: See
TracTickets for help on using
tickets.
La reestructuración terminó de revisarse con el commit 976.
Adjunto un resumen de los cambios hechos:
La estructura del módulo de estimaciones varía para adecuarse mejor a la
persistencia de los objetos y a su construcción y uso.
La estructura de una estimación (Estimation) viene dada por el siguiente
esquema:
Nótese que la previsión (Forecast) es un tipo particular (clase derivada)
de una estimación condicionada.
La información más significativa respecto a estas clases es:
@MMS.Estimation
@MMS.Forecast
El objeto estimation dispone de una copia del modelo además de un
adaptador para su uso desde el módulo de estimaciones de acuerdo al
criterio modular.
El condicionamiento de la estimación se hace mediante el atributo y
argumento _.conditioning.
La estrategia de estimación utilizada está en el atributo _.strategy y
ésta posee un objeto de configuración _.settings.
Para la creación de la estimación se recomienda (a diferencia de lo que se
hacía hasta ahora) no utilizar el argumento _.strategy, sino simplemente
el argumento _.settings, y éste ya se encargará de comunicar al
constructor del estimador qué tipo de estratagia es necesaria.
Sin embargo por ahora, las dos opciones son aceptadas.
Ejemplo:
@MMS.Strategy
@MMS.StrategyBSR
@MMS.StrategyEstimate
@MMS.StrategyLogit
Las estrategia pasan a tener un atributo de configuraciones _.settings y
(al menos provisionalmente) y atributo _.session.
Dejan de tener nombre o descripción (_.name, o _.description) ya que el
papel original de éstos lo desempeñan ahora los homónimos de Estimation.
El constructor de la estrategia pretende ser llamado sólo por parte de
estimation de acuerdo a la configuración Settings utilizada. Aunque aún
pueda hacerse globalmente.
El método de asignación del modelo SetModel quedaría obsoleto y el modelo
se asignaría directamente en su construcción, ya que para la construcción
de la estimación es necesario proporcionar el modelo para el cual se desea
hacer.
Además StrategyBSR pierde sus atributos específicos. La configuración
BSR.Config queda dentro de las settings, el PartialHandler queda vinculado
al Conditioning y para el Notifier se admite sólo el Notifier por defecto.
Otro notifier, quizá podría especificarse desde las settings.
La estrategia VLogit desaperece como tal y se vuelve una variante de la
Logit para utilizar una u otra disponemos de la configuración
_.logitEstimator.
El estimador VLogit pasa a incluirse desde fun_vlogit.tol con el nombre
VLogit. Respecto a este estimador decir que no se devuelve resultados
parecidos a Logit, por lo que quizá habría q revisarlo.
@MMS.Settings
@MMS.SettingsBSR
@MMS.SettingsEstimate
@MMS.SettingsLogit
Aparece un objeto de configuraciones (Settings) como sustituto a los
objetos Setting.
Los objetos Setting eran exclusivos para tratar las configuraciones de
variables globales, el objeto Settings pretende manejar éstas como
cualquier otra configuración propia de la estrategia.
Las configuraciones por defecto se pueden construir usando
{{{::Default(?)}} por ejemplo:
aunque podemos crearlas también especificando los valores de algunas de
ellas
de la forma siguiente:
@MMS.ResultsAdapter
@MMS.ResultsAdapterMMS
@MMS.ResultsAdapterBSR
@MMS.ResultsAdapterEstimate
@MMS.ResultsAdapterLogit
Respecto a los adaptadores de resultados, la principal novedad es la
aparición de un adaptador de resultados persistente.
Cuando se guardan los resultados, se guarda sólamente la información
mínima para reconstruirlos (es decir, los ResultingParameters)
Creamos pues un ResultsAdapterMMS que nos permite acceder a los resultados
como si procedieran de unos resultados nativos.
Este nuevo objeto reconstruye incluso el conjunto de series más comunes
para agilizar el acceso a resultados.
Está diseñado más bien para uso interno pero podría usarse sin problemas
creando el adaptador, para lo cual sólo es necesario un conjunto de
parámetros resultantes y un adaptador de modelos.