PRÁCTICA FINAL DE IRC - Departamento de Ingeniería ... · Inteligencia en Redes de Comunicaciones...

PRÁCTICA FINAL DE IRC

Pablo Jiménez Bermejo Aitor Rubio Elguea

Ing. de Telecomunicación, 5º curso

Inteligencia en Redes de Comunicaciones Práctica Final Ing. de Telecomunicación, 5º curso

Pablo Jiménez BermejoAitor Rubio Elguea

1

Introducción En la presente práctica hemos desarrollado un planificador de rutas de metro con aprendizaje. Esto significa que el software que presentamos es capaz de calcular la ruta óptima entre dos puntos cualesquiera de la red de metro de Madrid, así como otras funciones auxiliares. Estas otras funciones se pueden resumir en variantes de cálculo para las rutas, presentación del conjunto total de rutas calculadas, o la asociación de puntos de interés de la ciudad con la red de metro, de forma que se pueda presentar un entorno más amigable al usuario. Además, se presentan también de forma destacada los puntos de la red de metro que permite el acceso a otros tipos de transporte (enlace con aeropuerto, estaciones de tren de largo recorrido, autobuses...) por ser éstos los de uso más común. Es importante destacar que para el desarrollo de este programa hemos utilizado unos métodos genéricos, al tiempo que utilizamos una base de conocimientos externa, de forma que no sólo es aplicable este programa a cualquier red de metro (con los ficheros con los datos adecuados), sino que también sirve para enrutamiento en redes de ordenadores (aplicación más común en nuestro entorno habitual) o cualquier tipo de red (carreteras, tren, aéreas, canalizaciones, etc.)

Codificación de la información

Base de conocimientos La base de conocimientos sobre la que trabaja el programa está almacenada en un fichero externo, que en este caso se ha guardado con el nombre “completo.txt”. En él, se presenta la información relativa a la red de metro de Madrid con el siguiente formato: connection(argüelles,san_bernardo,cuatro). connection(san_bernardo,bilbao,cuatro). connection(bilbao,alonso_martinez,cuatro). connection(alonso_martinez,colon,cuatro). connection(colon,serrano,cuatro). connection(serrano,velazquez,cuatro). connection(velazquez,goya,cuatro). connection(goya,lista,cuatro). En este pequeño ejemplo, vemos que la unidad mínima de información no son las estaciones individuales de la red, sino las conexiones entre cada una de ellas. Vemos que el formato definido es una conexión entre dos estaciones y la línea de metro que las une. De esta forma, enlazando todas las estaciones de la red, el programa puede seguir desde cada estación todas las posibles conexiones que tiene a través de todas las líneas a las que pertenece.



2

Desde el principio nos planteamos cuál sería el formato más conveniente en la representación de la información, planteándonos otras opciones: el uso de listas o de tuplas más complejas, que incluyeran todas las conexiones correspondientes a cada estación, entre otras. La primera de estas dos soluciones no era viable, ya que las listas sólo tienen sentido en el contexto de una línea completa, lo que provoca algunos problemas a la hora de establecer las interconexiones con otras líneas; en cuanto a las tuplas más complejas, se vuelve también demasiado complejo analizar las implicaciones de cada uno de los elementos de la tupla para decidir si seguirlos o no, que optar por tuplas sencillas, como es nuestro caso, en el que cada conexión en principio se sigue siempre, y se analiza posteriormente si estamos en un punto repetido en la búsqueda.

Grafía utilizada En cuanto a la grafía que habríamos de utilizar, intentamos ceñirnos en la medida de lo posible a la empleada en los documentos oficiales empleados por la propia red de metro, en concreto con la usada en los planos de mano que cualquier usuario puede tener. De esta forma, cualquier usuario en principio inexperto puede hacer funcionar el programa sin más que escribir adecuadamente el nombre de las estaciones, o mejor dicho, escribiéndolo de igual forma a como aparece en los mencionados planos de bolsillo. No obstante, hay algunas excepciones; la más obvia es que no se pueden emplear espacios en blanco, por lo que fueron sustituidos por un guión bajo “_” (por ejemplo: “gran_via”). Asimismo, las comillas en los nombres (como en la estación “O’Donell”) no pueden aparecer, por lo que hubo que quitarlas (así, queda “odonell”). Aunque sí que se admiten algunos caracteres especiales (por ejmplo: “argüelles”, con diéresis). Respetar la grafía de los planos de bolsillo es importante sobre todo en abreviaturas, como por ejemplo en “avda_de_america”.

Presentación de resultados Los resultados del programa se pueden observar de dos formas distintas. Una de ellas, inmediata, se presenta en el apartado “Interacción con el usuario”, en la que se presentan por pantalla directamente los resultados obtenidos. Sin embargo, y dado que a veces los resultados son bastante extensos, conviene analizarlos más despacio. Por ese motivo el programa genera un fichero “soluciones.txt” en el que se almacenan todos los resultados de ejecuciones sucesivas del programa; es un fichero de texto sencillo que puede consultarse posteriormente con cualquier editor, y que es creado por el programa en caso de ser la primera ejecución y no existir previamente. En este fichero de resultados se almacena la fecha y hora de ejecución y un listado de los datos obtenidos, pero sin el formato de presentación en pantalla que veremos más adelante; sencillamente se dan todas las posibles soluciones de rutas como dos listas: una de ellas con las estaciones que se van atravesando y otra con las líneas empleadas en ir entre cada una de las estaciones. Podemos ver que esto corresponde con la



3

información almacenada en las tuplas de la base de conocimientos, sencillamente se toman los elementos que corresponden a la solución deseada. Así, por ejemplo, un resultado de una ejecución en la que se buscan rutas entre las estaciones de “valdezarza” y “gran_via”: -------------Sun Dec 21 21:52:42 2003-------------.

solucion(valdezarza,gran_via,[valdezarza, francos_rodriguez, guzman_el_bueno, islas_filipinas, canal, quevedo, san_bernardo, noviciado, santo_domingo, opera, sol, gran_via],[siete, siete, siete, siete, dos, dos, dos, dos, dos, dos, uno]).

solucion(valdezarza,gran_via,[valdezarza, francos_rodriguez, guzman_el_bueno, islas_filipinas, canal, quevedo, san_bernardo, noviciado, santo_domingo, opera, sol, gran_via],[siete, siete, siete, siete, dos, dos, dos, dos, dos, dos, uno]).

solucion(valdezarza,gran_via,[valdezarza, francos_rodriguez, guzman_el_bueno, islas_filipinas, canal, alonso_cano, gregorio_marañon, avda_de_america, cartagena, parque_de_las_avenidas, barrio_de_la_concepcion, pueblo_nuevo, quintana, el_carmen, ventas, diego_de_leon, nuñez_de_balboa, ruben_dario, alonso_martinez, chueca, gran_via],[siete, siete, siete, siete, siete, siete, siete, siete, siete, siete, siete, cinco, cinco, cinco, cinco, cinco, cinco, cinco, cinco, cinco]).

solucion(valdezarza,gran_via,[valdezarza, francos_rodriguez, guzman_el_bueno, islas_filipinas, canal, alonso_cano, gregorio_marañon, avda_de_america, cartagena, parque_de_las_avenidas, barrio_de_la_concepcion, pueblo_nuevo, quintana, el_carmen, ventas, diego_de_leon, nuñez_de_balboa, ruben_dario, alonso_martinez, chueca, gran_via],[siete, siete, siete, siete, siete, siete, siete, siete, siete, siete, siete, cinco, cinco, cinco, cinco, cinco, cinco, cinco, cinco, cinco]).

Aprendizaje El título de nuestra práctica indica que el programa posee un pequeño sistema de aprendizaje. Más adelante detallaremos cómo funciona; aquí, puesto que estamos hablando de la codificación de la información, hablaremos de cómo almacenamos la información “aprendida” por el programa. Dado que los datos de partida sobre los que trabajamos están almacenados en un fichero externo que hemos llamado “completo.txt”, es lógico que cualquier otra información adicional sobre la que queramos trabajar también se guarde en dicho fichero. Así, las últimas entradas del archivo tendrán el mismo aspecto que toda la información restante: % Aprendizaje del programa connection(puerta_del_sol,sol,trasbordo). connection(universidad_carlos_iii,leganes_central,trasbordo). Podemos ver que en la posición de la tupla correspondiente al número de línea se ha incluido la palabra clave “trasbordo”, que identifica el nuevo destino “aprendido” como algo externo a la red de metro, de forma que no se puede incluir en los cálculos de rutas como estación intermedia pero sí como destino. Esto nos da ya una pequeña información de cómo funciona el mecanismo de aprendizaje: identifica lugares de la ciudad con la estación de metro más próxima, y es por eso que las nuevas entradas sólo pueden constar como destino de una ruta.



4

Algoritmos implementados Para el desarrollo de esta práctica se han empleado varios algoritmos parciales encaminados a proporcionar el resultado final. A continuación veremos cada uno de ellos con más detalle.

“rutal” Para comprender mejor el funcionamiento del algoritmo veremos primero en qué consiste:

rutal(From, To, Path, Lineas,Limit) :- rutal(From, To, Path, Lineas, [From],[],Limit). rutal(To, To, [To],[],_,_,_). rutal(From, To, [From|Path],[Lin|Lineas],Visited,Lvisited,Limit) :- nel(Visited,N),M is N-1,M<Limit, (connection(From, Via,Lin) ; connection(Via, From,Lin) ), ( (not(member(Via,Visited))) ,

no_espuria(Lvisited), (rutal(Via,To,Path,lineas,[Via|Visited],[Lin |Lvisited] ,Limit))

). Este algoritmo busca todas las rutas con número de paradas menor que “Limit”. Es un algoritmo de inundación: en cada paso sigue todas las conexiones desde el punto en el que estamos hasta cualquier otra parada a la que esté conectada (esto lo evaluamos analizando si la parada forma parte de la tupla empleada en la representación de datos tanto en primer como en segundo lugar). Es necesario llevar un control de errores: se evitan bucles (líneas circulares o bucles hechos con varias líneas), llevando control de las paradas ya visitadas (“visited”), y se excluyen los enlaces marcados con “trasbordo” (“no_espuria”) como puntos intermedios (sólo son destinos, como hemos indicado antes). Lógicamente, el algoritmo es recursivo; el caso final de la recursión se da en el momento en que va de una parada a ella misma. Queremos destacar el uso de la función “nel”, que nos proporciona el número de elementos de una lista.

“rutalt” De nuevo veremos en primer lugar la propia implementación del algoritmo para comentarla a continuación:



5

rutalt(From, To, Path, Lineas,Limit) :- rutalt(From, To, Path,Lineas, [From],[],Limit). rutalt(To, To, [To],[],_,_,_). rutalt(From, To, [From|Path],[Lin|Lineas],Visited,Lvisited,Limit):- list_to_set(Lvisited,L2),nel(L2,N1),nel(Visited,M),N2 is M-1,T is(3*N2 + 5*N1),T< Limit, (connection(From, Via,Lin) ; connection(Via, From,Lin) ), ( (not(member(Via,Visited))),

no_expuria(Lvisited), (rutalt(Via, To, Path, Lineas,[Via|Visited],[Lin|Lvisited],Limit))

). Este algoritmo busca una ruta que tarde menos de “Limit” minutos en completarse. Para ello, no considera únicamente el número de paradas que se recorren, como hacía el algoritmo anterior, sino que también tiene en cuenta los trasbordos que es necesario hacer para cambiar de líneas. Dado que no merece la pena individualizar el tiempo empleado en cada recorrido entre estaciones y en cada trasbordo, se ha optado por tomar un valor estimado que describa, en media, los tiempos necesarios para realizar un trasbordo (5 minutos) y para avanzar de una estación a la siguiente dentro de una línea (3 minutos). Con estos valores, se calcula el tiempo necesario para recorrer una ruta y, al igual que antes, se buscan aquellas que necesiten menos de una cantidad, en este caso “Limit”. Por lo demás, este algoritmo es muy similar al anterior: se siguen todas las conexiones desde el punto actual, se lleva control de errores para evitar bucles y “trasbordos”, y la recursión finaliza cuando se va de una parada a ella misma. Una pequeña diferencia estriba en el uso de “Lvisited”, que lleva control del número de líneas visitadas de la misma forma que “Visited” lo lleva del número de estaciones. En este caso destacamos el uso de la función “list_to_set”, que elimina elementos repetidos de una lista.

“rutac” Como antes, vemos primero la implementación del algoritmo:

rutac(From, To, Path, Lineas) :- rutac(From, To, Path,Lineas,[], [From]). rutac(To, To, [To],[],_,_). rutac(From, To, [From|Path],[Lin|Lineas],Visited,Lvisited) :- (connection(From, Via,Lin) ; connection(Via, From,Lin) ), not(member(Via,Visited)), no_expuria(Lvisited), (rutac(Via, To, Path, Lineas,[Via|Visited],[Lin|Lvisited]),!).



6

En este caso, vemos que esencialmente el algoritmo es muy parecido al algoritmo “rutal”, con la salvedad de que hace uso del operador de corte (!); esto lo hace para mostrar el primer resultado obtenido (válido) por el programa. Dado que únicamente están definidas las conexiones entre estaciones, no hay a simple vista ni de forma lógica una ruta “óptima”, sino que hay que calcularla. Esto hace que el resultado obtenido por esta función no sea necesariamente ni el más “sencillo” ni el más corto, sino que corresponde con el primer “hilo” de ejecución que finaliza el cálculo. (No tiene sentido hablar de hilos de ejecución reales, el programa no es concurrente, pero nos da una idea del intento de simultaneidad de cálculo de “Prolog” al seguir varias alternativas).

“ruta_menos_paradas” Vemos el código del algoritmo:

ruta_menos_paradas(From,To,Ruta,Lineas):- mascorta2(From,To,_,_,N,0),rutal(From,To,Ruta,Lineas,N),ins_log(From,To,Ruta,Lineas). mascorta2(From,To,Ruta,Lineas,N,Limit):- ( (rutal(From,To,Ruta,Lineas,Limit),N is Limit,!) ;

(L1 is Limit+1,mascorta2(From,To, Ruta,Lineas,N,L1)) ).

Vemos que este algoritmo invoca a su vez a otros dos: “mascorta2”, cuyo código se presenta a continuación de “ruta_menos_paradas”, y “rutal”, que como ya hemos visto antes busca todas las rutas que lleven del origen (“From”) al destino (“To”) con un número de paradas intermedias menor que “Limit”. El algoritmo “mascorta2” invoca recursivamente a “rutal” incrementando de forma progresiva el valor de “Limit”, de forma que averigua el valor mínimo de “Limit” para el cual existe un resultado. Este valor es el mínimo número de paradas con el que se puede calcular una ruta. Así, al invocar desde “ruta_menos_paradas” a “rutal”, se hace con el valor de “Limit” que nos proporciona “mascorta2”, con lo que se obtienen todas las rutas con el mínimo número de paradas posibles que son solución del problema.

“ruta_menos_tiempo” El código correspondiente al algoritmo:

ruta_menos_tiempo(From,To,Ruta,Lineas):- mtiempo(From,To,_,_,N,0),rutalt(From,To,Ruta,Lineas,N),ins_log(From,To,Ruta,Lineas). mtiempo(From,To,Ruta,Lineas,N,Limit):- ( (rutalt(From,To,Ruta,Lineas,Limit),N is Limit,!);

(L1 is Limit+1,mtiempo(From,To,Ruta,Lineas,N,L1)) ).



7

Este algoritmo es muy similar a “ruta_menos_paradas”. También invoca a una función intermedia (“mtiempo”) y después a “rutalt” que, como ya hemos comentado, es similar a “rutal” pero minimizando el tiempo en lugar del número de estaciones. Y como en la anterior, la función “mtiempo” invoca recursivamente a “rutalt” incrementando de forma progresiva el valor de “Limit”, para hallar el valor mínimo que proporciona un resultado válido; este resultado es el que se usa para invocar una última vez a “rutalt” para obtener todas las soluciones posibles de menor tiempo.

Interacción con el usuario A la hora de elaborar la interfaz con el usuario de este programa se ha intentado hacerlo de la forma más amigable posible, dentro de las limitaciones de “Prolog” en ese sentido. En primer lugar, el comando para invocar la función principal, (el nombre del programa, realmente), es “metro”. Al teclearlo, (seguido, como siempre y en todas las instrucciones que se le dan al programa, por un punto), se nos presenta un menú con las distintas opciones del programa:

A partir de este menú se elige la opción deseada y con ello se invoca alguno de los algoritmos vistos anteriormente:



8

• Ruta más corta -> invoca a “ruta_menos_paradas”. • Ruta más rápida -> invoca a “ruta_menos_tiempo”. • Todas las rutas -> invoca directamente a “rutal”. • Cálculo de una ruta cualquiera -> invoca a “rutac”. • Cálculo de una ruta a un punto de la comunidad -> emplea el sistema de

aprendizaje del programa. • Cálculo de ruta hasta ... -> calcula “ruta_menos_tiempo” entre la parada de

origen especificada y la de destino asociada (más cercana) al lugar indicado en la opción del menú.

Tras elegir la correspondiente opción, el programa nos pregunta los datos que necesita para realizar los cálculos, en principio las paradas de origen y destino de la ruta que ha de calcular:

Como hemos indicado anteriormente, el resultado de la ejecución de todos los algoritmos es siempre un conjunto de dos listas, uno con las paradas y otro con las líneas empleadas en el recorrido (Véase “Presentación de resultados” dentro del epígrafe “Codificación de la información”). Para representar este resultado de forma más amigable al usuario se emplea la función “impr” que, empleando las mencionadas listas, presenta la información de forma lógica al usuario. Así, si ante el problema de calcular la ruta más rápida entre las estaciones de “sol” y “avda_de_america” tomamos la solución extraída del fichero “soluciones.txt”:



9

solucion(sol,avda_de_america,[sol, gran_via, tribunal, alonso_martinez, gregorio_marañon, avda_de_america],[uno, uno, diez, diez, siete]).

Ésta aparecerá por pantalla como:

Vemos que no solamente se presentan los resultados contenidos en las listas, sino que también se muestran unas pequeñas estadísticas, con el número de paradas, el número de trasbordos y el tiempo empleado.

Aprendizaje Hemos mencionado varias veces en esta memoria el sistema de aprendizaje del programa. Básicamente consiste en la posibilidad de poder introducir nuevas entradas en la base de conocimientos referentes a destinos finales. Así, por ejemplo, si un usuario especifica un nuevo destino desconocido por el programa, éste le preguntará cuál es la parada de metro más próxima a dicho destino. Cuando el usuario proporcione la información pedida, el programa, usando la función “aprender_correspondencias”, llamará a una función auxiliar “ins_basedatos” para



10

introducir el nuevo destino en el fichero “completo.txt” que, recordamos, servía para almacenar todas las correspondencias y destinos sobre los que trabaja el programa.

Si se pidiera de nuevo al programa a continuación la ruta para ir al nuevo destino especificado, ahora sí sabría dónde está, puesto que ya está almacenado en la base de datos, y entonces podría calcular la ruta adecuadamente. Vemos que este mecanismo proporciona una gran versatilidad al programa, al poder adaptarlo según las necesidades del usuario, ya que se pueden modificar los datos de partida de forma dinámica. No obstante, el fichero de entrada está escrito en texto simple, por lo que en caso de necesidad también se podría modificar manualmente.

Consideraciones finales de diseño Al margen de todo lo comentado hasta el momento, nos parece importante destacar algunos problemas de relevancia que hemos encontrado en el diseño. El primero de ellos fue un intento de incluir una opción más en el menú principal, que calculara la ruta con menor número de trasbordos. Al intentar realizarlo comprobamos que para que esta opción fuera factible, la única solución posible era calcular la totalidad de rutas posibles y a partir de ahí elegir las de menor número de trasbordos. Esto supondría un desmesurado coste computacional, por lo que preferimos no seguir adelante con esta opción.



11

Otro problema, y éste es a nuestro entender más grave, se nos presentó al comprobar que los resultados que nos aparecían estaban duplicados en los registros. Esto es debido al back-tracking, que hace que por cada camino de búsqueda posible se establezca más de un “hilo” de ejecución, por lo que se duplica el número de registros. Dado que controlamos la impresión de los resultados, este problema es fácilmente subsanable. No es tan fácil de corregir sin embargo el problema relacionado con el tiempo y el coste computacional de los cálculos más largos. En efecto, si se solicita un cálculo como el de todas las rutas posibles o uno que implique demasiadas combinaciones, el proceso puede ser inabordable.

PRÁCTICA FINAL DE IRC - Departamento de Ingeniería ... · Inteligencia en Redes de Comunicaciones...

Documents

Transcript of PRÁCTICA FINAL DE IRC - Departamento de Ingeniería ... · Inteligencia en Redes de Comunicaciones...