Resultados

A lo largo del desarrollo de MMS han ido apareciendo distintos métodos de acceso a los resultados provocando quizá en los usuarios cierta confusión.

A continuación explicamos cuáles son estos métodos, por qué aparecen y cuáles debemos utilizar:

Resultados por evaluación del modelo

Estos fueron los primeros métodos de acceso a resultados. Su diseño se basa en la idea de que el modelo (como cada una de sus partes) es capaz de evaluar los resultados si conoce los parámetros estimados.

Para ello se añadieron unos métodos de obtención de resultados con la forma Get[Result].E(Set resultingParameters) en las clases adaptadaras del modelo (@MMS.ModelAdapter y complementarias).

Así en el código de los ejemplos nos encontrábamos con expresiones del tipo:

// Obtención de todo los parámetros estimados (@MMS.ResultingParameter)
Set rPars = estimation::GetParameters(?);

para obtener los parámetros estimados, luego:

@MMS.SubmodelAdapter submodel = estimation::GetModelAdapter(?)
  ::GetSubmodel("Veh.Tur.Mat");

para obtener el objeto adaptado al que pedirle los resultados y finalmente llamadas como:

Serie outputE = submodel::GetOutput.E(rPars)::GetExpectedValue(?);
Serie noiseE = submodel::GetNoise.E(rPars)::GetExpectedValue(?);
Serie filterE =  submodel::GetFilter.E(rPars)::GetExpectedValue(?);
Serie residualsE = submodel::GetResiduals.E(rPars)::GetExpectedValue(?);

para obtener los resultados deseados.

Ventajas

La única ventaja de estos métodos es que nos permitían obtener un conjunto de resultados para un determinado conjunto de parámetros estimados, fuesen verdaderamente estimados o no.

Inconvenientes

El principal inconveniente es su lentitud, muy notable en modelos grandes, ya que cada llamada al método concatenaba una multitud de cálculos que se repetían sin poder reutilizarse. Por ejemplo, para obtener la serie de residuos anterior residualsE internamente se volvían a calcular todos loes efectos, el filtro (filterE), etc. aún cuando acababan de ser calculados, pues no hay una forma natural de almacenar esa información pues depende del argumento rPars.

Resultados mediante acceso a resultados nativos

Este fue el segundo método de acceso a resultados y que se implementó probablemente por dos motivos por un lado por la lentitud del método anterior y por otro por cuestionarse si los métodos anteriores devolvían lo mismo que los resultados nativos.

Estos métodos se encargaban de obtener de los resultados nativos los correspondientes a cada parte del modelo, de modo que era necesario indicarle al objeto encargado de encontrarlos (@MMS.ResultsAdapter de qué objeto se trataba. Para ello era necesario pasar como argumento la instancia adaptada del objeto para el que deseabamos los resultados.

Así pues encontrábamos en el código de los ejemplos que primero se obtenía el adaptador de resultados:

@MMS.ResultsAdapter results = estimation::GetResults(?);

luego se buscaba el objeto adaptado sobre el que se querían buscar los resultados:

@MMS.SubmodelAdapter submodel = estimation::GetModelAdapter(?)
  ::GetSubmodel("Veh.Tur.Mat");

y finalmente se obtenían los resultados con llamadas como éstas:

Serie outputR = results::GetOutput(submodel);
Serie noiseR = results::GetNoise(submodel);
Serie filterR = results::GetFilter(submodel);
Serie residualsR = results::GetResiduals(submodel);

Ventajas

La principal ventaja ha de ser la confianza por el acceso a los resultados nativos que no sólo eran conocidos sino también explorables con el inspector de TOLBase.

Inconvenientes

El principal inconveniente es que estos resultados no son accesibles cuando una estimación ha sido guardada y posteriormente recuperada, ya que al guardar una estimación sólo se guardan los parámetros estimados.

Por ello, para permitir el uso de dichos métodos, al recuperar una estimación guardada se construían unos pseudo-resultados nativos haciendo uso de los métodos de evaluación y de los parámetros estimados almacenados.

Sin embargo, esto tenía terribles consecuencias en el caso de modelos grandes ya que la reconstrucción de los resultados se hacía enormemente lenta y consumidora de RAM, lo primero como hemos comentado era esparable por el diseño de los métodos de evaluación, lo segundo es debido a pérdidas de memoria (!) en las llamadas a funciones que al repetirse una y otra vez ocupaban enormes cantidades de RAM.

Este problema se intenta solucionar con un nuevo grupo de métodos que se diseñan para la versión 0.6 y que se adaptan a la 0.5.

Un inconveniente añadido de este grupo de funciones de acceso a los resultados nativos es que no hayan resultados nativos porque éstos no se han calculado (véase el tique #270). En esta situación, los métodos fallarán como es lógico.

Resultados a partir de una única evaluación del modelo

En la versión MMS_0.6 se diseña un conjunto de clases que sustituyen a los métodos de evaluación que reciben los parámetros estimados como argumento (los primeros).

Estas clases (@MMS.ModelResults y complementarias) se comportan de manera similar a cómo hacían las clases adaptadoras (@MMS.ModelAdapter y complementarias) pero utilizando como atributo adicional el conjunto de parámetros estimados.

De este modo se crea un conjunto de instancias para cada estimación o conjunto de parámetros estimados. Para más detalles de su estructura véase MMS_0.5/ResultsClasses?.

Ventajas

La principal ventaja de estas clases de resultados es su eficiencia, pues al construirse para un grupo determinado de parámetros estimados, puede permitirse almacenar sus resultados y así acelerar su respuesta en las siguientes llamadas.

Otra característica de las instancias de resultados (y que puede verse como ventaja) desde el punto de vista de la eficiencia y la economía de recursos es que se construye por demanda, de modo que inicialmente sólo se construye la instancia de @MMS.ModelResults y las demás instancias (de @MMS.SubmodelResults, @MMS.ExpTermResults, @MMS.HierarchyResults, etc) se construyen la primera vez que se llama a los métodos (GetSubmodels, GetHierarchies, etc).

Inconvenientes

El principal inconveniente de estos métodos, como también lo era de los métodos de evaluación, es que no está disponible un conjunto de objetos TOL (reales, series y matrices) que se puedan explorar con el inspector de TOLBase, ni siquiera cuando los resultados han sido ya construidos y almacenados internamente.

Sin embargo, podemos disponer de métodos ágiles en la obtención de informes o conjuntos de resultados que sí podrán se inspeccionables desde la interfaz gráfica de TOL.

Uso

El uso de estas instancias de resultados se considera la más recomendada en la versión 0.5 y probablemente sea la única en la versión 0.6 y posteriores.

Hay que destacar que su uso es más sencillo que el de los métodos anteriores pudiendo acceder directamente a los resultados mientras se recorre la estructura del modelo:

Serie estimation::GetModelResults(?)::GetSubmodel("Veh.Tur.Mat")::GetOutput(?);
Serie estimation::GetModelResults(?)::GetSubmodel("Veh.Tur.Mat")::GetNoise(?);
Serie estimation::GetModelResults(?)::GetSubmodel("Veh.Tur.Mat")::GetFilter(?);
Serie estimation::GetModelResults(?)::GetSubmodel("Veh.Tur.Mat")::GetResiduals(?);

sin tener que incluir más argumentos que los nombres de los objetos para los que se demandan los resultados.