Trabajo Final Lic. en Ciencias de la Computación Optimización en Dominios de Planificación

Transcripción

1 Trabajo Final Lic. en Ciencias de la Computación Optimización en Dominios de Planificación Alumno: Facundo Bustos Director: Dr. Carlos Areces FaMAF Universidad Nacional de Córdoba Año

2 The ACM Computing Classification System (1998): I. Computing Methodologies. I.2. ARTIFICIAL INTELLIGENCE. I.2.8. Problem Solving, Control Methods, and Search. -Scheduling Palabras claves: -Planificación -Planificadores -Dominios -Split -Optimización Resumen: Dentro del área de la Inteligencia Artificial, el problema de la planificación consiste básicamente en, dado un conjunto finito de acciones, un estado inicial y un objetivo, decidir si existe o no una secuencia finita de tales acciones que me permita pasar del estado inicial a un estado en el cual se satisface dicho objetivo. Al conjunto de acciones de un problema de planificación se lo llama dominio. Actualmente existen algoritmos, llamados planificadores, que realizan esta tarea. Nuestro trabajo consistirá en encontrar una transformación de un problema de planificación P P en otro problema de planificación P P, tal que, los tiempos de respuesta por parte del planificador sean menores en P P que en P P, teniendo que existir la propiedad de que el conjunto de soluciones entre ambos problemas de planificación se preservan, es decir, que podamos recuperar una solución de P P a través de una solución de P P y viceversa. Vamos a explicar en detalle la técnica de transformación llamada Split y luego presentamos una formalización de la misma que nos sirva para poder demostrar formalmente propiedes deseables de nuestra técnica. Proponemos cuatro algoritmos que automatizan la técnica, analizando sus ventajas y desventajas. Finalmente analizamos y discutimos los resultados arrojados en diez dominios de planificación de prueba, comparando la performace del dominio Split con respecto al dominio original. 1

3 Índice 1. Introducción 4 2. El problema de planificación Conceptos de un problema de planificación Ejemplo de un problema de planificación El lenguaje de especificación para los problemas de planificación Formalizando el problema de planificación Noción de equivalencia entre dominios de planificación Equivalencia en sistemas de ecuaciones lineales Equivalencia en lógica proposicional Equivalencia en dominios de planificación Split de un dominio de planificación Ejemplo de Split de una acción Cómo obtenemos un Split a partir de un esquema de acción? Definición formal de Split La importancia del orden de ejecución de las subacciones del Split Preservando el conjunto de soluciones Definción formal del sistema de tokens Obteniendo la transformación de un problema de planificación Recuperando un solución de P P a través de su transformación P P y viceversa Split y equivalencia, parte formal Algoritmos de Split Analizando el espacio de búsqueda de los cubrimientos de una acción Criterios de preferencia entre cubrimientos Algoritmo de cubrimiento: Literal Fit Algoritmo de cubrimiento: Greedy Merger Algoritmo de cubrimiento: Optimized Literal Fit Algoritmo de cubrimiento: Π-Merger Algoritmo de mapeo

4 6. Pruebas y análisis de los resultados obtenidos con los algoritmos de Split Definición de la métrica Delta Gráfica Delta Literal Fit Gráfica Delta Greedy Merger Gráfica Delta Optimized Literal Fit Gráfica Delta Π-Merger Observando los diferentes Splits en los dominios d1, d5 y d Utilizando Split en modo concurrente Utilizando Split en modo off-line Resumen y Conclusiones 79 3

5 1. Introducción En computación, el problema de planificación consiste intuitivamente en decidir si existe o no una secuencia finita de acciones que me permita llegar de un estado inicial a un estado en el cual se satisface un determinado objetivo. Al conjunto de acciones de un problema de planificación se lo llama dominio. Actualmente existen algoritmos, usualmente llamados planificadores, que realizan esta tarea, tales como Graphplan [1], SatPlan, FastFoward [1] entre otros. Nuestro trabajo consistirá en encontrar una transformación de un problema de planificación P P en otro problema P P, tal que, los tiempos de respuesta por parte del planificador sean menores en P P que en P P, teniendo que existir la propiedad de que el conjunto de soluciones entre ambos problemas de planificación se preservan, es decir, que podamos recuperar una solución de P P a través de una solución de P P y viceversa. Vamos a automatizar dicha transformación y probar su funcionamiento en diferentes problemas de planificación para poder inferir empíricamente si se produce o no una optimización en el tiempo de respuesta del planificador. Los objetivos cumplidos o logros de este trabajo son: Comprendimos los conceptos básicos y la complejidad asociada al problema de planificación. Presentamos una formalización del problema de planificación que permita probar propiedades deseables de nuestra técnica de optimización. Empezamos a estudiar el concepto de equivalencia entre dominios de planificación. Presentamos una primera definición de equivalencia y probamos formalmente que dicha definición preserva el conjunto de soluciones de problemas de planificación. Presentamos en detalle la técnica Split del Dr. Carlos Areces, sus conceptos básicos y restricciones, para obtener dominios que satisfacen nuestra definición de equivalencia. Explicamos la ventaja que presenta el dominio Split con respecto al dominio original. Definimos formalmente la técnica de Split y probamos formalmente que permite obtener dominios equivalentes. Propusimos e implementamos diferentes algoritmos de Split (en lenguaje Java), estudiando sus ventajas y desventajas. 4

6 Observamos el funcionamiento o performances de los dominios obtenidos mediante los algoritmos de Split que se implementaron y lo comparamos con el performace del dominio original en un conjunto de diez dominios de prueba. Verificamos empíricamente si Split reduce o no el tiempo de respuesta del planificador. Con respecto a la estructura de este texto, en la sección 2 se presentan los conceptos básicos asociados a los problemas de planificación, así como también ejemplos concretos, su lenguaje de especificación formal (PDDL) y finalmente su formalización matemática. En la sección 3 se presenta una noción de equivalencia entre dominios de planificación y su definición formal. Luego demostramos que problemas de planificación con dominios equivalentes preservan las soluciones. En la sección 4 damos una técnica automatizable, llamada Split, para halllar dominios equivalentes, explicamos sus conceptos, detalles de su implementación y por qué esperamos que dicha técnica resulte en una optimización en los tiempos de respuestas del planificador. Finalmente formalizamos la técnica y luego probamos que efectivamente al aplicarla obtenemos un dominio equivalente. En la sección 5 se presentan ciertos algoritmos de Split que implementan diferentes heurísticas, enumerando sus ventajas y desventajas. En la seccion 6 se presentan diferentes gráficas donde se comparan las performances de los algoritmos de Split presentados en la sección 5 con respecto a la performace del dominio original sobre un conjunto de diez dominios que fueron bajados de la web de las competencias internacionales de planificación ICAPS[6]. Finalmente en la sección 7 y última de este texto, presentamos un resumen y conclusiones del trabajo realizado. 5

7 2. El problema de planificación Como dijimos en la introducción el problema de planificación consiste intuitivamente en decidir si existe o no una secuencia finita de acciones que me permita llegar de un estado inicial a un estado en el cual se satisface un determinado objetivo. Los planificadores, que así se denominan a los algoritmos que deciden si existe o no solución para un problema de planificación dado son algoritmos que operan con representaciones proposicionales explícitas de estado y acciones. Estas representaciones hacen posible la obtención de heurísticas efectivas y el desarrollo de poderosos y flexibles algoritmos para la resolución de problemas. La planificación en Inteligencia Artificial (IA) emerge de la investigación en áreas tales como búsquedas en el espacio de estados, demostración de teoremas y teoría de control, desde las necesidades prácticas en robótica, organización y otros dominios. La planificación es, actualmente, un área de gran interés dentro de la IA. Una razón de esto es que combina dos grandes áreas de IA: búsquedas y lógica. Esto es, un planificador puede ser visto tanto como un programa que busca la solución o como uno que (constructivamente) proporcione la existencia de una solución. Lo fértil del cruce de ideas desde ambas áreas ha llevado a un avance en la pasada década de varios órdenes de magnitud y un aumento del uso de planificadores en aplicaciones industriales. Desafortunadamente, no se tiene una clara comprensión de qué técnicas funcionan mejor en qué clase de problemas. La planificación es, en primer lugar, un ejercicio de control de la explosión combinatoria. Si tenemos un número p de proposiciones primitivas en un dominio tendremos 2 p estados. Para dominios complejos, p puede crecer mucho. La planificación es una tarea compleja, de hecho, se conoce que el problema de planificación pertenece al conjunto de problema de complejidad PSPACE-COMPLETO. De aquí se deduce la importancia de hallar una técnica que permita en muchos casos lograr optimizar el tiempo de respuesta del planificacador Conceptos de un problema de planificación Representación de estados. Los planificadores representan el mundo en términos de condiciones lógicas y representan un estado como un conjunto de literales positivos. Por ejemplo {P obre, Desconocido} puede representar un agente desafortunado. Tambien se utilizan literales de primer orden, como por ejemplo, {En(avion 1, ezeiza), En(avion 2, aeroparque)} que puede representar un estado en un problema de reparto de encomiendas, en donde 6

8 el avion 1 se encuentra en el aeropuerto de Ezeiza mientras que el avion 2 se encuentra en el aeropuerto de Aeroparque. La hipótesis de un mundo cerrado es asumida por lo que todas las condiciones que no son mencionadas en un estado se asumen que son falsas. Representación de objetivos. Un objetivo será un estado parcialmente especificado, representado por un conjunto de literales positivos, tales como {Rico, F amoso} o {En(avion 1, argentina)}. Un estado s satisface un objetivo g si s contiene al menos todos los elementos de g, por ejemplo, el estado {Rico, F amoso, Enf ermo} satisface el objetivo {Rico, F amoso}. Representación de acciones. Una acción es especificada en términos de las precondiciones que deben cumplirse antes de ser ejecutada y de las consecuencias que siguen cuando se ejecuta. Por ejemplo, la acción que especifica que un avión vuela de una ciudad a otra puede representarse con el siguiente esquema de acción: AccionV olar(p : Avion, Desde, Hacia : Aeropuerto) pre : {En(P, Desde)} ef ecto : { En(P, Desde), En(P, Hasta)} Para hacer más sencilla la legibilidad, algunos sistemas de planificación dividen en dos lconjuntos los efectos de las acciones, un conjunto add de literales positivos que serán interpretados como ciertos luego de ejecutada la acción y un conjunto del, también de literales positivos, que serán interpretados como falsos luego de ejecutada la acción. En consecuencia, nuestra acción anterior V olaravion se podría especificar de la siguiente manera: AccionV olar(p : Avion, Desde, Hacia : Aeropuerto) pre : {En(P, Desde) add : {En(P, Hasta)} del : {En(P, Desde)} Notar que con esta última forma de especificar una acción logramos que su definición sea sólo en terminos de literales positivos. Por otro lado, observar que el esquema de acción anterior en realidad representa varias acciones posibles, en particular una por cada instanciación posible de sus variables. Diremos que una acción instanciada es ejecutable en un estado si este satisface su precondición, en caso contrario la acción 7

9 no tiene efecto. Veamos esto con un ejemplo. Supongamos que tenemos un estado s descripto por: {En(avion 1, ezeiza), En(avion 2, aeroparque)} Dicho estado s satisface la precondición de la acción AccionV olar para la siguiente instanciación de sus variables: [P avion 1, Desde ezeiza, Hasta aeroparque]. De esta forma la acción instanciada AccionV olar(avion 1, ezeiza, aeroparque) es ejecutable en s y al ejecutar la acción pasamos del estado s al siguiente estado: {En(avion 1, aeroparque), En(avion 2, aeroparque)} En general, el resultado de ejecutar una acción instanciada a en un estado s nos lleva a un estado w, que es exactamente igual a s excepto que cualquier literal positivo en el conjunto add es agregado a w y cualquier literal positivo de la lista del es eliminado de w Ejemplo de un problema de planificación Ahora estamos en condiciones de dar una ejemplo concreto y completo de un problema de planificación [1]. Se trata de un problema de transporte de carga aéreo el cual es definido mediante tres acciones: Cargar, Descargar y Volar. Las acciones se definen principalmente en términos de dos literales: Dentro(C, P ) significa que la carga C está dentro del avión P y En(X, A) significa que X (tanto avión como carga) está en el aeropuerto A. EstadoInicial : {En(carga 1, ezeiza), En(carga 2, aeroparque), En(avion 1, ezeiza), En(avion 2, aeroparque)} Objetivo : {En(carga 1, aeroparque), En(carga 2, ezeiza)} AccionCargar(C : Carga, P : Avion, A : Aeropuerto) pre : {En(C, A), En(P, A)} add : {Dentro(C, P )} del : {En(C, A)} 8

10 AccionDescargar(C : Carga, P : Avion, A : Aeropuerto) pre : {Dentro(C, P ), En(P, A)} add : {En(C, A)} del : {Dentro(C, P )} AccionV olar(p : Avion, Desde, Hasta : Aeropuerto) pre : {En(P, Desde)} add : {En(P, Hasta)} del : {En(P, Desde)} La siguiente secuencia de acciones es un plan del problema: 1. AccionCargar(carga 1, avion 1, ezeiza) 2. AccionV olar(avion 1, ezeiza, aeroparque) 3. AccionCargar(carga 2, avion 2, aeroparque) 4. AccionV olar(avion 2, aeroparque, ezeiza) 5. AccionDescargar(carga 1, avion 1, aeroparque) 6. AccionDescargar(carga 2, avion 2, ezeiza) 2.3. El lenguaje de especificación para los problemas de planificación PDDL [3] (Planning Domain Definition Language) tiene como objetivo estandarizar la descripción de dominios y problemas de planificación dentro del área de Inteligencia Artificial. En un pricipio fue desarrollado por Drew Mc Dermott con la ayuda de algunos colegas para las competencias internacionales de planificación de los años , en donde se compararon las performances de diferentes algoritmos de planificación, por lo tanto era necesesario un lenguaje común de especificación de problemas. Una especificación PDDL consiste en dos partes: la definición del dominio y la definición del problema. A partir de ahora, hablaremos de especificaciones STRIPS [4] (Stanford Research Institute Problem Solver, desarrollado por Richard Fikes y Nils Nilsson en el año 1971), que es un sub-lenguaje de PDDL, es decir, es un lenguaje mas simple y de menor expresividad. En STRIPS, la definición del dominio contiene principalmente la definición de los predicados y las acciones. Un dominio STRIPS tiene en general el siguiente formato: 9

11 (define (domain DOMAIN_NAME) (:requirements :strips :typing) (:types NAME 1... NAME N) (:predicates (PREDICATE_1_NAME?A1 - TYPE-A1?A2 - TYPE-A2...?AN - TYPE-AN) (PREDICATE_2_NAME?A1 - TYPE-A1?A2 - TYPE-A2...?AN - TYPE-AN)...) (:action ACTION_1_NAME :parameters (?P1 - TYPE-P1?P2 - TYPE-P2...?PN - TYPE-PN) :precondition PRECOND_FORMULA :effect EFFECT_FORMULA ) (:action ACTION_2_NAME...)...) Los nombres (del dominio, predicados, acciones) son caracteres alfanuméricos, guiones, guiones bajos. Los parámetros de los predicados y acciones comienzan con el caracter?. Los parámetros usados en la declaración de los predicados no tiene otra función que especificar la cantidad y tipo que el predicado debe tener, i.e. el nombre del parámetro en sí no tiene importancia. Además los predicados pueden no tener parámetros, en cuyo caso se denota con paréntesis vacios. La precondición de una acción (la sección precondition:) puede ser una fórmula atómica (un único predicado) o una conjunción de fórmulas atómicas. Mientras que su efecto (la sección precondition:) será una fórmula atómica, la negación de una fómula atómica, o una conjunción de ellas. Cabe aclarar, que los parámetros de cada uno de los predicados que ocurren en la acción deben ser también parámetros de la acción. Por el otro lado, la definición del problema, contiene la especificación de los objetos que representan las instancias del problema, un estado inicial y la descripción de un objetivo, en el siguiente formato: (define (problem PROBLEM_NAME) (:domain DOMAIN_NAME) (:objects OBJ1 - TYPE1 OBJ2 - TYPE2... OBJM - TYPEM) (:init ATOM1 ATOM2... ATOM_N) (:goal CONDITION_FORMULA) ) 10

12 La descripción del estado inicial (la sección init:) es simplemente una lista de átomos que son verdaderos en el estado inicial mientras que cualquier otro es considerado como falso. La descripción del objetivo (la sección goal:) es una fórmula atómica o una conjunción de formulas atómicas, es decir, igual que en el caso de las precondiciones de las acciones. Por último, PDDL posee la capacidad de declarar tipos, es decir, que cada objeto o instancia declarada en el problema estará asociado a un tipo particular. Para ello debemos: 1. Declarar el requerimiento de tipos en la definición del dominio (:requirements strips, typing) 2. Definir los tipos, esto se debe realizar antes de usarlos en la definición de los predicados (:types NAME 1... NAME N) Para declarar los tipos de los parámetros tanto en los predicados como en las acciones uno escribe?x - TYPE-OF-X. Una lista de parámetros que tiene el mismo tipo se puede abreviar?x?y?z - TYPE-OF-XYZ. La sintaxis para definir los tipos de los objetos o instancias en la definición del problema es exactamente igual. Se recomienda leer [5] para más detalles sobre especificación en PDDL. Continuando con el ejemplo de la sección 2.2 sobre transporte de carga aéreo, veamos como se especifica en PDDL. Primero, la especificación del dominio: (define (domain TransporteCargaAereo) (:requirements :strips :typing) (:types Carga Avion Aeropuerto) (:predicates (Dentro?C - Carga?P - Avion) (Enc?C - Carga?A - Aeropuerto) (Enp?P - Avion?A - Aeropuerto)) (:action Cargar :parameters(?c - Carga?P - Avion?A - Aeropuerto) :precondition(and (Enc?C?A) (Enp?P?A)) :effect(and (not(enc?c?a)) (Dentro?C?P)) 11

13 ) (:action Descargar :parameters(?c - Carga?P - Avion?A - Aeropuerto) :precondition (and (Dentro?C?P) (Enp?P?A) ) :effect (and (Enc?C?A) (not (Dentro?C?P))) ) (:action Volar :parameters(?p - Avion?Desde - Aeropuerto?Hasta - Aeropuerto) :precondition (and (Enp?P?Desde) ) :effect (and (not (Enp?P?Desde)) (Enp?P?Hasta)) ) ) Finalmente la especificación del problema: (define (problem TransporteCargaAereoProblema) (:domain TransporteCargaAereo) (:objects carga_1 carga_2 - Carga avion_1 avion_2 - Avion ezeiza aeroparque - Aeropuerto ) (:init (Enc carga_1 ezeiza) (Enc carga_2 aeroparque) (Enp avion_1 ezeiza) (Enp avion_2 aeroparque) ) (:goal (and (Enc carga_1 aeroparque) (Enc carga_2 ezeiza) ) ) ) 2.4. Formalizando el problema de planificación Ahora intentaremos dar una formalización matemática del problema de planificación. Para ello pensaremos las acciones como ya instanciadas y sus efectos positivos y negativos separados en dos conjuntos diferentes para poder especificar una acción en términos sólo de literales positivos (en la Sección 2.1 ya se había hecho referencia a esta posibilidad). Una acción a será una 3-upla (pre, add, del) donde pre, add, del son conjuntos finitos de literales positivos instanciados tales que add del =. Denotaremos pre(a) = pre, add(a) = add y del(a) = del. Sea Lit(a) = pre(a) add(a) del(a), el conjunto de literales que ocurren en la acción a. Sea A conjunto finito de acciones, Lit(A) = {Lit(a) : a A} 12

14 será el espacio de literales de A, mientras que Σ A = P(Lit(A)) el espacio de estados definido por A. Un estado será cualquier s Σ A, donde los literales que pertenecen a s se asumen verdaderos mientras que los literales en Lit(A) \ s se consideran falsos. Definición 1. Un problema de planificación P P será una 3-upla (A, s 0, F ) donde A = {a 1,..., a n } un conjunto finito no vacío de acciones, llamado dominio. s 0 Σ A, llamado el estado inicial. F Σ A, llamado el conjunto de estados finales. Definimos la siguiente relación de transición: sean a A y s, w Σ A, s a w sii pre(a) s y w = (s add(a)) \ del(a). Diremos que a es ejecutable en s sii s a w para algún w Σ A. Denotaremos con A el conjunto de todas las secuencias o cadenas finitas de acciones, es decir, A = {a 1...a n : a i A, n >= 0} y con ε la cadena vacia. Sea a = a 1...a n definimos, s a a w sii s 0...s n Σ A. s 1 0 s1...s n 1 y s 0 = s, s n = w. Si s a w diremos que a lleva de s a w. a n sn Definimos el conjunto de soluciones para un problema de planificación, Sol(PP) = {a A a : s 0 sf, con s f F }. Diremos que a A es un plan de P P sii a Sol(PP). 13

15 3. Noción de equivalencia entre dominios de planificación En muchas áreas de la matemática es interesante poder observar cuándo dos objetos se comportan en forma similar con respecto a una propiedad matemática puntual. Aquí es donde nace el concepto de equivalencia entre objetos matemáticos. La idea es poder concluir ciertas propiedades de uno de ellos a través del comportamiento del otro. Vamos a comenzar repasando definiciones de equivalencia en distintas áreas de la matemática y finalmente vamos a introducir el concepto de equivalencia entre dominios de planificación Equivalencia en sistemas de ecuaciones lineales En el álgebra lineal, sabemos que dos sistemas de ecuaciones lineales son equivalentes si uno es combinación lineal del otro y viceversa [2]. Se ha demostrado que sistemas de ecuaciones lineales que cumplen con esta definición de equivalencia tienen las misma soluciones. La importancia de esto radica en que, dado un sistema de ecuaciones lineales, podemos encontrar otro sistema de ecuaciones, equivalente al primero, cuyas soluciones son exactamente las mismas que las del primer sistema pero que en el segundo son más fáciles de calcular, o computacionalemte hablando, más baratas de encontrar si es que lo hiciéramos mediante algún método numérico. Veamos con un ejemplo como esta noción de equivalencia entre sistemas de ecuaciones lineales nos es útil para encontrar las soluciones de un sistema de ecuaciones dado. Supongamos que queremos encontrar la solución del siguiente sistema de ecuaciones lineales: 2x 1 x 2 + 3x 3 + 2x 4 = 0 x 1 + 4x 2 x 4 = 0 2x 1 + 6x 2 x 3 + 5x 4 = 0 Representamos el sistema con la siguiente matriz: Sabemos que si aplicamos una secuencia de operaciones elementales de fila sobre una matriz cualquiera obtenemos otra que es combinación lineal 14

16 de la primera y viceversa. Por lo tanto, luego de aplicar ciertas operaciones elementales de fila sobre la matriz anterior, obtenemos: Esta última matriz representa el sistema: x x 4 = 0 x x 4 = 0 x x 4 = 0 Estos dos sistemas cumplen con la definición de sistemas equivalentes y por lo tanto, tienen las mismas soluciones. Ahora, está claro que si en el segundo sistema, asignamos a x 4 un valor c cualquiera, se obtiene que toda solución es de la forma ( 17 3 c, 5 3 c, 11 3 c, c), es decir, logramos obtener la solución del primer sistema mediante la solución del segundo sistema, en el cual fue más fácil hallar la solución Equivalencia en lógica proposicional Una de las definiciones de equivalencia entre fórmulas de la lógica proposicional que podemos encontrar dice que, dos fórmulas φ y ψ son equivalentes si y sólo si la fórmula φ ψ es una tautología. Se puede ver que, si dos fórmula son equivalentes, entonces todos los modelos que satisfacen una de las fórmulas también satisfacen la otra y vicerversa. Supongamos que dada una fórmula proposicional debemos decidir si es satisfacible o no (recordando que una fórmula es satisfacible si existe al menos un modelo que la satisface). Para ello podríamos encontrar otra fórmula, equivalente a la primera, para la cual, decidir si es o no satisfacible sea mucho más simple. Veamos un ejemplo. Sea φ = ( p q) (p q), debemos decidir si existe un modelo (o sea, una asignación sobre {true, f alse} de las variables proposicionales p, q) tal que φ sea verdadera. Sabemos que toda fórmula proposicional es equivalente a otra en forma normal conjuntiva donde esta última fórmula se obtiene de la primera a partir de aplicar ciertas reglas sintácticas que escapan el alcance de este texto. Aplicando dichas reglas sintácticas obtenemos que 15

17 ψ = ( p q) es la fórmula en forma normal conjuntiva equivalente a φ. Luego, vemos que cualquier modelo que asigne a la variable q el valor de verdad true satisface ψ, por lo tanto, también satisface φ, es decir, logramos ver que φ es satisfacible utilizando su equivalencia con ψ Equivalencia en dominios de planificación Nuestra intención es definir una noción de equivalencia entre dominios tal que podamos obtener un plan de uno de ellos a través de un plan del otro y viceversa. Una primer definición de equivalencia podría ser aquella tal que si dos dominios A y A son equivalentes entonces todo plan de A es también plan de A y viceversa. Una definición así tiene el defecto de que las acciones de ambos dominios deberían ser las mismas, es decir, obliga a que el espacio de soluciones de problemas de planificación que tienen a A y A como dominios sean el mismo. La idea es poder definir una noción de equivalencia entre dominios que pueden ser completamente diferentes y que además sea lo más general posible. En otras palabras, lo que nos interesa es que los dominios posean un espacio de soluciones equivalente, siempre que un problema de uno de los dominios tenga una solución, esto también ocurre en el otro y viceversa. Además para poder utilizar uno de los dominios como alternativa del otro, vamos a pedir que sea posible traducir una solución de uno de ellos en una solución del otro. Como consecuencia, necesitamos introducir el concepto de traducción de un plan de A en un plan de A y viceversa. También necesitamos una traducción de los estados que define A hacia los estados que define A. La idea de nuestra definición es que, si uno pasa de un estado s a un estado w mediante una secuencia de acciones a de A, entonces debe existir una traducción de a en una secuencia de acciones a de A tal que permita pasar del estado que es traducción de s a un estado que es traducción de w. Recíprocamente, si tenemos una secuencia de acciones a de A que me lleva de un estado que es traducción de un estado s de A a un estado que es también traducción de un estado w de A, entonces debe existir una traducción de a en una secuencia de acciones a de A que me lleve de s a w. Es importante destacar que esta condición no se necesita que se cumpla para cualesquiera dos estados s y w, sino para ciertos estados que son los que se van a configurar finalmente como estado inicial y final para un problema de planificación. Por lo tanto restringiremos la noción de equivalencia a un conjunto de pares de posibles estados iniciales y finales. Dicho todo esto, ya estamos en condiciones de enunciar la definición formal de equivalencia entre dominios de planificación que finalmente vamos a estudiar. 16

18 Definición 2. Sean A, A dominios, C Σ A Σ A un conjunto de pares de estados, T : Σ A Σ A, t : A A, t : A A. Diremos que A y A son equivalentes via T, t, t en el contexto C (notación, A T,t,t C A ) sii i. (s, w) C. a A. s a w T (s) t(a) T (w) ii. (s, w) C. a A. T (s) a T (w) s t (a ) w. Notar que la ralación T,t,t C no es una relación de equivalencia. Si bien es reflexiva (basta con tomar T, t, t como la identidad) no es necesariamente simétrica ni transitiva. Para obtener estas últimas dos propiedades deberíamos, por ejemplo, tomar C como el conjunto de todos los estados y requerir que T sea biyectiva (para asegurar que T 1 esté bien definida). Pero estos requisitos no son necesarios para asegurar equivalencia del espacio de soluciones que es lo que buscamos (ver Teorema 1) y además hacen menos general la definición. Veamos un ejemplo que nos ayude a interpretar la definición anterior. A continuación se presentan dos dominios de planificación, A = {a1, a2} y B = {b1, b2, b3, b4} que cumplirán con la definición de equivalencia propuesta. Figura 1: Dominios equivalentes. 17

19 Tomaremos las siguientes funciones de traducción, T (S1) = S1, T (S2) = S2, T (S3) = S3, t(a1)=b1b2, t(a2)=b3, t (b1b2)=a1, t (b3)=a2 y el contexto C = {(S1,S2), (S1,S3)}. Notar que los estados primados en el segundo se corresponde con las traducciones de los estados del primero. Uno puede pasar de S1 a S2 mediante a1 en el dominio A mientras que en B uno puede pasar de S1 a S2 mediante b1 seguido de b2. Similarmente, uno puede pasar de S1 a S3 mediante a2 en el dominio A mientras que en B se puede pasar de S1 a S3 mediante b3. Recíprocamente uno puede pasar de S1 a S2 en B mediante b1 seguido de b2 mientras que en A uno puede pasar de S1 a S2 con a1, finalmente vamos de S1 a S3 mediante b3, en tanto que, en A podemos pasamos de S1 a S3 mediante a2. Ahora, enunciaremos el teorema que asegura que problemas de planificación con dominios equivalentes preservan el conjunto de soluciones. Es decir, el teorema garantiza que podemos recuperar un plan de uno de los problemas de planificación a través de la traducción de un plan del otro. Teorema 1. Si A T,t,t C A, entonces tomando P P = (A, s 0, F ) y P P = (A, T (s 0 ), T (F )) problemas de planificación tales que s f F : (s 0, s f ) C, se cumple que: i. t(sol(p P )) Sol(P P ) ii. t (Sol(P P ) Sol(P P ). Demo I: veamos que si a Sol(P P ), entonces t(a) Sol(P P ). Sea a Sol(P P ) a s 0 sf con s f F T (s 0 ) t(a) T (s f ) t(a) Sol(P P ) por definición de equivalencia Demo II: veamos que si a Sol(P P ), entonces t (a ) Sol(P P ). Sea a Sol(P P ) T (s 0 ) a T (s f ) para algún s f F t s (a ) 0 s f t (a ) Sol(P P ) por definición de equivalencia 18

20 4. Split de un dominio de planificación En esta sección, nos abocaremos a lograr una transformación de un problema de planificación P P en otro P P, cuyos dominios sean equivalentes para recuperar un plan de P P mediante un plan de P P, tal que exista una optimización en el tiempo de respuesta del planificador en P P con respecto a P P. La estrategia para la transformación del problema de planificación consiste básicamente en tomar cada acción del dominio de P P y dividirla en partes o subacciones tal que al ejecutar las subacciones en forma consecutiva se tenga los mismos efectos que ejecutar la acción original. Intuitivamente, al dividir una acción en subacciones se reduce la cantidad de instanciaciones que debe realizar el planificador y por consiguiente, debería reducirse el tiempo de respuesta del mismo. Es decir, suponemos que menor cantidad de instanciaciones implica menor tiempo de respuesta. Esta estrategia de dividir las acciones de un dominio, tiene como contrapartida un incremento en la cantidad de acciones resultantes haciendo que nuestros planes sean más extensos. Es decir, si pensamos el problema de planificación como una simple búsqueda en un grafo, podemos afirmar que Split reduce el número de ramificaciones (branch) pero con el costo de generar mayor profundida(depth) en el grafo.y este será el costo que se debe asumir por aplicar dicha estrategia Ejemplo de Split de una acción Veamos con un ejemplo en qué consiste y qué se logra con la división de una acción en subacciones: Move(A, B, C : Bloque) pre : {on(a, B), clear(a), clear(c)} add : {on(a, C), clear(b)} del : {on(a, B), clear(c)} El esquema de acción Move en este caso tiene 3 variables todas del tipo Bloque. Supongamos que existen m objetos de tipo Bloque en el problema de planificación. Por lo tanto, el planificador deberá instanciar el esquema de acción para cada uno de las posibles combinaciones de estas instancias para establecer cuál de todas estas acciones concretas son ejecutables en un 19

21 Figura 2: Ejecución de la acción Move(A, B, C). estado dado. Es decir, realizará m 3 instanciaciones y chequeará la ejecutabilidad de cada una ellas. Ahora, dividamos la acción M ove en dos subacciones: Move 1 (A, B : Bloque) pre : {on(a, B), clear(a)} add : {clear(b)} del : {on(a, B)} Move 2 (A, C : Bloque) pre : {clear(c)} add : {on(a, C)} del : {clear(c)} Aquí, el esquema de acción Move de tres variables se dividió en dos subacciones Move 1 y Move 2 de dos variables cada una. Cada subacción implicaría para el planificador m 2 instanciaciones, por lo tanto, al ejecutar Move 1 seguido de Move 2 tendríamos un total de 2m 2 instanciaciones contra las m 3 que teníamos con la acción original. Veamos en una tabla que sucede para diferentes valores de m: m Instanciaciones en Move Instanciaciones en Move 1 Move Claramente a medida que m crece se observa una optimización importante en la cantidad de instanciaciones que debe realizar el planificador. Habíamos dicho que la estrategia de dividir una acción tiene como contrapartida un incremento en la cantidad de acciones resultantes. En el ejemplo, dividir una acción generó dos acciones y éste es el costo que se debe asumir por aplicar dicha técnica. 20

22 Por otra parte, analizando nuevamente el ejemplo, se observa que las condiciones en las que se puede ejecutar y los efectos de la acción Move son los mismos que para Move 1 seguido de Move 2 y viceversa. Además, Move 1 seguido de Move 2 es igual a ejecutar Move 2 seguido de Move 1. Es decir, el efecto final luego de ejecutar todas las subacciones es independiente del orden en el que se ejecutan. Sin embargo, debemos decidir (arbitrariamente o según consideremos más apropiado desde algún punto de vista) en qué orden específico se ejecutarán las subacciones, es decir, si la acción se divide en n partes habrá una primera subacción, una segunda subacción y así sucesivamente hasta una n-ésima subacción. También, debemos asegurar que las subacciones se ejecuten en forma atómica, no puede ocurrir una ejecución parcial del Split de una acción. En la Sección 4.5 veremos cómo se logra esto. En la sección 4.9, se prueba formalmente que, dado un dominio cualquiera, si obtenemos otro a partir de dividir las acciones del primero, entonces tenemos dominios equivalentes. Por lo tanto, podremos recuperar un plan del primer dominio mediante un plan del segundo que estará formado por subacciones. En definitiva, nuestro algoritmo consistirá en tomar cada uno de los esquemas de acción de un dominio dado y obtener un Split de cada uno de ellos Cómo obtenemos un Split a partir de un esquema de acción? Primero vamos a definir la interfaz de un esquema de acción a (interfaz(a)) como el conjunto formado por sus parámetros. Análogamente se define la interfaz de un literal l de un esquema de acción (interfaz(l)). Para obtener un Split de un esquema de acción, debemos realizar dos tareas. Primero obtener un cubrimiento de la interfaz del esquema de acción original. Cada uno de los elementos de dicho cubrimiento determina la interfaz de cada subaccción. La segunda tarea es tomar un mapeo entre los literales del esquema de la acción original y los elementos del cubrimiento. Veamos en detalle estas dos tareas. Definición 3. Sea a una acción, C P(interfaz(a)) es un cubrimiento de a sii i. c C c = interfaz(a) ii. c, c C. c c c = c. 21

23 iii. l Lit(a) : c C : interfaz(l) c. La definición anterior nos dice primero que la unión de los elementos de un cubrimiento debe ser la intefaz de la acción. Segundo, que ningún elemento del cubrimiento es subconjunto de algún otro y finalmente que las interfaces de los literales de la acción deben ser cubiertas por al menos un elemento del cubrimiento. En particular, en el ejemplo de la acción Move de la sección 4.1 cuya interfaz es {A, B, C}, usamos el cubrimiento C 0 = {{A, B}, {A, C}}. Notar que C 0 satisface la definición anterior, ya que la unión de sus elementos es igual a la interfaz de la acción, ninguno de sus dos elementos es subconjunto del otro y finalmente todo literal de la acción Move tiene su interfaz incluida en al menos uno de sus dos elementos. Diremos que un literal l es cubierto por c C sii la interfaz de l es un subconjunto de c. Por ejemplo, los literales clear(a) y on(a, B) son cubiertos por {A, B} mientras que el literal on(a, C) no lo es. La definición de cubrimiento asegura que todo literal en la acción original es cubierto por algún elemento de C. Por qué pedimos esto? Porque, si un literal l no fuese cubierto por alguno de los elementos de C y como cada elemento determina la interfaz de cada subacción del Split, no existiría una subacción cuya interfaz me permita mapear dicho literal en ella. Supongamos que para la acción Move tomamos el cubrimiento C = {{A}, {B, C}}. Tendríamos dos subacciones con interfaz {A} y {B, C}. Como el literal on(a, B) no es cubierto por niguno de las dos interfaces, no puede ser mapeado a ninguna de las dos subacciones del Split. Está claro que dada una acción existen muchos cubrimientos posibles. Nuestra intención es estudiar cuál es el mejor de todos los cubrimientos posibles. Ya habíamos dicho que cada elemento del cubrimiento será la interfaz de una subacción del Split. De aquí se desprende que la cantidad de elementos del cubrimiento determina la cantidad de subacciones del Split. Resta determinar qué literales de la acción original tendrá cada una de las subacciones, es para ello que definimos un mapeo entre los literales de la acción orginal y las subacciones cuyas interfaces están ya definidas por los elementos del cubrimiento. Mapearemos la ocurrencia de un literal l a la subacción a i con interfaz c C si l es cubierto por c. Notar que dado un literal este puede ser cubierto por más de un elemento de C. Es aquí donde estudiaremos políticas de mapeo. Por ejemplo, podríamos optar por elegir aleatoriamente o que se mapee a la subacción con interfaz más grande. Ob- 22

24 viamente, el mapeo respeta el lugar de ocurrencia del literal dentro de la acción original. Es decir, si un literal ocurre en la sección pre, add ó del de la acción original dicho literal ocurrirá en la sección pre, add ó del respectivamente, de la subacción a la que fue mapeado. Es muy importante que la definición del mapeo cumpla con la siguiente condición: si un literal l ocurre en la precondición y en el efecto de la acción original entonces ambas ocurrencias deben mapearse al mismo elemento de C. Esta condición tiene como objetivo que el efecto final luego de ejecutar todas las subacciones del Split sea independiente del orden en el que se ejecutaron. La condición evita concretamente estas dos situaciones: que una subacción elimine un literal que está también en la precondición de otra subacción que se va a ejecutar posteriormente conviertiendo a esta última en una subacción no ejecutable independientemente de la ejecutabilidad de la acción original. que una subacción agregue un literal que está también en la precondición de otra subacción que se va a ejecutar posteriormente conviertiendo a esta última en una subacción ejecutable independientemente de la ejecutabilidad de la acción original. Veamos un ejemplo de la primer situación: XX(A, B, C : Bloque) pre : {on(a, B), clear(a), clear(c)} add : {on(c, A)} del : {clear(a)} y la dividimos en dos: XX 1 (A, B : Bloque) XX 2 (A, C : Bloque) pre : {on(a, B)} pre : {clear(a), clear(c)} add : add : {on(c, A)} del : {clear(a)} del : Supongamos que la acción XX es ejecutable en P P en un cierto estado, por lo tanto XX 1 y XX 2 debería ser ejecutables en P P. Ahora luego de ejecutar XX 1, XX 2 no es ejecutable, pues clear(a) está en su pre y este literal fue removido por XX 1. Claramente esto se debe a que las dos ocurrencias de clear(a) en la acción original se mapearon a diferentes subacciones. 23

25 4.3. Definición formal de Split Para probar matemáticamente propiedades deseables del Split, vamos a definir formalmente el concepto de Split como un mapeo entre las acciones del dominio y una secuencia de acciones. Recordar que en las formalizaciones siempre pensamos nuestras acciones como ya instanciadas, no como esquemas de acción. Definición 4. Sea A un dominio. Una función Split sobre A será una función α : A Acciones, tal que si α(a) = a 1...a k se cumple que: 1 i. l Lit(A). l X(a)! a i : l X(a i ) con X {pre, add, del} ii. l Lit(A). l pre(a) X(a)! a i : l pre(a i ) X(a i ) con X {add, del} La primera condición dice que los literales de la acción original se mapean a una única subacción y todo literal de una subacción es literal de la acción original. Mientras que la segunda condición dice que si en una acción original un literal ocurre en la pre y en el efecto, ya sea en add ó del, entonces ambas ocurrencias se mapean a la misma subacción. De la definición de Split se desprenden las siguientes proposiciones. Proposición 1. Sea α(a) = a 1...a k una función Split y X {pre, add, del}. 1. X(a i ) X(a). 2. X(a i ) X(a j ) =, con i j. 3. X(a i ) = X(a). 4. pre(a i ) add(a j ) =, con i j. 5. pre(a i ) del(a j ) =, con i j. 6. add(a i ) del(a j ) =. 1 donde Acciones es el conjunto de todas las acciones. 24

26 4.4. La importancia del orden de ejecución de las subacciones del Split Observemos que dada una acción a y a 1,..., a k un Split de a, cualquier permutación a i1,..., a ik es un Split de a. Ahora nos preguntamos si hay en general una permutación más conveniente que otra? Supongamos que la acción a no es ejecutable en algún estado. Entonces sabemos que existe un literal en su precondición que es falso, y ese mismo literal está en la precondición de una única subacción a j. Entonces esta subacción también será no ejecutable en algún estado. Entonces si hacemos que a j sea la última de las subacciones del Split (j = i k ), el planificador instanciaría el resto de las k 1 subaccciones para darse cuenta de que esta última subacción no se puede ejecutar. En cambio si aj es la primera subacción (j = i 1 ) del Split, el planificador ahorraría las k 1 instanciaciones de las demás subacciones. Es decir, que lo más conveniente sería que la subacción que no se puede ejecutar esté lo antes posible en el orden de la permutación. En general, no sabemos de antemano cual es la subacción que será no ejecutable en caso de que la acción sea no ejecutable. Como heurística podemos considerar que mientras más literales haya en la precondición de una subacción más probabilidad tiene de ser no ejecutable. Por lo tanto, ordenaremos el Split de forma tal que las subacciones con más literales en su precondición estén al principio en la permutación Preservando el conjunto de soluciones Ya tenemos una forma de obtener un Split a partir de un esquema de acción. Ahora debemos completar el Split para asegurar las siguientes propiedades: P1. Las subacciones de un Split tienen un orden de ejecución predefinido. P2. Luego de ejecutar una subacción, únicamente es ejecutable la subacción siguiente en el Split, excepto en el caso de que la subacción que se ejecutó sea la última en el orden del Split, en cuyo caso las únicas subacciones ejecutables serán todas aquellas que son primera subacción de algún Split. P3. Si una subacción es ejecutable instanciando una de sus variables con el objeto o y luego esa misma variable es parámetro de una subacción posterior del mismo Split, esa variable debe quedar instanciada con el objeto o. 25

27 Estos tres items son necesarios para garantizar la equivalencia entre un dominio A y el dominio A que tiene por acciones los Splits de las acciones del primero. Dado que A y A son equivalentes podremos recuperar un plan del primer dominio a partir de un plan del segundo. Para garantizar P1, P2, P3 usaremos literales nuevos que implementan un sistema de tokens que se irán pasando entre las subacciones del Split. El literal procnone es tomado por la primera subacción y es liberado por la última del Split. Nos indica que comienza la ejecución de las subacciones de un Split, de esta forma no puede ejecutarse subacciones de un Split de alguna otra acción hasta que éste literal sea liberado. El literal do es el token que se pasan entre las subacciones de un Split. Nos es útil para que las subacciones se ejecuten en un orden predefinido. Por último, el literal arg es utilizado para asegurar que si una subacción del Split instancia una variable con un cierto objeto y dicha variable está en la interfaz de alguna subacción posterior en el Split, entonces ésta última subacción debe instanciar la variable al mismo objeto. Para terminar de entender el sistema de token que describimos, veamos como quedaría la acción M ove una vez colocados los mismos. Teníamos el esquema de acción: Move(A, B, C : Bloque) pre : {on(a, B), clear(a), clear(c)} add : {on(a, C), clear(b)} del : {on(a, B), clear(c)} Luego, dividíamos la acción M ove en dos subacciones: Move 1 (A, B : Bloque) pre : {on(a, B), clear(a)} add : {clear(b)} del : {on(a, B)} Move 2 (A, C : Bloque) pre : {clear(c)} add : {on(a, C)} del : {clear(c)} Ahora si colocamos los tokens como se describió anteriormenete en Move 1 y Move 2 : Move 1 (A, B : Bloque) pre : {on(a, B), clear(a), procnone} add : {clear(b), do Move 2, arg(a)} del : {on(a, B), procnone} Move 2 (A, C : Bloque) pre : {clear(c), do Move 2, arg(a)} add : {on(a, C), procnone} del : {clear(c), arg(a)} 26

28 A continuación describimos con más detalle cómo se implementa el sistema de tokens. Sea a un esquema de acción y a 1,..., a k un Split de a. Token procnone. Si el Split es más de una subacción, agregaremos el token procnone en las secciones pre y del de a 1 y en la seccción add de a k. Si el Split es una sola subacción agregaremos procnone en la sección pre de a 1. Token do. Si el Split tiene más de una subacción y la subacción a j no es la primera ni la última de las subacciones del Split, agregaremos el token do a j en sus secciones pre y del y el token do a j+1 en su sección add. Si la subacción a j es la primera subacción entonces ponemos solamente el token do a 2 en su sección add. Si a j es la última de las subacciones ponemos en la secciones pre y del el token do a k. Si el Split tiene una sola subacción no necesitaremos del token do. Token arg(). Si una subacción a j tiene como parámetro la variable v y v no es parámetro de ninguna de las subacciones anteriores a a j y v es variable de alguna subacción a r posterior de a j entonces agregamos el token arg(v) en la sección add de a j y en la sección pre de a r. Si arg(v) está en la sección pre de algún a j y ninguna de las subacciones posteriores de a j tiene como parámetro a v, entonces agregamos arg(v) a la sección del de a j 4.6. Definción formal del sistema de tokens Definimos la función que coloca los literales tokens: Γ : A A Γ(a 1...a k ) = a 1...a k donde caso k = 1: a 1 = (pre(a 1) {procnone}, add(a 1 ), del(a 1 )) caso k > 1: a 1 = (pre(a 1) {procnone}, add(a 1 ) {do a 2 }, del(a1 ) {procnone}) a j = (pre(a j) {do a j}, add(a j ) {do a j+1}, del(a j ) {do a j}) con1 < j < k 27

29 a k = (pre(a k) {do a k}, add(a k ) {procnone}, del(a k ) {do a k}) tal que, {do a i }, {procnone} / Lit(A). Notar que Lit(A ) = Lit(A) {procnone} {do a i }. Es importante aclarar que el token arg() no ocurre en la definición de la función Γ porque, recordemos, que en la formalización del problema de planificación pensamos en acciones instanciadas, no en esquemas de acción Obteniendo la transformación de un problema de planificación Hemos visto hasta ahora como dado un problema de planificación P P obtenemos un Split (con tokens) de cada una de las acciones en el dominio de P P. Nos resta especificar cómo se construye el problema de planificación P P a partir de P P el cual usaremos para recuperar una solución de P P mediante una solución de P P. Los literales en P P serán los literales de P P más los literales nuevos que se usaron como tokens. El dominio de P P estará formado por las subacciones que conforman los splits de cada una de las acciones del dominio de P P. El estado inicial de P P será el estado inicial de P P más el literal token procnone. El objetivo de P P será el objetivo de P P más el literal token procnone. Los tipos y sus instancias en P P serán los mismos que en P P (i.e la transformación preserva los tipos y sus instancias) Recuperando un solución de P P a través de su transformación P P y viceversa Si tenemos una solución de P P, una solución de P P será la secuencia de subacciones formada por los splits de cada acción de la solución en el orden en que ocurren. Formalmente, si a 1,..., a n es una solución de P P y a 1 i,..., ak i i es el Split con tokens de la acción a i que se dividió en k i subacciones, entonces a 1 1,..., ak 1 1,..., a1 n,..., a kn n será una solución en P P. 28

30 Si tenemos una solución de P P, sabemos que ésta puede ser únicamente una concatenación de splits de las acciones del dominio de P P. Tomaremos la secuencia formada por tales acciones del dominio P P en el orden en que ocurren sus splits en la solución de P P. Formalmente, si tenemos una solución de P P, tiene que ser de la forma a 1 1,..., ak 1 1,..., a1 n,..., a kn n donde a 1 i,..., ak i i es el Split con tokens de la acción a i del dominio de P P, entonces a 1,..., a n es una solución de P P Split y equivalencia, parte formal El objetivo de esta sección es demostrar que si obtenemos un dominio A a partir del Split de cada una de las acciones de un dominio A, entonces A es equivalente a A. Comencemos introduciendo un poco de notación. Denotaremos con [a] i al i-ésimo elemento de la cadena a y diremos a a cuando i : [a] i = a (sobrecargamos el operador de pertenecia). Un tramo inicial propio de una cadena a es una cadena b tal que a = b a y b ε, a. Si S, A i, B i conjuntos, con i = 1,..., n, denotaremos al conjunto (S A 1... A n ) \ B 1 \... \ B n con la expresión S i n A i \ i n B i. Por último, sea α una función Split, definimos α = Γ α. Definimos un nuevo dominio cuyas acciones serán únicamente las subacciones de las acciones del primero. Definición 5. Sea A un dominio y α una función Split sobre A. Split α (A) = {a : a A tq a α(a)}. El siguiente teorema que es el resultado principal de esta sección, nos asegura que un dominio y su split son equivalentes vía ciertas traducciones en cualquier contexto. Teorema 2. Sea A un dominio y α una función Split sobre A, entonces A T,t,t C Split α (A) con C Σ A Σ A, T (s) = s {procnone}, t(a 1...a n ) = α(a 1 )... α(a n ) y t tal que t (t(a)) = a. La demostración la dejaremos para más adelante, ya que necesitaremos para ella probar y discutir otros resultados antes. Comenzamos observando que t(a 1...a n ) = t(a 1 )...t(a n ). A continuación, un lema que nos dice que ocurre cuando se ejecuta un tramo inicial propio de un Split. 29