| 109 | == Resultados a partir de una única evaluación del modelo == |
| 110 | |
| 111 | En la versión MMS_0.6 se diseña un conjunto de clases que sustituyen a los métodos |
| 112 | de evaluación que reciben los parámetros estimados como argumento (los primeros). |
| 113 | |
| 114 | Estas clases ({{{@MMS.ModelResults}}} y complementarias) se comportan de manera |
| 115 | similar a cómo hacían las clases adaptadoras ({{{@MMS.ModelAdapter}}} y complementarias) |
| 116 | pero utilizando como atributo adicional el conjunto de parámetros estimados. |
| 117 | |
| 118 | De este modo se crea un conjunto de instancias para cada estimación o conjunto |
| 119 | de parámetros estimados. Para más detalles de su estructura véase [wiki:MMS_0.5/ResultsClasses]. |
| 120 | |
| 121 | == Ventajas == |
| 122 | |
| 123 | La principal ventaja de estas clases de resultados es su eficiencia, pues al construirse |
| 124 | para un grupo determinado de parámetros estimados, puede permitirse almacenar sus |
| 125 | resultados y así acelerar su respuesta en las siguientes llamadas. |
| 126 | |
| 127 | Otra característica de las instancias de resultados (y que puede verse como ventaja) |
| 128 | desde el punto de vista de la eficiencia y la economía de recursos es que se construye |
| 129 | por demanda, de modo que inicialmente sólo se construye la instancia de @MMS.ModelResults |
| 130 | y las demás instancias (de @MMS.SubmodelResults, @MMS.ExpTermResults, @MMS.HierarchyResults, etc) |
| 131 | se construyen la primera vez que se llama a los métodos (GetSubmodels, GetHierarchies, etc). |
| 132 | |
| 133 | == Inconvenientes == |
| 134 | |
| 135 | El principal inconveniente de estos métodos, como también lo era de los métodos de evaluación, |
| 136 | es que no está disponible un conjunto de objetos TOL (reales, series y matrices) que se puedan |
| 137 | explorar con el inspector de TOLBase, ni siquiera cuando los resultados han sido ya construidos |
| 138 | y almacenados internamente. |
| 139 | |
| 140 | Sin embargo, podemos disponer de métodos ágiles en la obtención de informes o conjuntos de |
| 141 | resultados que sí podrán se inspeccionables desde la interfaz gráfica de TOL. |
| 142 | |
| 143 | == Uso == |
| 144 | |
| 145 | El uso de estas instancias de resultados se considera la más recomendada en la versión 0.5 |
| 146 | y probablemente sea la única en la versión 0.6 y posteriores. |
| 147 | |
| 148 | Hay que destacar que su uso es más sencillo que el de los métodos anteriores |
| 149 | pudiendo acceder directamente a los resultados mientras se recorre la estructura del modelo: |
| 150 | {{{ |
| 151 | Serie estimation::GetModelResults(?)::GetSubmodel("Veh.Tur.Mat")::GetOutput(?); |
| 152 | Serie estimation::GetModelResults(?)::GetSubmodel("Veh.Tur.Mat")::GetNoise(?); |
| 153 | Serie estimation::GetModelResults(?)::GetSubmodel("Veh.Tur.Mat")::GetFilter(?); |
| 154 | Serie estimation::GetModelResults(?)::GetSubmodel("Veh.Tur.Mat")::GetResiduals(?); |
| 155 | }}} |
| 156 | sin tener que incluir más argumentos que los nombres de los objetos para los que |
| 157 | se demandan los resultados. |