Modelos y el primer método de contrastación

En esta sección se muestra cómo cargar modelos al programa. Los modelos pueden ser de dos tipos, completos e incompletos (i.e. puede fallar la denotación de algún término en ellos). Se expone cómo consultar al programa por la denotación de un término en un modelo, por si una oración dada es satisfecha por un modelo y por si un modelo satisface todos los axiomas propios, leyes fundamentales y especializaciones cargadas anteriormente.

En base a esto, se introduce el primer procedimiento de testeo de una reconstrucción formal: los modelos correspondientes a aplicaciones paradigmáticamente exitosas de la teoría deben satisfacer la formalización de las leyes, mientras que modelos correspondientes a aplicaciones no exitosas deben hacer falsas a alguna ley (a aquella/s que informalmente se piensa que fallan en tal aplicación). Se ejemplifica con algunos casos sencillos.

109

Los modelos (potenciales) completos pueden cargarse desde la pestaña Models. Luego de elegido un nombre para el modelo en el campo Model name, debe introducirse en el recuadro abajo la interpretación para cada término del lenguaje primitivo, en el campo correspondiente. Como ejemplo, tómese la aplicación de MCAR que contiene dos cuerpos (b1 y b2) y dos tiempos (t1 y t2), tales que b1 y b2 chocan antes de t1, con velocidades de 2 y −2, y resultan en las velocidades −2 y 2 (un caso de aplicación potencial exitosa). En Reconstructor, este modelo se vería como sigue:

Fig. 4.21. Modelo de MCAR cargado en Reconstructor

110

▪ Los dominios deben ser conjuntos de objetos. En Reconstructor (en todos los módulos) es posible usar tanto la sintaxis “{c1, c2, …}” como “set(c1, c2, …)” para conjuntos. Los objetos miembros de los conjuntos pueden ser ellos mismos conjuntos, tuplas (especificadas con “tuple(…)”), números o strings (e.g. “d1”). Las últimas son interpretadas como tipos de objeto propios de la teoría y no como objetos de alguna clase por default.

▪ Las constantes deben ser objetos de alguno de los dominios, o conjuntos/tuplas construidas a partir de objetos de los dominios.

▪ Las interpretaciones de relaciones n-arias son conjuntos de n-tuplas, como es estándar. Cada

n-tupla debe contener como elementos a objetos de los dominios, propios o auxiliares/por

default (o conjuntos/tuplas construidos a partir de los dominios). ▪ Las funciones pueden especificarse de dos modos:

- El que se muestra en la imagen, que coincide con un modo estándar de interpretar una función. Es decir, una interpretación de un símbolo de función es un conjunto de pares ordenados. Cada par tiene como primer elemento a una tupla (con los argumentos) y como segundo a un objeto (con el valor de la función para esos argumentos).

- Un modo menos engorroso de cargar interpretaciones de funciones es usar la sintaxis “f(a1, …, an) = v1, f(aj, …, ak) = v2”, en donde f es el término para la función, los ai son argumentos, y los vi valores. Nótese que si se introduce la interpretación de la función de este modo, Reconstructor la guardará en memoria del primer modo. Así, si se actualiza la pestaña, la interpretación de la función se verá como arriba.

Como puede verse, desde la pestaña Models, todas las interpretaciones que son conjuntos se cargan por extensión, listando a los elementos del conjunto. Esto puede ser engorroso cuando los conjuntos son grandes. Reconstructor permite simular una definición por comprensión desde el módulo de métodos de determinación (véase la sección 4.5).

Una vez cargado un modelo es posible consultar a Reconstructor por la denotación de un término en él, desde el módulo Query. Allí, debe seleccionarse la opción Model en la primer lista desplegable, escribirse el nombre del modelo a la derecha, seleccionar Denotation? en la lista inferior izquierda y brindarse el término a evaluar a su derecha. Esta última lista desplegable trae precargados por default los términos primitivos de la teoría, pero puede escribirse en ella para

111

consultar por otros términos (primitivos, por default, o términos complejos que tienen ambos). Por ejemplo:

Fig. 4.22. Consultas por la denotación de términos.

4.2.2. Modelos incompletos

Otra funcionalidad que será útil luego es la posibilidad de cargar modelos incompletos. Los modelos incompletos son aquellos en donde uno o más términos contienen fallas de denotación. Esto es, una constante de individuo puede fallar en denotar, una n-tupla de elementos puede no pertenecer ni a la extensión ni a la anti-extensión de una relación y un argumento de una función puede no tener asignado un valor.

112

Este tipo de modelos pueden cargarse desde la pestaña Incomplete models.33 _{Un ejemplo}

de un modelo de este tipo es el siguiente:

Fig. 4.23. Ejemplo de carga de modelo incompleto en MCAR. B y T (que no se ven en la captura) son

iguales que en la figura 4.7.

En este caso, se ilustran los tres tipos de indeterminación: la constante c no recibió ninguna interpretación, la tupla 〈b2, b1, t1〉 (entre otras) no pertenece ni a la extensión ni a la anti-extensión de CL y las velocidades no están cargadas para t2. Si se consulta a Reconstructor por la denotación de expresiones como “c” el resultado será indeterminado [indeterminate]. El modo en el que el

113

programa valúa las oraciones que contienen términos con fallas de denotación será explicado en la sección 4.4.

4.2.3 Valuaciones y el primer método de contrastación de reconstrucciones

Una de las funciones centrales de Reconstructor es, como se adelantó anteriormente, chequear si una oración formal es satisfecha por un modelo dado. Una vez cargado un modelo, puede chequearse si este satisface una oración desde el módulo Query. Existen dos modos de hacer esto: (i) elegir Sentence en la primer lista desplegable, escribir la oración, luego elegir Satisfied by? y por último dar el nombre del modelo, en la última lista; y (ii) elegir Model en la primer lista desplegable, escribir el nombre del modelo, y luego elegir Satisfies? y el tipo de axioma (precargado) que se desea evaluar. En la figura 4.10 se ilustra el segundo método.

114

Fig. 4.24. Consultas sobre la valuación de los axiomas impropios y la ley fundamental en m1. La valuación de las especializaciones puede consultarse de modo idéntico, seleccionando Specializations en la última

lista desplegable.

Como se dijo anteriormente, el modelo m1 pretendía representar a un caso de aplicación exitoso de la teoría. Sin embargo, se observa que Reconstructor afirma que uno de los axiomas impropios (IMP5) es falso. Como se adelantó, esto mostraría que la reconstrucción no es adecuada ya que (y en esto consiste el test) modelos que traducen aplicaciones paradigmáticamente exitosas de teorías deben satisfacer las leyes (y viceversa para aplicaciones no exitosas).

Pero Reconstructor no se detiene ahí. Es posible investigar el motivo por el que la contrastación falló. Cuando el valor dado por el programa y las expectativas del usuario no coinciden puede afirmarse que ocurrió una de las tres siguientes cosas:

115

i. Alguno de los axiomas (en este caso, el axioma impropio 5) fue incorrectamente formalizado.

ii. El modelo no es una traducción adecuada de la situación empírica descripta. iii. Lo que la comunidad científica considera un modelo exitoso en realidad no lo es.

Para estos casos, en donde las expectativas y el output no coinciden, Reconstructor incluye otra herramienta útil para determinar cuál de esas tres opciones es el caso, que consiste en la posibilidad de imprimir el log de valuaciones (i.e. el proceso de razonamiento interno por el que Reconstructor llegó a afirmar que las valuaciones eran esas). Esto se hace oprimiendo el botón Print valuation log. Esto abrirá un cuadro de diálogo para guardar el log como un archivo .txt que contiene el log de la última valuación (o conjunto de valuaciones) que se le pidió evaluar. En este caso, para el axioma IMP5, el log dice lo siguiente:

Fig. 4.25. Log de valuaciones de Reconstructor. Las fórmulas se muestran aquí en el formato interno que

el programa usa para almacenarlas y evaluarlas.

Dado que Reconstructor utiliza una semántica sustitucional (por limitaciones computacionales, ya que los modelos son siempre finitos) puede verse que asignó un nombre a aquellos elementos de los dominios que no tenían una constante asignada ($0 es t1, $1 es t2 y $2 es b2, estas denotaciones pueden consultarse desde el módulo Query si se desea).

116

Recuérdese que el axioma 5 afirmaba que si bx choca con by en ti, entonces by choca con bx en

ti (i.e. la relación de choque es simétrica en las primeras dos posiciones). El programa dictaminó que la oración es falsa porque:

- CL(b1, b2, t1) es verdadera y CL(b2, b1, t1) es falsa (líneas 122 y 123 del log) - Por tanto, CL(b1, b2, t1) → CL(b2, b1, t1) es falsa (línea 124)

- Por tanto, la cuantificación universal sobre las tres posiciones es falsa (líneas 125 a 127)

Es decir, lo que falló es que 〈b2, b1, t1〉 no está en la interpretación de CL, estando en el caso (ii) anterior (la situación empírica fue incorrectamente cargada como modelo). Si se agrega esta tupla a la denotación de CL (en el archivo suplementario, ello se hace en un modelo m2) se obtiene que todos los axiomas impropios son verdaderos y que el test es exitoso.

Todo esto ilustra otro punto importante. Como el holismo de la contrastación nos enseña, un test de una hipótesis nunca lo es de la hipótesis aislada, sino que siempre existen algunas presuposiciones que se testean conjuntamente con la hipótesis deseada. Estas incluyen condiciones iniciales, cláusulas ceteris paribus, etc.; incluso, según las versiones más radicales, un test puede incluir partes de la matemática y de la lógica como parte del conocimiento de background asumido. Si bien el objetivo de este test es determinar si las leyes fueron correctamente formalizadas (i.e. la hipótesis sería que las leyes fueron correctamente formalizadas), como todo otro test de toda otra teoría, también incluye ciertas presuposiciones. En el presente caso, (ii) y (iii) de arriba son algunas de ellas. De ese modo, al igual que en todo otro ámbito científico, el fallo del test no implica automáticamente (i.e. lógicamente) que la hipótesis sea falsa. Nuevamente, el caso recién considerado ilustra este punto.

Un test más completo de una teoría utilizando este método consistiría en diseñar distintos tipos de situaciones (i.e. modelos) en las que leyes deberían ser satisfechas, así como varios en los que distintas combinaciones de leyes deberían no valer. En el segundo caso, el programa debería arrojar que las leyes particulares que se cree que no valen en tal caso son las que son falsas. En MCAR esto incluiría diseñar casos que satisfagan (y no satisfagan) la otra ley especial (la que lidia con cuerpos que no chocan), casos con más dos cuerpos y más de dos instantes de tiempo, etc. Si en todos estos casos la reconstrucción “se comporta igual” que su contraparte informal, entonces

117

puede afirmarse que la formalización de las leyes es correcta (asumiendo que los otros presupuestos se satisfacen también).