| | 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. |