ag-costane: algoritmos genéticos para el cálculo del

UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMÁTICA

GRADO EN INGENIERÍA INFORMÁTICA

TRABAJO FIN DE GRADO

AG-COSTANE: Algoritmos genéticos para elcálculo del centroide de un grupo de series

temporales mediante una distancia no Euclídea

Pablo León Alcaide

Julio, 2017

AG-COSTANE: ALGORITMOS GENÉTICOS PARA EL CÁLCULO DELCENTROIDE DE UN GRUPO DE SERIES TEMPORALES MEDIANTE UNA

DISTANCIA NO EUCLÍDEA

EscuelaSuperiorde Informática

UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMÁTICA

Tecnologías y Sistemas de Información

TECNOLOGÍA ESPECÍFICA DE

COMPUTACIÓN

TRABAJO FIN DE GRADO

AG-COSTANE: Algoritmos genéticos para elcálculo del centroide de un grupo de series

temporales mediante una distancia no Euclídea

Autor: Pablo León Alcaide

Director: Dr. Luis Jiménez Linares

Julio, 2017

Pablo León Alcaide

Ciudad Real – Spain

E-mail: [email protected]éfono: 660 933 959

c© 2017 Pablo León Alcaide

Permission is granted to copy, distribute and/or modify this document under the terms of the GNUFree Documentation License, Version 1.3 or any later version published by the Free SoftwareFoundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copyof the license is included in the section entitled "GNU Free Documentation License".Se permite la copia, distribución y/o modificación de este documento bajo los términos de laLicencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada porla Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta incluida enel apéndice titulado «GNU Free Documentation License».Muchos de los nombres usados por las compañías para diferenciar sus productos y servicios sonreclamados como marcas registradas. Allí donde estos nombres aparezcan en este documento, ycuando el autor haya sido informado de esas marcas registradas, los nombres estarán escritos enmayúsculas o como nombres propios.

i

TRIBUNAL:

Presidente:

Vocal:

Secretario:

FECHA DE DEFENSA:

CALIFICACIÓN:

PRESIDENTE VOCAL SECRETARIO

Fdo.: Fdo.: Fdo.:

iii

Resumen

El uso de una distancia elástica, como DTW, resulta muy importante si se quiere teneren cuenta la forma de las series temporales cuando se mide la similitud entre ellas. Todavíamás importante es su uso cuando se desea obtener un representante de un conjunto de series.La serie prototipo del conjunto puede verse completamente deformada, sin representar laestructura de las series, si se utiliza una distancia Euclídea. Sin embargo, el uso de unadistancia elástica puede obtener un representante en el que se resuma correctamente la formade las series.

El método propuesto estima un representante de un conjunto de series utilizando para elloDTW como medida de distancia. Este problema tiene una solución óptima con una com-plejidad temporal demasiado alta para ser utilizada con más de unas pocas series. Por ello,se ha planteado como un problema de optimización que se resuelve mediante un algoritmogenético.

El algoritmo diseñado supera a las soluciones más relevantes de la literatura en los ex-perimentos que se han realizado, obteniendo mejores representantes en un tiempo menor.Además, el algoritmo es escalable a grandes conjuntos de series, característica que no pre-senta ningún metodo hallado en la literatura.

V

Abstract

The use of an elastic distance, such as DTW, is very important if one wants to take intoaccount the shape of the time series when measuring the similarity between them. Evenmore important is its use when it is desired to obtain a representative of a set of series. Theprototype series of the set can be completely deformed, without representing the structure ofthe series, if an Euclidean distance is used. However, the use of an elastic distance can obtaina representative in which the shape of the series is summed up correctly.

The proposed method estimates a representative of a set of series using DTW as a measureof distance. This problem has an optimal solution with a temporary complexity too high tobe used with more than a few series. Therefore, it has been considered as an optimizationproblem that is solved by a genetic algorithm.

The algorithm designed surpasses the most relevant solutions of the literature in the ex-periments that have been carried out, obtaining better representatives in a shorter time. Inaddition, the algorithm is scalable to large sets of series, a feature that does not present anymethod found in the literature.

VII

Agradecimientos

Llegado a este punto me gustaría agradecer a aquellos que han contribuido a que el caminohaya sido más fácil, más llevadero.

En primer lugar dar las gracias a mis padres. Por todo. Por el gran esfuerzo. Por la con-fianza, por los consejos, por la ayuda. Por los viajes a Ciudad Real y los tuppers. Muchasgracias.

A mis hermanos, Luis y Miguel. Que siempre están ahí, y de una forma u otra me hanayudado a lograr llegar hasta aquí.

A mi amigo Alberto, que ya llevamos muchas, y las que quedan.

A mis amigos de la universidad, con quienes he pasado grandes momentos. En especial aMarcos, por las risas y la cantidad de buenas experiencias que hemos vivido, y por algún queotro debate linguístico.

Y por último a Luis, mi tutor, por la ayuda y por brindarme la oportunidad de hacer untrabajo tan divertido.

Pablo León Alcaide

IX

A mis padres

xi

Índice general

Resumen V

Abstract VII

Agradecimientos IX

Índice general XIII

Índice de cuadros XVII

Índice de figuras XIX

Índice de listados XXI

Listado de acrónimos XXIII

1. Introducción 1

1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Objetivos 5

2.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1. Implementación de algoritmo genético . . . . . . . . . . . . . . . . 5

2.2.2. Desarrollo de algoritmos de aprendizaje automático . . . . . . . . . 6

2.2.3. Desarrollo de una API REST . . . . . . . . . . . . . . . . . . . . . 6

2.2.4. Diseño e implementación de un cliente web . . . . . . . . . . . . . 6

3. Antecedentes 7

3.1. DTW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.1. DTW clásico, especificación formal y algoritmo . . . . . . . . . . 8

XIII

3.1.2. Variantes de DTW . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.3. Experiementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.4. Usos actuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2. Algoritmos genéticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.1. Algoritmo genético clásico . . . . . . . . . . . . . . . . . . . . . . 20

3.2.2. Otros algortimos genéticos . . . . . . . . . . . . . . . . . . . . . . 21

3.3. Algoritmos de aprendizaje: K-Means, KNN y NC . . . . . . . . . . . . . . 26

3.3.1. K-Means . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.2. KNN: K-Nearest Neighbors . . . . . . . . . . . . . . . . . . . . . 27

3.3.3. NC: Nearest Centroid . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4. Métodos actuales: DBA y COMASA . . . . . . . . . . . . . . . . . . . . . 29

3.4.1. DBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4.2. COMASA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5. Framework: DEAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4. Metodología 37

4.1. Metodologías ágiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.1. Valores del Manifiesto Ágil . . . . . . . . . . . . . . . . . . . . . 37

4.1.2. Principios del Manifiesto Ágil . . . . . . . . . . . . . . . . . . . . 38

4.2. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.1. Equipo Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.2. Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.3. Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.4. Reuniones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3. Extreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3.1. Buenas prácticas en XP . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4. Aplicación de la metodología . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4.1. Definición de roles . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4.2. Definición del Product Backlog . . . . . . . . . . . . . . . . . . . 44

4.4.3. Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.5. Herramientas Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.5.1. Herramientas para el desarrollo . . . . . . . . . . . . . . . . . . . 48

4.5.2. Herramientas para la documentación . . . . . . . . . . . . . . . . . 49

4.5.3. Lenguajes de programación y frameworks . . . . . . . . . . . . . . 49

4.5.4. Librerías científicas . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.6. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

xiv

5. Resultados 53

5.1. Visión global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.2. Sprint 1: Estudio e implementación de DBA y COMASA . . . . . . . . . . 53

5.2.1. Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2.2. Implementación de DTW . . . . . . . . . . . . . . . . . . . . . . . 55

5.2.3. Resultados experimentales . . . . . . . . . . . . . . . . . . . . . . 57

5.3. Sprint 2: Desarrollo de AG-naive . . . . . . . . . . . . . . . . . . . . . . . 59

5.3.1. Algoritmo genético . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.3.2. Resultados experimentales . . . . . . . . . . . . . . . . . . . . . . 61

5.4. Sprint 3: Desarrollo de AG-segments . . . . . . . . . . . . . . . . . . . . . 62

5.4.1. Individuos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.4.2. Operador de cruce . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.4.3. Operador de mutación . . . . . . . . . . . . . . . . . . . . . . . . 66

5.4.4. Operador de evaluación . . . . . . . . . . . . . . . . . . . . . . . 70

5.4.5. Estudio de complejidad . . . . . . . . . . . . . . . . . . . . . . . . 70

5.4.6. Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.5. Sprint 4: Desarrollo de AG-SEGMENTS-COOP . . . . . . . . . . . . . . . 76

5.5.1. Algoritmo genético . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.5.2. Estudio de complejidad . . . . . . . . . . . . . . . . . . . . . . . . 77

5.6. Sprint 5: Desarrollo de algoritmos de aprendizaje . . . . . . . . . . . . . . 77

5.6.1. K-Means con DTW . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.6.2. NC con DTW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.7. Sprint 6: Desarrollo de un servidor REST . . . . . . . . . . . . . . . . . . 82

5.7.1. API REST: Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.7.2. API REST: Implementación . . . . . . . . . . . . . . . . . . . . . 84

5.7.3. API REST: Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.7.4. Despliegue en Bluemix . . . . . . . . . . . . . . . . . . . . . . . . 88

5.8. Sprint 7: Diseño e implementación de un cliente web . . . . . . . . . . . . 90

5.8.1. Cliente web: Prototipo inicial . . . . . . . . . . . . . . . . . . . . 90

5.8.2. Cliente web: Versión final . . . . . . . . . . . . . . . . . . . . . . 90

5.8.3. Comunicación con el servidor y arquitectura . . . . . . . . . . . . 95

6. Conclusiones 99

6.1. Análisis de consecución de objetivos . . . . . . . . . . . . . . . . . . . . . 99

6.2. Competencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.3. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

xv

A. Historias de usuario 103

B. Manual de usuario 109

Referencias 111

xvi

Índice de cuadros

3.1. Complejidad de los operadores . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1. Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2. Iteración 1: Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . 45







5.1. Resultados de COMASA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2. Resultados de AG-naive . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.3. Parametrización de AG-segments (I) . . . . . . . . . . . . . . . . . . . . . 68

5.4. Parametrización de AG-segments (II) . . . . . . . . . . . . . . . . . . . . 72

5.5. Parametrización de AG-segments (III) . . . . . . . . . . . . . . . . . . . . 72

5.6. Complejidad de los operadores . . . . . . . . . . . . . . . . . . . . . . . . 72

5.7. Conjunto de series: Experimentos de cálculo de centroide (I) . . . . . . . . 73

5.8. Experimentos NC: Comparación de tasas de errores . . . . . . . . . . . . . 82

5.9. Conjunto de series: Experimentos con NC . . . . . . . . . . . . . . . . . . 82

A.1. Historia de usuario: Investigación sobre DEAP . . . . . . . . . . . . . . . . 103

A.2. Historia de usuario: Búsqueda de datos de naturaleza temporal . . . . . . . 103

A.3. Historia de usuario: Estudio e implementación de soluciones existentes . . . 103

A.4. Historia de usuario: Investigación sobre DEAP . . . . . . . . . . . . . . . . 104

A.5. Historia de usuario: Experimentos con las soluciones de la literatura . . . . 104

A.6. Historia de usuario: Implementación de algoritmo genético genérico . . . . 104

A.7. Historia de usuario: Experimentos con el algoritmo genético genérico . . . 104

A.8. Historia de usuario: Implementación de operador de cruce . . . . . . . . . 105

XVII

A.9. Historia de usuario: Implementación de operador de mutación . . . . . . . 105

A.10.Historia de usuario: Implementación e integración algoritmo genético . . . 105

A.11.Historia de usuario: Parametrización y comparación de resultados . . . . . 105

A.12.Historia de usuario: Implementación de algoritmo genético cooperativo . . 106

A.13.Historia de usuario: Experimentos con algoritmo genético cooperativo . . . 106

A.14.Historia de usuario: Implementación de algoritmo K-Means con DTW . . . 106

A.15.Historia de usuario: Implementación de algorimo NC con DTW . . . . . . . 106

A.16.Historia de usuario: Experimentos con algoritmo NC . . . . . . . . . . . . 107

A.17.Historia de usuario: Clasificaciones difusas con NC . . . . . . . . . . . . . 107

A.18.Historia de usuario: Implementación del servidor REST . . . . . . . . . . . 107

A.19.Historia de usuario: Extensión del servidor REST . . . . . . . . . . . . . . 107

A.20.Historia de usuario: Implementación del cliente web . . . . . . . . . . . . . 108

xviii

Índice de figuras

1.1. Electrocardiograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Centroides: Euclídea y DTW . . . . . . . . . . . . . . . . . . . . . . . . . 2

3.1. Alineamiento entre las series Xe Y . . . . . . . . . . . . . . . . . . . . . 10

3.2. Condiciones globales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3. Cuatro tipos de condiciones locales . . . . . . . . . . . . . . . . . . . . . . 13

3.4. Reducción de la dimensión previa a la aplicación de DTW. . . . . . . . . . 14

3.5. FastDTW con radio = 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.6. Operador de selección de Ruleta . . . . . . . . . . . . . . . . . . . . . . . 24

3.7. Modelo cooperativo de tres especies [PDJ00] . . . . . . . . . . . . . . . . 25

3.8. Ejemplo del alinemiento compacto C . . . . . . . . . . . . . . . . . . . . . 32

3.9. Representación en forma de tupla del alineamiento compacto de Fig. 3.8 . . 32

3.10. Algoritmos DEAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1. Ejemplo de proceso Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.1. Mapa conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2. Selección de series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.3. Una clase del conjunto de datos 50words . . . . . . . . . . . . . . . . . . . 58

5.4. Centroide del conjunto de datos 50words . . . . . . . . . . . . . . . . . . . 59

5.5. COMASA: Curva del fitness con una clase de 50words . . . . . . . . . . . . 59

5.6. Centroide del conjunto de datos 50words . . . . . . . . . . . . . . . . . . . 62

5.7. AG-Naive: Curva del fitness con una clase de 50words . . . . . . . . . . . 62

5.8. Ejemplo de segmentos de un alineamiento . . . . . . . . . . . . . . . . . . 64

5.9. Operador de cruce(I): Individuos a cruzar . . . . . . . . . . . . . . . . . . 65

5.10. Operador de cruce(II): Alineamientos . . . . . . . . . . . . . . . . . . . . 65

5.11. Operador de cruce(III): Individuos con secciones a intercambiar marcadas . 66

5.12. Operador de cruce(III): Individuos mutados . . . . . . . . . . . . . . . . . 66

5.13. Ejemplos de mutación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

XIX

5.14. Curvas de fitness para aprendizaje no supervisado (I) . . . . . . . . . . . . 74

5.15. Curvas de fitness para aprendizaje no supervisado (II) . . . . . . . . . . . . 75

5.16. Curvas de fitness para aprendizaje supervisado . . . . . . . . . . . . . . . . 76

5.17. Selección de series de Yoga . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.18. Centroides de Yoga obtenidos en diferentes ejecuciones . . . . . . . . . . . 79

5.19. Cadena de herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.20. Protipo inicial de la interfaz del cliente web . . . . . . . . . . . . . . . . . 91

5.21. Cliente web: Interfaz completa . . . . . . . . . . . . . . . . . . . . . . . . 92

5.22. Cliente web: Ejemplos de mutación . . . . . . . . . . . . . . . . . . . . . 93

5.23. Cliente web: Ejemplo de cruce . . . . . . . . . . . . . . . . . . . . . . . . 93

5.24. Cliente web: Tablas de descripción . . . . . . . . . . . . . . . . . . . . . . 94

5.25. Cliente web: Pestañas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.26. Cliente web: Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

B.1. Cliente web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

B.2. Series en archivo CSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

xx

Índice de listados

5.1. Función que registra los operadores utilizando la clase Toolbox de DEAP . . 61

5.2. «Hello world» con Flask . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.3. Opción de depuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.4. Manejadores de errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.5. Ejemplo de endpoints en el servidor . . . . . . . . . . . . . . . . . . . . . 86

5.6. Despliegue de la aplicación Flask . . . . . . . . . . . . . . . . . . . . . . . 87

5.7. Ejemplo de prueba de un endpoint . . . . . . . . . . . . . . . . . . . . . . 87

5.8. Fichero requirements.txt . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.9. Fichero manifest.yaml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.10. Fichero Procfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

XXI

Listado de acrónimos

API Application Programming Interface

REST REpresentational State Transfer

TFG Trabajo Fin de Grado

AG Algoritmo Genético

DTW Dynamic Time Warping

DDTW Derivated Dynamic Time Warping

NC Nearest Centroid

KNN K-Nearest Neighbors

DEAP Distributed Evolutionary Algorithms in Python

WBAN Wireless Body Area Network

PMX Partially Matched Crossover

SSE Sum of Squared Errors

DBA DTW Barycenter Averaging

COMASA COmpact Multiple Alignment for Sequence Averaging

HTTP Hypertext Transfer Protocol

JSON JavaScript Object Notation

URI Uniform Resource Identifier

CSV Comma-Separated Values

XP eXtreme Programming

UML Unified Modeling Language

HTML HyperText Markup Language

XML eXtensible Markup Language

CSS Cascading Style Sheets

XXIII

Capítulo 1

Introducción

E Nla actualidad, debido al gran aumento del volumen de datos disponibles, en parte gra-cias al incremento de la capacidad de almacenamiento, se hace necesario el desarrollo

de técnicas para su tratamiento que obtengan resultados aceptables en un tiempo razonable.Uno de los tipos de datos más relevantes debido a su abundancia y su diversidad son lasseries temporales. Por ejemplo, las series sísmicas, la evolución de las temperaturas, la re-presentación de un sonido, los movimientos de la bolsa o los electrocardiogramas son seriestemporales.

Debido a la naturaleza temporal de este tipo de datos, las series temporales presentan unosaspectos diferenciales que obligan a tratarlas de forma especial. Sin lugar a dudas, la formaen la que se mide la distancia entre dos series temporales es un aspecto clave cuando lo quese pretende hacer es resumir un conjunto de series en un solo representante, tarea común envarios algoritmos de agrupamiento.

Resumir un conjunto de series temporales en un representante es una tarea fácil cuando seusa para ello una distancia rígida, como la Euclídea o Manhattan. Sin embargo, cuando sedecide utilizar una distancia elástica que mida más naturalmente la similitud, el problema decalcular el representante se vuelve mucho más complejo.

Figura 1.1: Electrocardiograma

1

1.1 MotivaciónResumir un conjunto de series temporales en un representante mediante una distancia elás-

tica, como Dynamic Time Warping (DTW), ampliamente estudiada en la literatura, puede serun factor determinante en la mejora de los resultados de tareas de aprendizaje supervisadoy no supervisado, lidiando con la naturaleza temporal de este tipo de datos de una formanatural. Esto puede resultar en el desarrollo de modelos de aprendizaje más precisos y mejo-res.

En Fig. 1.2 se ilustra la diferencia entre el prototipo de un conjunto de secuencias tem-porales utilizando la distancia Euclídea y DTW (usando uno de los métodos implementadosen este TFG). Como se observa, la distancia Euclídea no capta la forma de las series, dandolugar a un centroide muy lejano del que se podría catalogar como un buen prototipo. Por otrolado, el centroide obtenido mediante la distancia DTW si que representa el conjunto de seriesde una forma mucho más natural.

(a) Conjunto de series

(b) Centroide con la distancia Euclídea (c) Centroide con la distancia DTW

Figura 1.2: Centroides: Euclídea y DTW

Además, las técnicas actuales más utilizadas para encontrar el representante de un conjun-

2

to de series utilizando una distancia elástica pasan por seleccionar aquella serie del conjuntoque más se parece al resto. Estos métodos tienen dos claros inconvenientes. En primer lugar,hay que elaborar una matriz de distancias entre todas las series, lo cuál requiere una enormecantidad de cálculos cuando la cantidad de datos que se maneja es grande. Y en segundolugar, la serie más parecida al resto de series del conjunto puede distar bastante de la quesería la mejor serie que resume ese conjunto.

Así, en el presente Trabajo Fin de Grado (TFG) se desarrolla una técnica para resumirun conjunto de series temporales empleando DTW, dedicandole especial importancia a ha-cer escalables los algoritmos desarrollados para que sean aplicables a grandes cojuntos deseries.

1.2 Problema

El problema de calcular el centroide de un conjunto de series temporales S = {S1, S2, ..., Sn}utilizando la distancia Euclídea es tan sencillo como calcular la media de los elementos decada indice de las series. Así, si se tiene un conjunto de n series de longitud m, el centroideC se calcula como sigue:

Ci =

∑nj=1 Sjin

∀i ∈ {1, 2, ...,m} (1.1)

Las distancias rígidas como la Euclídea, presentan una serie de inconvenientes importan-tes, como su incapacidad para medir de forma natural la distancia entre series similares peroque presentan algún desplazamiento en el tiempo, y estrechamientos o ensanchamientos enlas formas. Estos inconvenientes se pondrán de manifiesto en los siguientes capítulos.

La resolución de este mismo problema haciendo uso de una distancia elástica, como DTW,es mucho más complicada. Esto se debe principalmente a que cuando se mide la similitudentre dos series utilizando una distancia elástica, puede existir una correspondencia de varioselementos de una serie a uno de la otra, en lugar de la relación uno a uno que existe si seutiliza la distancia Euclídea. Por ello, la búsqueda del centroide se convierte en un problemade optimización, en el que se busca una serie que minimice su distancia DTW a las series delconjunto S.

SeaEm el espacio de series de longitudm. Si tenemos un conjunto de n series, el centroideC de ese conjunto se obtiene resolviendo el siguiente problema de minimización:

mınC∈Em

n∑i=1

DTW 2(C, Si) (1.2)

Este problema de minimización se resuelve de forma trivial si se restringe el espacio desecuencias en el que se busca el centroide al conjunto de series del que se parte, es decir,

3

Em = S. En este caso, se tiene que la serie media pertenece al conjunto de series de partida,C ∈ S. Para encontrar la secuancia que minimiza la distancia al resto, sería necesario ela-borar una matriz de distancias, por lo que hay que calcular la distancia DTW entre cada parde series del conjunto. Por tanto, esta resolución trae consigo una complejidad temporal deO(n2), que resulta inviable cuando crece el conjunto de series.

Sin restringir el espacio de búsqueda al conjunto series de partida el problema se complica.De hecho, la serie objetivo es denominada serie de Steiner, relativa a la teoría de árboles deSteiner, y el algoritmo que la obtiene tiene una complejidad temporal y espacial de O(mn),la cuál resulta inviable en cuanto se tiene un conjunto de unas pocas secuencias. Además,durante más de 30 años de investigación, no se ha logrado obtener un algoritmo escalableque calcule la serie de Steiner.

Así, se propone desarrollar un algoritmo basado en una estrategía evolutiva para hallar laserie media de un conjunto de series temporales, utilizando DTW como medida de distan-cia, sin restringir el espacio de búsqueda a las series del conjunto y haciéndolo escalable agrandes conjuntos de series temporales.

1.3 Estructura del documentoEl presente TFG incluye los siguientes capítulos:

Capítulo 2: ObjetivosSe exponen y detallan los objetivos tanto generales como específicos marcados paraeste proyecto.

Capítulo 3: AntecedentesSe realiza un un estudio del estado del arte de los conteptos teóricos utilizados en elproyecto: DTW, algoritmos genéticos, soluciones actuales para el problema propuesto,etc.

Capítulo 4: MetodologíaSe describen las metodologías utilizadas para el desarrollo del proyecto y se detalla suaplicación para la consecución de los objetivos propuestos. seguido para la realizacióndel proyecto.

Capítulo 5: ResultadosSe exponen los algoritmos genéticos implementados, y el servidor y el cliente en losque se integran. También se muestran los resultados experimentales.

Capítulo 6: ConclusionesSe exponen las conclusiones extraídas de la realización del proyecto y se describenalgunas posibles mejoras y extensiones del mismo.

4

Capítulo 2

Objetivos

E N el presente capítulo se presentan los objetivos generales y específicos definidos parael desarrollo del presente proyecto, además de los medios software y hardware utili-

zados. Al ser un proyecto de investigación, resulta de vital importancia acotar el alcance delmismo, para así también facilitar la consecución de las metas definidas.

2.1 Objetivo general

El objetivo principal del proyecto es desarrollar una librería de funciones que permitaobtener el centroide de un conjunto de series temporales utilizando una distancia elástica,concretamente DTW. Para lograrlo se desarrollarán una serie de algoritmos evolutivos, es-tudiando diferentes estrategias y formas de abordar el problema, y comparando las distintassoluciones existentes en la literatura con las propuestas en el proyecto.

La librería contendrá también la implementación de dos algoritmos de aprendizaje, unosupervisado y otro no supervisado que harán uso de los algoritmos evolutivos implementa-dos. El primero de estos corresponde al algoritmo de agrupamiento K-Means integrando enél la distancia DTW. El segundo consiste en el algoritmo Nearest Centroid (NC), una variantedel algoritmo K-Nearest Neighbors (KNN), utilizando DTW como medida de distancia.

2.2 Objetivos específicos

Los objetivos secundarios son aquellas metas que será necesario alcanzar para la consecu-ción del objetivo principal. Estos objetivos se detallan a continuación:

2.2.1 Implementación de algoritmo genético

Los algoritmos genéticos conforman un subconjunto de los algoritmos evolutivos. En elproyecto se implementarán una serie de algoritmos genéticos para obtener el representantede un conjunto de series temporales utilizando como medida de distancia DTW. Para ellos,será necesarió implementar una serie de operadores que definen todo algoritmo genético.Estos son los operadores de mutación, cruce, selección y evaluación. Concluida su imple-mentación, se compararán los resultados de los algoritmos implementados con aquellos en-contrados en la literatura.

5

2.2.2 Desarrollo de algoritmos de aprendizaje automáticoCon el objetivo de integrar el algoritmo implementado en tareas que vayan más allá del

cálculo del centroide de un conjunto de series, se implementarán una serie de algoritmos deaprendizaje que hagan lo utilicen en labores de agrupamiento y clasificación. Por tanto, sedesarrollan una serie de algoritmos que utilizan la distancia DTW para clasificar y agruparseries temporales.

2.2.3 Desarrollo de una API RESTCon el fin de ofrecer la posibilidad de utilizar la librería desarrollada, se implementa una

API REST. A través de esta API se podrán utilizar todos los algoritmos implementados y contodas sus variantes. Una vez diseñada e implementada, se desplegará en la nube. Para ello,se estudiarán distintas alternativas de diferentes proveedores de servicios en la nube.

2.2.4 Diseño e implementación de un cliente webPara visualizar el proceso evolutivo se desarrollará un cliente web que permitirá, de forma

gráfica, observar la evolución de los individuos a lo largo de las generaciones. Se hará espe-cial hincapíe en que se observe la relevancia del proceso de búsqueda del algoritmo genéticoimplementado. Este cliente tendrá como soporte la API REST desarrollada, a través de la cuálse obtendrán los resultados del proceso evolutivo.

6

Capítulo 3

Antecedentes

E N el presente capítulo se muestra el estudio bibliográfico que se ha realizado para eldesarrollo del proyecto. Éste cubre los conceptos más importantes en los que está ba-

sado el TFG. En primer lugar se expone un estudio en profundidad realizado sobre DTW y susvariantes, que abarca gran parte de la literatura relacionada. Después, se dan nociones sobrealgoritmos genéticos. Posteriormente, se detallan los métodos actuales para resolver el pro-blema planteado en el presente proyecto. También explican algunos algoritmos de aprendiza-je supervisado y no supervisado que son implementados con alguna variante posteriormenteen el TFG. Por último, se explica el entorno usado para la implementación de los algoritmosgenéticos.

3.1 DTW

La distancia entre series temporales resulta crítica y es fundamental ser lo más precisoposible, ya que sirve como base de otros procesos más complejos como el de agrupamiento.Las distancias rígidas, como Manhattan, Euclídea, Minkowski o Chebyshev, no logran captardeformaciones entre dos series que para un humano resultan similares. Debido a ello, surgenotras distancias, denominadas elásticas, que buscan medir la distancia de una forma másflexible y natural.

DTW es una medida de distancia entre dos series temporales perteneciente al conjuntode las distancias elásticas [WMD+13]. Estas distancias, frente a las rígidas que miden ladistancia índice a índice, buscan un acoplamiento entre la forma de las series temporales.Así, la distancia no se mide entre el i-ésimo elemento de una serie y el i-ésimo de la otra,sino que puede existir una relación de posiciones de una a muchas.

La distancia DTW empezó a utilizarse en el reconocimiento de voz en los años 70. Seusaba para medir la similitud entre las plantillas que representaban las palabras y el sonidoque se reconocía [Vin68, SC78]. Su uso se extendió bastante en este ámbito porque es unamedida muy robusta ante los desplazamientos, ensanchamientos y estrechamientos de lasformas de las series, producidos debido a las distintas velocidades a las que se dice unamisma palabra. Unos años después, debido al aumento de la cantidad de datos disponibles,se propuso su uso para la detección de patrones en series temporales en general, no solo

7

en aquellas relacionadas con el reconocimiento de la voz [BC94]. Actualmente, DTW esprobablemente la medida de distancia elástica más común utilizada entre series temporales,tal como se indica en [PG12].

3.1.1 DTW clásico, especificación formal y algoritmoDTW puede hacer alusión tanto al algoritmo como a la distancia resultante de dicho algorit-

mo. En adelante, DTW hará referencia a cualquiera de estas definiciones, siempre quedandoclaro por el contexto a cuál se está refiriendo.

El algoritmo DTW es una técnica para buscar el alineamiento óptimo entre dos secuenciasde naturaleza temporal, basada en la distancia de Levenshtein. Informalmente, un alinea-miento entre dos series es una forma de acoplar una a la otra. Un alineamiento óptimo enton-ces es un acoplamiento entre dos series de forma que la distancia entre ellas es mínima.

Sean X e Y dos series temporales, de longitudes |X| e |Y | respectivamente, con X =

x1, x2, ..., xi, ..., x|X| e Y = y1, y2, ..., yj, ..., y|Y |. Estas secuencias están formadas por pun-tos equidistantes en el tiempo. Antes de definir qué es el alineamiento entre dos series, hayque definir la función de distancia local que mide la distancia entre cada par de elementos re-lacionados, uno perteneciente a cada serie [Mül07]. Esta función δ se define como sigue:

δ : E × E → R+ (3.1)

donde E es un elemento de una secuencia. El resultado de aplicar la función sobre doselementos, uno de cada serie, es un número real mayor o igual que cero.

Un alineamiento entre las series X e Y , es una secuencia W = w1, w2, ..., wk, ..., wL, conmax(|X|, |Y |) ≤ L ≤ |X| + |Y | y wk = (i, j), donde i es un índice de la serie X y j de laserie Y , que satisface las siguientes tres condiciones:

1. Condición límite: w1 = (1, 1) y wL = (|X|, |Y |).

2. Condición de monotonía: Si wk = (i, j) y wk+1 = (i′, j′), entonces i ≤ i′ y j ≤ j′.

3. Condición de continuidad: Si wk = (i, j) y wk+1 = (i′, j′), entonces i ≤ i′ ≤ i + 1 yj ≤ j′ ≤ j + 1.

Por tanto, el alineamiento esta formado por todos los índices de ambas series temporalesdebido a la condición 1 y 3, y los indices no podrán retroceder debido a la condición 2. Seobserva, además, que la condición 3 lleva implícita la 2, pero en aras de la claridad se indica,tal y como hace se hace en [Mül07].

El coste total de un alineamiento, es decir, la distancia total entre dos series, se ha definidode diferentes maneras en la literatura. Desde la suma de la distancia local δ entre cada par deelementos del alineamiento en [Mül07, Fu11], la media de la suma de las distancias localesen [Lia05] o la raíz de la suma en [RK04]. Se usará de ahora en adelante la primera de estas

8

opciones por simplicidad. Por tanto, el objetivo de DTW es buscar el alineamiento de costemínimo entre dos series temporales, es decir, buscar el alineamiento W tal que minimice lasuma de las distancias locales:

DTW (X, Y ) = mınK∑k=1

δ(xwki, ywkj

) (3.2)

donde wki es el índice de la serie X en la posición k del alineamiento y wkj el de la serieY . Para encontrar el coste del alineamiento óptimo, se puede resolver la siguiente recurren-cia:

D(Xi, Yj) = δ(xi, yj) +min

D(Xi−1, Yj−1),

D(Xi−1, Yj),

D(Xi, Yj−1)

(3.3)

donde Xi hace referencia a la subsequencia x1, x2, ..., xi de X e Yj a la subsecuenciay1, y2, ..., yi. La distancia total se obtiene aplicándo la función recursiva a las series comple-tas, es decir, resolviendo D(X|X|, Y|Y |).

Sin embargo, una implementación directa de esta definición recursiva da lugar a un algo-ritmo de complejidad temporal exponencial. Afortunadamente, debido al solapamiento demuchos de los subproblemas en los que resulta el cálculo de la recurrencia, se pueden guar-dar los resultados parciales para reutilizarlos. De esta forma, mediante una implementacióndinámica se puede resolver el problema con una complejidad O(|X| · |Y |). El algoritmodinámico que resuelve el problema se muestra a continuación:

algoritmo 1 DTW clásico1: function DTW(X , Y )2: M [1, 1]← δ(x1, y1)3: for i← 2 to |X| do4: M [i, 1]←M [i− 1, 1] + δ(xi, y1)

5: for j ← 2 to |Y | do6: M [1, j]←M [1, j − 1] + δ(x1, yj)

7: for i← 2 to |X| do8: for j ← 2 to |Y | do9: M [i, j]← δ(xi, yj) +min(M [i− 1, j],M [i, j − 1],M [i− 1, j − 1])

return M [|X|, |Y |]

Este algoritmo hace uso de una matriz de costes M , en la que el eje-x representa a la serieX y el eje-y a la serie Y. La posición M(i, j) será el coste del mejor alineamiento de las sub-sequencias Xi e Yj . De esta forma el coste total del mejor alineamiento lo encontraremos enla posición M(|X|, |Y |). Una vez tenemos los costes de cada casilla, es sencillo calcular el

9

alineamiento óptimo simplemente realizando un recorrido a través de los vecinos de menorcoste desde la posición M(1, 1) a M(|X|, |Y |). En la Fig. 3.1 observamos esta matriz decostes para un ejemplo y el camino que refleja el alineamiento de menor coste.

Figura 3.1: Alineamiento entre las series Xe Y

A continuación se exponen una serie de observaciones detalladas en [Mül07]. En primerlugar, se pueden dar varios alineamientos óptimos entre dos series temporales. Segundo,DTW es una distancia simétrica si δ lo es, es decir, la distancia entre X e Y es la misma queentre Y y X . Y por último, DTW no cumple la inecuación del triángulo. Por lo tanto DTWno es una métrica.

El DTW clásico presenta una deficiencia fundamental que impide su uso en muchas apli-caciones reales, y es su complejidad temporal. Incluso utilizando programación dinámicasigue siendo demasiado alta su complejidad para su uso con series temporales grandes. Esaquí donde se han llevado acabo en los último años grandes esfuerzos para optimizarlo, sinque esto conlleve una excesiva pérdida de precisión.

3.1.2 Variantes de DTWEl algoritmo DTW clásico ha sido objeto de muchos cambios y experimentos para dismi-

nuir su complejidad, y para eliminar algunos aspectos poco deseables algunas veces como,por ejemplo, el alineamiento de un solo punto de una serie temporal con demasiados de laotra. Las primeras modificaciones surgieron en el campo del reconocimiento de voz, aunquegran parte de los problemas que intentaban solventar se dan en muchos otros dominios. Loscambios más comunes son la introducción de una o varias condiciones globales y locales quelimiten el espacio de búsqueda del alineamiento. También se han propuesto variaciones delalgoritmo clásico, como FastDTW, que busca el alineamiento con una complejidad muy cer-

10

cana a la lineal, o DDTW, que realiza el alineamiento con la derivada de las series temporalesintentando así evitar alineamientos indeseados y poco intuitivos.

Condiciones globales

Además de las condiciones básicas expuestas anteriormente, al algoritmo DTW clásico sele suele añadir una condición más que limite el espacio respecto a la diagonal que se exploraen la elaboración del alineamiento. Así se fuerza a que no haya alineamientos entre un puntode una serie y muchos de otra. Las dos restricciones globales más conocidas y utilizadas sonla Banda de Sakoe-Chiba [SC78] y el Paralelogramo de Itakura [Ita75].

La Banda de Sakoe-Chiba se define añadiendo simplemente la siguiente condición a lasya indicadas antes:

∀wk = (i, j) ∈ W, |i− j| ≤ r (3.4)

Cuanto mayor sea el valor de r, menos restrictiva será la condición y por tanto, se permiti-rán alineamientos con una mayor diferencia temporal entre una serie y otra. Un ejemplo deesta banda podemos verlo en la Fig. 3.2(a). La parte oscura de la imagen corresponde a labanda, y es el espacio en el que se puede hacer el alineamiento.

El paralelogramo de Itakura restringe los alineamientos a explorar como se muestra enFig. 3.2(b). Para lograr limitar el espacio de búsqueda así se añaden las siguientes dos res-tricciones:

1 +ik − 1

E≤ jk ≤ 1 + E(ik − 1) (3.5)

M + E(ik −N) ≤ jk ≤M +ik −NE

(3.6)

Donde E es un coeficiente que hace más o menos restrictivo el paralelogramo y, N y Mson las longitudes de las series que se están comparando. Si E es grande, las pendientes delas rectas que forman el paralelogramo tienen una mayor inclinación y, por tanto, cubre unmayor área. En el caso de que E sea pequeño, el paralelogramo será más estrecho. Podemosinterpretar estas condiciones, como si la primera restringiera el espacio desde el punto (1, 1)

y la segunda lo limitara hacia (N,M) [MRR80].

Condiciones locales

A parte de las condiciones globales, se pueden formular otro tipo de condiciones querestringen la relación entre los puntos consecutivos del alineamiento. Hubo una amplia in-vestigación en este campo durante varias décadas siendo algunas de las más importantes

11

(a) Banda de Sakoe-Chiba (b) Paralelogramo de Itakura

Figura 3.2: Condiciones globales

[Ita75, SC78, MRR80].

La idea principal es restringir los pasos que se dan al alinear las series, de forma que nosolo se va a dar uno de los tres descritos en Eq. 3.3, sino que se pueden definir de otra manerapara acoplarse mejor al problema a resolver y evitar alineamientos indeseados. En Fig. 3.3 semuestran los cuatro patrones de pasos propuestos en [SC78]. Por ejemplo, la ecuación quedefiniría el patrón de Fig. 3.3(c) es min(δ(Xi−1, Yj−1, δ(Xi−1, Yj−2, δ(Xi−2, Yj−1)). Usandoesta ecuación, el alineamiento esta obligado a que, cada vez que se dé un paso en horizontalo en vertical, deba dar otro en diagonal. La intensidad de la pendiente de un patrón de pasopuede medirse mediante la ecuación:

P = n/m (3.7)

Donde n son los pasos que se dan en diagonal por cada m pasos en horizontal o vertical.Así, con P =∞ (m = 0) se restringe hacia la diagonal el espacio de búsqueda y con P = 0

no existe restricción alguna. De esta forma se restringe el número de pasos que se pueda daren una dirección sin dar otro en la diagonal.

Cabe destacar, tal como se indica en [KR05], que las condiciones locales pueden rein-terpretarse como condiciones globales. Por ejemplo, si en una matriz se marcan todas lascasillas por las que pueden pasar los alineamientos siguiendo el patrón de paso mostrado enFig. 3.3(b), Fig. 3.3(c) y Fig. 3.3(d), se obtiene una superficie marcada similar a la de un pa-ralelogramo de Itakura. Aun así, las condiciones globales y locales se pueden utilizar juntas,siguiendo, en caso de conflicto, lo que indique aquella condición mas restrictiva (aquella queobligue al alineamiento pasar más cerca de la diagonal).

En los experimentos llevados a cabo en [SC78], se formula una versión asimétrica de los

12

(a) (b) (c) (d)

Figura 3.3: Cuatro tipos de condiciones locales

patrones de pasos mostrados, en la que mediante pesos se ponderan de forma diferente unospasos que otros. También, en este trabajo, en los patrones simétricos, el peso de los movi-mientos en diagonal se multiplican por dos. La cuestión de utilizar pesos o no en los pasosdel alineamiento y el uso, en definitiva, de las condiciones locales, depende del dominio delproblema a resolver, y se basa en el conocimiento sobre el dominio o, en muchos casos, enprueba y error.

Las condiciones locales y globales funcionan bien cuando el alineamiento es cercano ala diagonal, es decir, las dos series temporales son parecidas. Si hay algún cambio bruscoentre ellas, es posible que el alineamiento no transcurra por la zona permitida y, por tanto, elalineamiento resultante diste mucho del óptimo. Además, dado que las condiciones locales yglobales reducen el espacio de búsqueda por un valor constante, la complejidad sigue siendoO(N2). Así, en definitiva, el uso real de DTW utilizando tan solo condiciones de este tipopara reducir el espacio de búsqueda solo puede ser utilizado en problemas en los que se sepade antemano que las series temporales van a ser muy parecidas entre ellas.

Reducción de dimensionalidad

Esta técnica consiste en aplicar el algoritmo DTW sobre las series temporales con su di-mensionalidad reducida y proyectando el alineamiento resultante en la series completas. Re-duciendo así el tamaño de las series sobre las que se aplica el algoritmo, se hace más mane-jable el tamaño de la matriz sobre la que se busca el alineamiento y, por tanto, se reduce lacomplejidad. Un ejemplo de aplicación de esta técnica se puede ver en la Fig. 3.4.

Obviamente, el alineamiento resultante no es el óptimo en la mayoría de los casos, ycuanto más se reduzca la dimensión de la series, será menos preciso. Además, incluso aunqueel alineamiento óptimo pase por las celdas de la matriz de dimensión reducida, a la hora deproyectarlo en la matriz real, se pierde precisión porque se ignoran las modificaciones localesque se podrían hacer en el alineamiento cuando se aumenta granularidad.

13

(a) 1/1 (b) 1/5 (c) 1/1

Figura 3.4: Reducción de la dimensión previa a la aplicación de DTW.

FastDTW

FastDTW es un algoritmo propuesto en [SC07] con complejidad O(N), que utiliza lasideas de las condiciones globales y locales junto con las reducción de la dimensionalidad paraobtener una buena estimación del alineamiento que sería calculado por el algoritmo clásicoDTW clásico. Este algoritmo utiliza un enfoque multinivel con tres operaciones básicas:

1. Reducción: Disminuye la dimensionalidad de las series temporales.

2. Proyección: Busca el alineamiento en las series temporales reducidas y lo utiliza co-mo primera suposición de alineamiento en las series con un nivel de dimensionalidadmayor.

3. Refinamiento: Refina el alineamiento proyectado.

La reducción disminuye el tamaño de las series haciendo la media entre pares de puntosadyacentes. Así, las series resultantes después de esta operación son la mitad de las origina-les. La reducción se aplica múltiples veces, obteniendo varias resoluciones diferentes de lasseries. La proyección toma un alineamiento en una resolución baja de las series y calcula porqué celdas pasará en las series de una resolución mayor, concretamente en la que las seriestienen el doble de tamaño. Como la resolución de las series aumenta en un factor de dos, unpunto del alineamiento de las series reducidas estará relacionado con al menos cuatro en lasoriginales. Este alineamiento proyectado se usa como heurística para buscar el alineamientoen las series de mayor resolución. Esta búsqueda corresponde a la operación de refinamien-to, en la que se busca el alineamiento óptimo en el vecindario del alineamiento proyectado,donde el tamaño de este vecindario se controla mediante un parámetro llamado radio. Unejemplo de la aplicación del algoritmo se muestra en Fig. 3.5.

El algoritmo comienza reduciendo repetidamente las series temporales hasta alcanzar unlímite inferior que indica que no se puede disminuir más la dimensiónde las series. Cuandose obtienen las series de menor dimensión permitida, se calcula el alineamiento óptimo enellas utilizando DTW (se utiliza el algoritmo DTW clásico porque las series son de un tamañomuy pequeño), y se proyecta sobre las de un nivel superior. Una vez proyectado, se refina

14

(a) 1/8 (b) 1/4 (c) 1/2 (d) 1/1

Figura 3.5: FastDTW con radio = 1.

el alineamiento, pero no usando el algoritmo DTW clásico, sino utilizando una variante quetan solo permita buscar alineamientos alrededor de las casillas del proyectado. El númerode casillas que podrá desviarse el alineamiento respecto al ya proyectado viene dado por elparámetro radio. Una vez se tiene el alineamiento, se vuelve a proyectar sobre el de un nivelsuperior y se repite el proceso hasta llegar a la resolución original de las series. El alinea-miento obtenido en esa resolución inicial es el resultado del algoritmo. Como es obvio, noestá asegurada su optimalidad, y será más preciso cuanto más alto sea el valor del parámetroradio. Sin embargo, cuanto más grande es el valor de radio, la complejidad temporal aumen-ta, llegando a ser la del algoritmo DTW clásico en el caso de que se fije su valor al del tamañode una de las series.

algoritmo 2 FastDTW1: function FASTDTW(X , Y , radio)2: minSize← radio+ 23: if |X| ≤ minSize or |Y | ≤ minSize then4: return DTW(X , Y )5: else6: Xreducida← reducirPorLaMitad(X)7: Yreducida← reducirPorLaMitad(Y)8: alinBajaResolucion← FastDTW (Xreducida, Yreducida, radio)9: ventana← expandirV entana(alinBajaResolucion, X, Y, radio)

10: return DTW (X, Y, ventana)

El pseudocódigo del algoritmo se muestra en algoritmo 2. Como se puede observar, FastDTWtiene una implementación recursiva muy sencilla. El caso base se alcanza cuando el tamañode las series tiene una resolución suficientemente baja. En el caso general, primero se re-ducen las series por la mitad y se calcula su alineamiento mediante una llamada recursiva.Una vez obtenido este alineamiento, se proyecta teniendo en cuenta el valor de radio, y serefina, utilizando DTW con el área limitada al vecindario del alineamiento proyectado máslas casillas adicionales debidas al valor de radio.

En [SC07] realizan un estudio teórico de la complejidad de FastDTW y otro experimentalde su precisión comparándolo con otras técnicas. En el primero de estos, se demuestra que

15

este algoritmo propuesto tiene una complejidad temporal de

O(n) = n(8r + 14) (3.8)

y espacial de

O(n) = n(4r + 7) (3.9)

Donde n es el tamaño de las series (se supone, por simplicidad en la demostración, que am-bas tienen el mismo tamaño). Por tanto, se puede hablar de complejidad lineal tanto espacialcomo temporal si el valor de r es bajo.

En el estudio experimental, se compara la precisión de FastDTW, utilizando varios radios,con DTW utilizando una reducción de dimensionalidad y DTW con la banda de Sakoe-Chiba.En estos experimentos se observa que FastDTW es más preciso que los otros algoritmos enla mayoría de los casos, incluso cuando radio toma el valor 0.

DDTW

El algoritmo Derivated Dynamic Time Warping (DDTW) propuesto en [KP01], proponeuna modificación del DTW clásico para evitar alineamientos poco intuitivos, no deseablesentre dos series temporales debidos a diferencias en el eje vertical de las series y no en eltemporal. Esto es porque DTW intenta explicar, en algunas ocasiones, las diferencias entrelas series mediante desplazamientos en el tiempo, aunque realmente no los haya.

DDTW utiliza la primera derivada de las series para calcular el alineamiento. De esta forma,no se tiene en cuenta la distancia entre los puntos, sino la distancia entre las derivadas.En [KP01] proponen utilizar la diferencia al cuadrado de las derivadas como medida dedistancia entre cada par de puntos para construir el alineamiento. Una vez se tiene, paracalcular la distancia entre las series, se utiliza la distancia entre los puntos relacionados porel alineamiento, no entre las derivadas en esos puntos. La complejidad por tanto, es la mismaque en DTW clásico, salvo por el incremento del valor de alguna constante debido al cálculode la primera derivada de las series.

3.1.3 ExperiementosEn la literatura encontramos múltiples experimentos comparando tanto la precisión como

la velocidad de DTW con otro tipo de distancias, elásticas o no, y también con sus mismasvariantes. En muchos trabajos se llegan a conclusiones diametralmente opuestas a las que sealcanzan en otros. Y es, por tanto, necesaria una revisión bibliográfica exhaustiva para saberqué es cierto sobre DTW y qué no lo es.

Saber que medida de distancia se calcula con mayor rapidez es muy fácil de medir. Sin

16

embargo, saber cuál es mejor no es un proceso tan inmediato. En la mayoría de los trabajosse utiliza un clasificador K-Nearest Neighbors (KNN) con K = 1 para estudiar que distanciarealiza mejores clasificacioens. Este algoritmo de clasificación se basa, en este caso, en tenerun conjunto de series temporales etiquetadas con la clase a la que pertenecen (conjunto deentrenamiento), y en base a este conjunto, clasificar nuevas series (conjunto de prueba) segúnla clase a la que pertenezca la secuencia más cercana del conjunto de entrenamiento. Segúnel número de clasificaciones acertadas, se podrá considerar mejor o peor la distancia paraesos datos.

Experimentos de DTW y sus variantes

En [RK04], se realiza un estudio intentado derribar diversos mitos sobre DTW. El primerode ellos dice que una de las principales ventajas de utilizar DTW es que permite medir ladistancia entre series que tienen distinta longitud. Por ejemplo, en [WW03], se dice queuna las principales ventajas de DTW es que es capaz de medir la distancia que hay entre dosseries aunque éstas no tengan la misma longitud. La realidad es que no tiene ningún perjuiciorealizar una interpolación lineal de las series que son de distinta longitud para que tenganla misma y medir su distancia, tal y como muestran los resultados de unos experimentosllevados a cabo en [RK04], utilizando un clasificador 1-NN y diversos conjuntos de datos.Por lo tanto, no debe ser un factor diferencial que las series no tengan la misma longitud decara a elegir DTW como la distancia a utilizar o no.

Otro mito estudiado en el mismo trabajo consiste en que utilizar restricciones para dismi-nuir el espacio de búsqueda en la obtención del alineamiento es un mal necesario heredadode la comunidad del reconocimiento de voz para lograr hacer de DTW un algoritmo eficien-te y aplicable a problemas reales. Sin embargo, los experimentos llevados cabo utilizandobandas de Sakoe-Chiba de distinta anchura muestran que se puede hacer más precisa la dis-tancia DTW cuando se restringe bastante la zona en la que buscar el alineamiento. De hecho,la mejor precisión se alcanza, dependiendo el conjunto de datos, cuando solo se busca elalineamiento en una zona del 3 al 10 % del total del espacio de búsqueda. Sin embargo, otrosexperimentos llevado a cabo con conjuntos de entrenamiento mucho más pequeños, mues-tran que el porcentaje del espacio de búsqueda necesario para alcanzar la mejor precisión esmayor. Por lo tanto podemos obtener dos conclusiones. La primera, que el hecho de restringirDTW no tiene por qué emperorar los resultados a la hora de resolver problemas reales, aun-que el resultado del alineamiento no sea el óptimo según la definición, debido principalmentea que se evitan alineamientos indeseables. La segunda, es que la necesidad de restringir máso menos el espacio de búsqueda depende del problema a resolver, y se deberá probar para élen concreto, sin poder generalizar para todos los problemas.

17

Experimentos de DTW y otras distancias

También se han llevado a cabo trabajos en los que se compara la precisión de la distanciaDTW con otro tipo de distancias, elásticas o no. En [WMD+13], se llevan a cabo múlti-ples experimentos con distintos conjuntos de datos y distancias utilizando un clasificador1-NN.

En este trabajo se muestra que el algoritmo DTW restringido mediante alguna de sus va-riantes no es peor que algunos métodos recientemente introducidos. Es más, DTW los superageneralmente. Además, es difícil encontrar una técnica que mejore a DTW en algún ámbitoen concreto. En [KE09] y [CNOT07], en los que se detallan algunos nuevos métodos paramedir la distancia entre series temporales, los resultados experimentales obtenidos no sontan buenos como DTW, tal y como se indica en [WMD+13].

3.1.4 Usos actualesEn la actualidad, DTW se utiliza en más campos que el del reconocimiento de voz. Por

ejemplo, en [RM03] se utiliza para el reconocimiento de texto escrito a mano a partir deimágenes. Como las palabras escritas tienen una componente temporal, se escribe antes loque está a la izquierda que lo que hay a la derecha (o de derecha a izquierda, según elidioma), se pueden transformar las imágenes de texto a series temporales. En este trabajo,tras aplicar algunas técnicas de preprocesamiento en las imágenes de los textos y convertirlosapropiadamente a series temporales, se utiliza DTW para decidir, por similitud, a que palabracorresponde una determinada imagen.

En [LXF+16], se utiliza DTW para clasificar actividades humanas en base a tecnologíaWireless Body Area Network (WBAN), que consiste en diferentes sensores, repartidos alre-dedor del cuerpo, que miden el movimiento y lo envían a una unidades de control, comoun teléfono móvil. Estos datos medidos por los sensores se usan como series temporales, yutilizando DTW se mide la similitud respecto a series que representan acciones ya conocidaspara determinar qué actividad se está realizando.

En definitiva, DTW garantiza mejores resultados que cualquier distancia rígida en la ma-yoría de las ocasiones cuando se mide la similitud entre secuencias de datos que presentanuna naturaleza temporal.

3.2 Algoritmos genéticosLos Algoritmo Genético (AG)s son un método adaptativo usado habitualmente para re-

solver problemas de búsqueda y de optimización. Durante varias generaciones, poblacionesde individuos evolucionan acorde con los principios de la selección natural expuestos porCharles Darwin en «The Origin of Species». Mimetizando este proceso, los AGs son capacesde hacer que soluciones a un problema evolucionen si éstas están codificadas correctamente.Los principios básicos de los algoritmos genéticos fueron estudiados rigurosamente y ex-

18

puestos por Holland [Hol92], además han sido objeto de estudio en otros muchos trabajoscomo [BBM93a], [BBM93b], [BBM93b] o [Pos00].

Los AGs simulan aquellos procesos que ocurren en las poblaciones de seres vivos que losllevan a evolucionar. En la naturaleza, los individuos de una población compiten entre ellospor conseguir recursos como comida o agua para sobrevivir. También, los miembros de unamisma especie suelen competir para atraer a una pareja con la que reproducirse. Aquellosindividuos que tienen un mayor éxito en atraer más individuos con los que reproducirse,tendrán una mayor descendencia. Sin embargo, aquellos individuos menos aptos, produciránpocos o incluso ningún descendiente. Esto conlleva que los genes de los individuos más aptostienden a ir aumentando su cantidad en los individuos de las siguientes generaciones. Lacombinación de las catacterísticas buenas correspondientes a diferentes antecesores puedendar lugar a una descendencia mucho muy apta, cuyas catacterísticas son mucho mejoresque las de sus padres. Así, las especies evolucionan para estar más y más adaptadas a suentorno.

Los AGs hacen uso directo de esta analogía con la naturaleza. Trabajan con una pobla-ción de individuos, donde cada uno de ellos representa una posible solución a un problema.A cada uno de estos individuos se les asigna una puntuación o fitness que indica lo buenaque es esa solución para resolver el problema. Los individuos con un fitness mayor tendránmás oportunidades de reproducirse o de pasar a formar parte de la siguiente generación.Esto produce que los individuos que formen la descendencia tendrán las mejores caracterís-ticas de los mejores individuos de la población. Los individuos menos aptos tendrán menosposibilidades de reproducirse, por lo tanto acabarán desapareciendo.

Una población de nuevos individuos se produce seleccionando los mejores individuos dela generación actual, reproduciéndolos entre sí para generar un nuevo conjunto de indivi-duos. Esta nueva población contiene una alta proporción de las características poseídas porlos mejores individuos de la generación previa. De esta forma, durante muchas generaciones,las mejores características se distribuyen entre la población, siendo mezcladas e intercam-biadas con otras buenas características. Favoreciendo la reproducción entre los individuosmás aptos, las áreas más prometedoras del espacio de búsqueda son exploradas. Si el AG

está bien diseñado, la población converge en un óptimo local del problema.

La principal ventaja del uso de AG es lsu robustez, puediendo lidiar con éxito en problemasde diversas áreas, incluyendo aquellos que resultan muy difíciles de resolver mediante otrosmétodos. Los AGs no garantizan encontrar un óptimo global del problema, pero si que soncapaces de encontrar soluciones muy buenas rápidamente.

A continuación se da una descripción del AG clásico. Después se explican algunas de lasvariantes del algoritmo clásico que han sido utilizadas en el presente proyecto.

19

3.2.1 Algoritmo genético clásico

La estructra estándar de AG descrita en [BBM93a] es la siguiente:

1. Se genera la población inical.2. Se calcula el fitness de cada individuo.3. Mientras no se hayan ejecutado todas las generaciones o no haya convergido:

3.1. Hasta que la nueva generación no tenga el tamaño de la población actual:3.1.1. Selecciona dos individuos de la población.3.1.2. Reproduce esos dos individuos produciendo dos nuevos.3.1.3. Calcula el fitness de los nuevos individuos.3.1.4. Inserta los nuevos individuos en la nueva generación.

Antes de poder ejecutar el algoritmo genético, es necesario codificar (o reprensetar) losindividuos del problema apropiadamente. También es necesario definir una función de eva-luación que calcule el fitness de los individuos, una función para seleccionar los individuosy otras para reproducir los individuos seleccionados. A continuación se detallan estos aspec-tos.

Codificación

Se asume que la solución potencial del problema se puede representar mediante un con-junto de parámetros. Esos parámetros se juntan para formar una cadena de valores, nombradahabitualmente como cromosoma. Este cromosoma representa los parametros del problemamediante una codificación binaria. Esto se debe a que en El Teorema del Esquema de Holland[Hol92], se explica rigurosamente por qué funcionan los algoritmos genéticos, en particular,para un alfabeto de codificación binario. Así, por ejemplo, en un problema en el que se quie-ra maximizar una función de tres variables f(x, y, z), se podría representar cada variablesmediante un número binario de 10 bits. Por tanto, el cromosoma contendría tres genes yconsistiría en un numero binario de 30 bits.

En términos genéticos, el conjunto de parámetros que es representado por un cromosomase denomina genotipo. El genotipo contiene información referida a la construcción de unorganismo, que se denomina fenotipo. Esta misma terminología es utilizada en los AGs. Así,en el problema anterior de maximizar f(x, y, z), la cadena binaria de 30 bits es el genotipoy los valores de x, y, z el fenotipo. También se utiliza el término alelo, en este caso parareferirse a un elemento de cada gen. En este problema cada gen tiene diez alelos, siendocada uno de ellos un uno o un cero.

20

Función de evaluación

Para cada problema se debe implementar una función de evaluación. Dado un cromosomaen particular, la función de evaluación devuelve un valor numérico denominado fitness, quedebe ser proporcional a la utilidad del individuo que ese cromosoma representa. Para muchosproblemas de optimización, la función de evaluación es obvia, pues es la función que sequiere optimizar. Sin embargo, en otros problemas es más complejo definir una función deevaluación apropiada.

Reproducción

Durante la fase de reproducción de un AG, los individuos son seleccionados de la pobla-ción y recombinados, produciendo una descendencia que constituirá la siguiente generación.Los padres son seleccionados aleatoriamente de la población utilizando un esquema quefavorezca a los individuos con un fitness mayor. Así, los mejores individuos serán seleccio-nados probablemente varias veces en una generación y los peores ninguna.

Una vez seleccionados dos individuos que serán los padres, sus cromosomas son recom-binados, normalmente utilizando los mecanismos de cruce y mutación. En su forma másbásica, estos operadores se definen de la siguiente manera:

Cruce: Toma dos individuos y corta la cadena que constituye el cromosoma de cadauno en una posición seleccionada aleatoriamente para producir dos segmentos de ca-beza y dos segmentos de cola. Los segmentos de cola son entonces intercambiadospara producir dos nuevos cromosomas Los dos nuevos individuos contienen alelos decada uno de los padres. Esta operación es conocida como cruce en un punto simple. Aeste operador se le asigna una probabilidad, de forma que no se aplica habitualmentea todos los individuos seleccionados para reproducirse. Así, en el caso de que no serealice esta operación, los dos individuos pasan directamente a la siguiente generaciónsin ninguna modificación.

Mutación: Este operador es aplicado individualmente a cada hijo después del cruce.Modifica aleatoriamente cada gen con una pequeña probabilidad.

Tradicionalmente se considera que el cruce es el operador mas importante para explorarrapidamente el espacio de búsqueda. La mutación permite realizar una pequeña búsquedaaleatoria que asegura que ningún punto del espacio de búsqueda tenga una probabilidadigual a cero de ser examinado.

3.2.2 Otros algortimos genéticosEl AG clásico, aunque útil para la resolución de muchos problemas, presenta demasiadas

restricciones que dificultan su uso. Sin duda, la restricción más importante es la de represen-tar los individuos mediante una cadena binaria. También el algoritmo mostrado anteriormen-te puede modificarse para aplicar las operaciones de cruce y mutación en un orden diferente,

21

e incluso definir estas operaciones de otra forma, adaptándolas más al problema que se quiereresolver. Algunas de estas posibilidades se exploran a continación.

Representaciones no binarias

Un cromosoma es una secuencia de símbolos binarios en la definición clásica de AG. Sinembargo, en algunos trabajos como [GH88] se estudia el uso de alfabetos de una mayorcardinalidad. Goldberg desarrolló la teoría de los alfabetos virtuales [Gol91] en la que mues-tra por qué las representaciones no binarias funcionan bien. Otros estudios experimentales[JM91] [MJ91] en los que se usan alfabetos de alta cardinalidad han utiliado cromosomasdonde cada símbolo representa un entero o un número decimal. Este tipo de representacionesfacilita el uso de los AGs en la mayoría de los problemas porque los parámetros que se quie-ren optimizar tienen forma numérica, y la codificación más natural de cualquier problema esno tener que realizar ninguna. En [JM91] se realizan unos experimentos que muestran quelas representaciones mediante números decimales logran soluciones mejores, de forma másconsistente y rápida.

Debido a estas nuevas codificaciones también surgen otro tipo de operadores de mutacióny cruce que abordan de una forma más natural los problemas en los que los individuos estanformados por números decimales o enteros.

Operadores

Los operadores de cruce, mutación y selección pueden definirse de forma genérica pararesolver cualquier problema que presente una codificación en concreto. También se puedeoptar por una definición especializada en el problema a resolver. A continuación de detallanalgunos operadores de cruce, mutación y selección genéricos. Después se explica por qué esinteresante definir operadores específicos.

Operadores de cruce: Cuando las representaciones de los individuos no se realizan me-diante una codificación binaria solamente, se abre un abánico de posibilidades de combinardos individuos. Algunas de éstas posibilidades son las siguientes:

Cruce en dos puntos: Es similar al cruce en un punto, pero en este caso se establecendos puntos de corte de forma aleatoria dando lugar a tres segmentos. El segmentoestablecido entre los dos puntos de corte es entonces intercambiado dando lugar a dosnuevos individuos.

Cruce uniforme: Consiste en intercambiar aleatoriamente genes de los genotipos de losindividuos. Dado un umbral p que define la probabilidad de aplicar el operador sobrecada gen, se decide si intercambiar ese gen o no.

Medias: Para representaciones numéricas, se puede obtener un hijo de dos individuospadre haciendo la media aritmética o geométrica entre cada pareja de genes de los

22

padres.

Extensión: Se toma la diferencia entre los valores de cada pareja de genes de los padresy se suma esa diferencia al mayor, o se resta al menor.

Existe muchos otros operadores de cruce genéricos, por ejemplo en [GL85], Goldbergdescribe varias operaciones de cruce, entre ellos Partially Matched Crossover (PMX) parautilizarlo en problemas donde el orden de las partes de un individuo sean relevantes para elcálculo del fitness.

Operadores de mutación: Al igual que ocurre con el cruce, existen muchos tipos deoperadores de mutación. Algunos de ellos son:

Sustitución aleatoria: Reemplazar un valor por otro aleatoriamente.

Deslizamiento: Sumar o restar un valor aleatorio pequeño.

Gaussiana: Dada una distribución gaussiana de media µ y desviación típica σ, se mo-difica cada valor de la siguiente forma:

ind[i] := ind[i] +N(µ, σ) (3.10)

Operadores de selección: Los operadores de selección son definidos siempre de formagenérica, dado que su proposito difiere poco de un problema a otro. Su objetivo es facilitarde alguna forma la selección de aquellos individuos más aptos para pasar a formar parte dela siguiente generación. Algunas posibles definiciones de este operador son:

Mejores: Selecciona los k mejores individuos de la población.

Torneo: Selecciona k individuos utilizando k rondas de torneo. Una ronda de torneo esuna selección aleatoria de n indivudos. De cada una se selecciona el mejor. Notese queun valor demasiado pequeño de n puede provocar una selección demasiado aleatoriaen la que los mejores individuos se quedan sin seleccionar y no pasan a la siguientegeneración. Un valor demasiado grande de n, por otro lado, provoca que en la selecciónsea muy poco diversa.

Ruleta: Selecciona k individuos usando k giros de ruleta. A cada individuo se le asignauna probabilidad proporcional a su fitness. Un giro de ruleta consiste en la generaciónde un número aleatorio p entre cero y el valor de la suma de todas las probabilidadesasignadas. El individuo seleccionado en un giro es aquel en cuyo intervalo se encuentrael número aleatorio generado, quedando el intervalo de un individuo definido comolos números situados entre la suma de las probabilidades asignadas a los individuosanteriores a él y la suma de esas probabilidades con la probabilidad de ese individuo.En Fig. 3.6 se muestra gráficamente como las probabilidaeds asignadas influyen en laselección de los individuos.

23

Figura 3.6: Operador de selección de Ruleta

Operados definidos por el dominio del problema

Aunque la mayoría de las investigaciones en AGs han utilizado los operadores de crucey mutación tradicionales, algunas han abogado por diseñar operadores nuevos para cadaproblema, atendiendo al dominio de conocimiento específico de cada uno. Dado que los AGsson diseñados para resolver problemas reales, la incorporación de conocmiento propio delproblema tiene sentido si con él se logran mejores resultados.

En [SVG87] se argumenta que el conocimiento específico del problema puede ser intro-ducido en el operador de cruce. Este conocimiento puede utilizarse para prevenir que segeneren cromosomas que sean obviamente malos o que violen las restricciones del problemao también puede ser utilizado para generar una población inicial y evitar que esta no seacompletamente aleatoria. En [GH88], Goldberg describe técnicas para añadir conocimientodel dominio del problema a operaciones como el cruce y la mutación.

Estrategia cooperativa

Los AGs presentan una estructura suceptible de ser paralelizada de forma natural, mante-niendo distintas poblaciones evolucionando en paralelo que interaccionan entre sí de algunamanera. En [PDJ00] se realiza un amplio estudio sobre como modularizar los algorimos evo-lutivos en general y como deben interaccionar las subpoblaciones (o especies) entre sí paraque los resultados sean buenos. En ese trabajo se introduce una arquitectura general paradefinir las interacciones entre las especies a lo largo del proceso evolutivo.

El modelo básico de evolución cooperativa se muestra en Fig. 3.7. Aunque esta ilustra-ción en particular muestra tres especies, el número total de especies que pueden formar elecosistema puede ser distinto. Cada especie evoluciona en su propia población y se adapta al

24

entorno a lo largo de varias generaciones. Aunque la figura muestra un esquema secuencialde evaluación, donde la población de cada especie se evalúa por turnos, las especies puedentambién ser evaluadas en paralelo. De cada especie se define uno o varios representantes queson intercambiados con el resto de poblaciones. La elección del representante puede ser tansencilla como seleccionar el mejor individuo de la especie.

Figura 3.7: Modelo cooperativo de tres especies [PDJ00]

Al utilizar una estrategia cooperativa, se debe definir el número de especies que consti-tuyen el ecosistema de evolución y cada cuanto tiempo se intercambian los representantes.El número de especies apropiado, tal y como se muestra en [PDJ00], suele ser igual al nú-mero de patrones o al número de objetivos que se tienen que cumplir. En muchos casos, esdifícil o imposible conocer este número y se opta por un esquema en el que las especies quedejan de constribuir a la evolución son eliminadas, evitando así la realización innecesariade cálculos. El tiempo entre intercambios de representanetes es más fácil de definir. Si se

25

realiza un intercambio cada muy pocas generaciones, los resultados obtenidos aplicando laestrategia cooperativa son similares a no utilizarla, debido a que no ha dado tiempo a que lassubpoblaciones se especialicen. El tiempo necesario para que una subpoblación se adapte losuficiente y resulte interesante realizar el intercambio de representantes depende de cada pro-blema. Por ejemplo, en los algoritmos implementados en el presente TFG se ha establecidoel intercambio cada veinte generaciones.

3.3 Algoritmos de aprendizaje: K-Means, KNN y NC3.3.1 K-Means

El algoritmo K-Means es un método de agrupamiento muy popular en el análisis de datos.El objetivo de este algoritmo es el de particionar un conjunto de n observaciones en k grupos,de forma que cada observación pertenezca al grupo cuya media está situada más cerca. Lamedia de cada grupo se denomina centroide o prototipo del grupo. El algoritmo estándar fuepropuesto por Stuart Lloyd en 1957 [Llo82].

Sea X = x1, x2, ..., xn un conjunto de elementos a particionar, donde cada elemento xi =

(xi1, xi2, ..., xim) es un vector m-dimensional. Cada grupo está definido por un centroide quese calcula de la siguiente forma:

cj =

∑i∈Cj

xi

nj(3.11)

donde Cj es el conjunto de elementos que pertenece al grupo j y nj el número de elemen-tos que hay en ese grupo. La suma de los errores cuadráticos dentro de un grupo es:

SSE =K∑j=1

∑i∈Cj

||xi − cj|| (3.12)

El índice Sum of Squared Errors (SSE) define la función objetivo que se pretende minimi-zar. El algoritmo K-Means puede ser considerado como un proceso heurístico para resolverel problema de minimizar el índice SSE. El algoritmo es el siguiente:

1. Se eligen aleatoriamente K elementos c1, ..., cK como los centroides iniciales de los gru-pos.2. Se calcula la distancia entre cada elemento y el centroide de cada grupo. El elemento seasigna al grupo cuyo distancia a él es la mínima.3. Se calculan los nuevos centroides de cada grupo mediante Eq. 3.11.4. Si los centroides cambian, se vuelve al paso 1. En caso contrario el algoritmo ha conver-gido.

26

Este algoritmo presenta una serie de ventajas e inconvenientes. Las ventajas son las si-guientes:

Es eficiente, con una complejidad O(t · n · K), donde t es el número de iteraciones.Siendo normalmente K y t son mucho menores que n.

Es fácil de implementar.

Algunos de sus inconvenientes son:

Hay que especificar el valor de K. Seguramente sea el mayor inconveniente de estealgoritmo.

La inicialización del los centroides importa. Por esta razón es aconsejable ejecutar elalgoritmo en varias ocasiones con inicializaciones distintas.

Pueden aparecer grupos vacíos.

No funciona bien con grupos que presenten formas diferentes o tengan distintos tama-ños.

3.3.2 KNN: K-Nearest NeighborsK-Nearest Neighbors (KNN), es un algoritmo utilizado en tareas de clasificación y regre-

sión. En esta sección solo se explicará su uso como clasificador debido a que una de susvariantes será utilizada para ese cometido en el proyecto.

Este algoritmo no mantiene un modelo interno como otros algoritmos de clasificación,sino que almacena los datos de entrenamiento y cuando se desea clasificar algun nuevo ele-mento, se utilizan esos datos guardados para decidir a que clase asignarlo. Para clasificarun elemento, se observan a que clase pertenecen aquellos más cercanos a él del conjunto deentrenamiento y aquella clase que aparezca con una mayor frecuencia será la que se asigna-rá al elemento. Así, los nuevos elementos son clasificados basandose en la similitud con elconjunto de entrenamiento, observado los K vecinos más cercanos.

El algoritmo KNN necesita los siguientes elementos:

El conjunto de entrenamiento que será almacenado.

Una medida de distancia con la que calcular la similitud entre los elementos.

El valor de K, el número de vecinos en los que se basará la clasificación.

Los pasos que sigue el algoritmo KNN son muy sencillos:

1. Se calcula la distancia con los elementos del conjunto de entrenamiento.2. Se identifica los K elementos más cercanos.3. Se asigna la clase más frecuente entre sus vecinos.

27

Es necesario especificar el valor de K antes de ejecutar el algoritmo. Si se decide utilizaruna K demasiado pequeña, el método será muy sensible al ruido. En caso de utilizar unvalor de K demasiado grande, el vecindario incluirá seguramente elementos de otras clases,empeorando los resultados de la clasificación.

Las ventajas de este algoritmo son:

Puede ser aplicado a datos que presenten cualquier distribución. Por ejemplo, no existela necesidad de que sean linearmente separables.

Su implementación es sencilla.

Las clasificaciones suelen ser buenas si el conjunto de entrenamiento es lo sufientegrande.

Y sus desventajas:

La necesidad de determinar el valor de K.

No necesita entrenamiento, sin embargo todo el cálculo se realiza durante la etapade clasificación. En sistemas reales se puede permitir una etapa de entrenamiento delmodelo larga, pero no de clasificación, que normalmente se desea rápida.

Es necesario una gran capacidad de almacenamiento si el conjunto de entrenamientoes grande.

3.3.3 NC: Nearest Centroid

El método Nearest Centroid (NC), propuesto en [THNC02], consiste en una variante delalgoritmo KNN. Este algoritmo, en lugar de observar el vecindario de un nuevo elemento paradecidir a que clase asignarlo, se mira cuál es la clase cuyo centroide es el más cercano.

Las ventajas principales de este algoritmo son:

Los cálculos en la etapa de clasificación se ven reducidos, aumentando los realizadosen la etapa de entrenamiento en el cálculo de los centroides. Esto se debe a que elnúmero de centroides es, normalmente, mucho menor que el número de elementos delconjunto de entrenamiento.

La complejidad computacional total del método es menor.

No es necesario determinar un valor de K.

La principal desventaja surge cuando las clases no son lo sufcientemente homogéneas, estoes, a una misma clase pertencen elementos muy diferentes. Con este tipo de distribucionesserá más robusta una clasificación utilizando KNN.

28

3.4 Métodos actuales: DBA y COMASALos dos algoritmos más destacados en la literatura para la búsqueda del centroide de un

conjunto de series temporales utilizando DTW como distancia son DTW Barycenter Avera-ging (DBA) y COmpact Multiple Alignment for Sequence Averaging (COMASA), estandoambos relacionados. Estos algoritmos son introducidos en [PG12] y [PKG11] respectiva-mente.

3.4.1 DBAEste algoritmo consiste en ir mejorando iterativamente una hipotética secuencia media

C del conjunto de series π = {S1, ..., SN}, establecida inicialmente de forma aleatoria. Lamajora de la hipotética secuencia media establecida en un principio corresponde al problemade minimización indicado en Eq. 1.2.

Dada la naturaleza del alineamiento entre dos series proporcionado por DTW, se puededescomponer intuitivamente la suma de las distancias entre cada serie de π y la secuenciaC en la suma entre cada elemento de C con sus elementos relacionados de cada secuenciade π. Así, se puede establecer una contribución de cada elemento de C al resultado final dela suma de distancias entre C y cada serie de π. Nótese que un solo elemento de una de lasseries π puede estar relacionado, y por tanto contribuir, a la suma de distancias total, con másde un elemento de C.

La idea fundamental de éste metodo consiste en lograr obtener el baricentro de cada cadaelemento de C y los elementos relacionados de cada serie de π, de forma que se minimizacada una de las sumas parciales que constituyen el problema de optmización. En otras pala-bras, el objetivo de DBA es obtener una secuencia cuyos elementos sean los baricentros delos elementos relacionados de las secuencias de π con cada elemento de C.

DBA consiste en un algoritmo iterativo. Se parte de una secuencia media C establecidade forma aleatoria antes de realizar la primera iteración. En cada iteración, DBA realiza dospasos:

1. Aplicar el algoritmo DTW entre cada secuencia de π y C, con el objetivo de buscarasociaciones entre los elementos de C y las series de π.

2. Actualizar cada elemento de la secuencia media como el baricentro de los elementosasociados durante el primer paso.

Sea Ci la secuencia media C en la iteración i. Sea assoc una función que relaciona cadaelemento de la secuencia media con una o más coordenadas de las secuencias de π. Estafunción se computa durante el cálculo de DTW entre C y cada secuencia de π. El i− esimoelemento de la secuencia media en la iteración j se define como:

Cji = baricentro(assoc(Cji)) (3.13)

29

donde:

baricentro({X1, ..., Xα}) =X1 + ...+Xα

α(3.14)

Cabe destacar que el orden en el que se calcula el algoritmo DTW entre C y las secuenciasde π no afecta al resultado final. De esta forma, repitiendo los pasos 1 y 2, la secuencia mediacambiará hasta que se alcance la convergencia.

La complejidad de este algoritmo es:

O(DBA) = O(k(n ·m2 + n ·m)) = O(k · n ·m2) (3.15)

donde k es el número de iteraciones que se computan. Esta complejidad es muy elevada,de forma que este algoritmo solo es útil si se el conjunto de series del que se quiere calcularla secuencia media no es grande.

3.4.2 COMASA

Este método consiste en un algoritmo genético que utiliza, para representar el genotipode sus individuos, el denominado alineamiento múltiple compacto, que está basado en laidea de alineamiento múltiple. El alineamiento múltiple consiste en una generalización delalineamiento proporcionado por DTW, mediante el que se puede calcular el alineamientoentre N secuencias. De esta forma, por ejemplo, en lugar de de calcular DTW comparandotres valores en una matriz, tres secuencias pueden ser alineadas comparando siete valoresen una matriz tridimensional (cubo). De la misma manera, DTW puede calcularse en unamatriz n-dimensional para obtener el alineamiento entre n secuencias. Sin embargo, calcularel alineamiento múltiple de n secuencias de longitud m tiene una complejidad temporal yespacial de O(mn), lo cual lo hace inviable para más de unas pocas secuencias.

Mediante está generalización de DTW, el alineamiento múltiple de un conjunto π =

{S1, ...Sn} de secuencias esW = w1, ..., wk, ..., wL, donde wk viene determinado por n índi-ces, cada uno relativo a una serie del conjunto. De este alineamiento se obtiene la secuenciamedia de la siguiente forma:

C = λ(S1(w1(1)), ..., Sn(w1(n))), ..., λ(S1(wL(1), ..., Sn(wL(n))) (3.16)

donde λ es una función que calcula la media aritmética de sus argumentos. Sj(wi(j)) de-nota al elemento de la serie j que se encuentra en posición la i del alineamiento. Se recuerdaal lector, que en una posición del alineamiento dado por DTW se encuentra una relación entredos elementos, uno relativo a cada una de las series sobre las que se aplica. En este caso, alser una generalización de DTW a n series, una posición del alinemiento múltiple consiste en

30

una relación entre n elementos donde cada uno de ellos pertenece a una de las n series.

Mediante la definición anterior, se muestra cómo haciendo uso del alineamiento múltiple,existe la posibilidad de obtener la secuencia media de un conjunto haciendo la media deaquellos elementos que están relacionados. Sin embargo, resulta imposible abordar este pro-blema calculando el alineamiento óptimo entre un conjunto de series. Así, COMASA buscauna manera de resolver este problema combinando los algoritmos genéticos con la idea dealineamiento múltiple. Para ello, se estudia la forma de representar los individuos como partede un alineamiento múltiple.

El alineamiento múltiple compacto consiste en una representación de la secuencia mediaC mediante el alineamiento entre sus índices y los indices de las series del conjunto π. Enotras palabras, la forma de representar un individuo será mediante los alineamientos entrecada serie del conjunto π y la secuencia media C que se pretende hallar.

Esta representación necesita determinar a priori la longitud de la serie media. Notese quesegún Eq. 3.16, la longitud de la serie media es la longitud del alineamiento múltiple. Y dadalas condición límite que debe cumplir el alineamiento, explicada anteriormente sobre DTW,extendida a alineamientos múltiples, se tiene que w1 = (1, ..., 1) y wL = (m, ...,m). Comoconsecuencia directa, se puede acotar inferior y superiormente la longitud de un alineamientomúltiple de la siguiente forma:

d∞(w1, wL) ≤ L− 1 ≤ d1(w1, wL) (3.17)

N

maxn=1|wL(n)− w1(n)| ≤ L− 1 ≤

N∑n=1

|wL(n)− w1(n)| (3.18)

N

maxn=1|T − 1| ≤ L− 1 ≤

N∑n=1

(m− 1) (3.19)

m− 1 ≤ L− 1 ≤ N · (m− 1) (3.20)

m ≤ L ≤ N · (m− 1) + 1 (3.21)

donde d1 y d∞ denotan respectivamente a las distancias de Manhattan y Chebyshev.

De esta forma tenemos las cotas superior e inferior de la longitud del alineamiento múl-tiple. Cualquiera de esos valores podría ser elegido para definir el alineamiento múltiplecompacto. Tal y cómo se propone en [PKG11], la decisión de tomar como longitud del ali-neamiento múltiple, L, la longitud de las series de π es lo más apropiado, pues se quierecalcular la secuencia media de ese conjunto.

Así, una vez se establece la longitudL de la serie mediaC, se puede definir el alineamientomúltiple compacto, que consiste en una forma de representar un alineamiento múltiple de

31

forma compacta. Así, un alineamiento compacto consiste en una secuencia de m tuplas den elementos, donde cada uno de esos elementos es un conjunto de índices. Es decir, unalineamiento compacto M∗ se representa como:

M∗ = (t1, ..., tm) (3.22)

donde la tupla ti representa el alineamiento compacto entre la serie Si y la secuenciamedia C. El contenido de ti(j) es el conjunto que contiene los índices de la serie Si queestán relacionados con la posición j de C.

Figura 3.8: Ejemplo del alinemiento compacto C

Figura 3.9: Representación en forma de tupla del alineamiento compacto de Fig. 3.8

En Fig. 3.8 se muestra el alineamiento compacto entre una serie S del conjunto π y lasecuencia media. En Fig. 3.9 se observa la representación en una tupla de conjuntos delmismo alinemiento compacto. Cada alineamiento compacto constituye un gen del genotipopor el que se representa un individuo. Y el genotipo completo que define un individuo estáformado por el alineamiento múltiple compacto, es decir el alineamiento compacto de cadaserie Si con la secuencia media C.

Así, manteniendo una esta representación de los individuos, se utiliza la Ecuación 3.13 pa-ra calcular el fenotipo de los individuos, que consiste en una serie de longitud m, candidataa ser la secuencia media del conjunto π. Nótese que como no se conoce la secuencia media,los alineamientos compactos que constituyen el alineamiento múltiple compacto no son óp-timos, esto es, son relaciones entre elementos de una serie de π y la secuencia media que sebusca. Estos alineamiento compactos múltiples evolucionarán para asemejarse lo más posi-ble al alineamiento múltiple compacto óptimo que se obtendría mediante la generalizaciónde DTW a n series, tal y como se ha explicado anteriormente.

Mediante esta representación compacta del alineamiento, se definen los individuos de unalgoritmo genético y las operaciones de mutación y cruce. Este algoritmo, además, aplicaDBA a cada individuo para optimizarlo en cada generación del proceso evolutivo. Nótese que

32

DBA no se definió para alineamientos múltiples compactos, sin embargo, es sencillo adaptar-lo, ya que un alineamiento múltiple compacto es un alineamiento múltiple representado deuna forma especial.

A continuación se detallan los operadores esenciales de este algoritmo genético:

Generación: La generación de individuos de forma aleatoria no resulta trivial. Se de-ben generar para cada individuo N genes, que consisten en alineamientos compactos.Se parte de una sola secuencia de índices y se procede a dividirla iterativamente enconjuntos hasta que se obtiene un alineamiento compacto de longitud m. Para que segeneren apropiadamente los genes se deben respetar una serie de propiedades de losalineamientos compactos múltiples que se explican en [PKG11].

Cruce: Cada genotipo tiene N genes y cada hijo, por tanto, debe tener también N

genes. La forma en la que se cruzan dos individuos es intercambiando un gen entreellos, dando lugar a dos nuevos individuos.

Mutación: Consiste en unir dos conjuntos de un gen y partir otro conjunto en dos. Aligual que en el operador de mutación, se deben cumplir una serie de propiedades queno forman parte del alcance de esta explicación.

Evaluación: Consiste en el objetivo inicial de obtener una secuencia que minimicela distancia DTW al resto de secuencias del conjunto π. Por tanto el fitness de unindividuo es calculado como la suma de la distancia DTW del fenotipo del individuo acada secuencia de π.

A continuación se detalla la complejidad del algoritmo COMASA. Sea N el número desecuencias de π, T la longitud media de las secuencias de π, L la longitud de la secuenciamedia, P el tamaño de la población y G el número de generaciones. En el Cuadro 3.1 semuestra la complejidad temporal de cada algoritmo.

Operación Complejidad temporal

Generación O(P ·N · L)Evaluación O(P ·N · L · T )Mutación O(P ·N)

Cruce O(P ·N)

Cuadro 3.1: Complejidad de los operadores

La complejidad total del algoritmo es:

O(G · (P ·N · L+ P ·N · L · T + 2 · P ·N)) (3.23)

= O(G · P ·N · (L+ L · T + 1)) (3.24)

= O(G · P ·N · L · T ) (3.25)

33

La complejidad temporal resulta bastante grande si el conjunto de series es de gran ta-maño y si éstas tienen muchos elementos. Además, la complejidad espacial del algoritmoes muy elevada debido a que cada individuo está representado por el alineamiento múltiplecompacto de todas las series del conjunto π, lo que hace imposible su uso en la mayoría delos problemas reales.

3.5 Framework: DEAPDistributed Evolutionary Algorithms in Python (DEAP) es un framework de computación

evolutiva que facilita el prototipado de algoritmos mediante el uso de Python. Fue desarro-llado por el Laboratorio de Visión por Computador y Sistemas de la Universidad de Laval[FDG+12]. Su diferencia principal respecto al resto de herramientas y librerías para el di-seño de algoritmos evolutivos es que presenta los algoritmos de forma explícita, de formaque es fácil su manipulación y personalización para la resolución de cualquier problema. Eneste apartado se detallan las características principales de esta herramienta, centrandose enaquellas relacionadas con los algoritmos genéticos.

Individuos

La forma de representar los indiviuos en DEAP es flexible. Éstos pueden estar represen-tados mediante cualquier estructura de datos, de forma que es fácil acoplar cualquier repre-sentación de los individuos a cualquier algoritmo genético sin tener que modificar nada deéste.

Operadores

DEAP contiene implementaciones de diferentes operadores genéricos de cruce, mutación,evaluación y selección. Además, debido a la representación explícita de los algoritmos quepresenta, se facilita la integración de operadores personalizados.

La clase Toolbox constituye una parte esencial del framework. Es una clase en la que seregistran los operadores y sus parámetros para que luego sean integrados en el algoritmoevolutivo. De esta forma, la estructura del algoritmo genético puede permancer inalteradaaunque se modifiquen los operadores.

Algoritmos

DEAP ofrece tres algoritmos genéticos básicos: eaSimple, eaMuPlusLambda y eaMuCom-maLambda. Todos ellos toman los argumentos de la probabilidad de cruce, la probabilidadde mutación, el número de generaciones, la población inicial y el objeto de la clase Toolboxen el que se han registrado los operadores que van a ser utilizados en el proceso de evolución.A continuación se detallan estos tres algoritmos.

eaSimple: Este algoritmo, en primer lugar, selecciona un conjunto de individuos del

34

tamaño de la población mediante el operador de selección. A estos individuos selec-cionadas les aplica, con la probabilidad dada, la operación de cruce. En caso de quedos individuos sean cruzados, los individuos resultantes los sustituirán. Después seaplica el operador de mutación. Estos individuos generados constituirán la poblaciónde la siguiente generación. Por tanto, se observa que los individuos que pasan a la si-guiente generación pueden haberse generado a partir de una operación de cruce sólo,de mutación sólo, de cruce y mutación, o de ninguna.

eaMuPlusLambda: Este algoritmo recibe dos argumentos más que eaSimple: el núme-ro de individuos que se seleccionan, lambda, y el número de hijos que se generan encada generación, mu. En primer lugar, se aplican los operadores de cruce y mutaciónpara generar la descendencia. La forma de aplicarlos es seleccionar aleatoriamente dela población un individuo y sobre ese individuo aplicar los operadores de mutacióny de cruce. En caso de que se aplique el cruce, se selecciona otro individuo de for-ma aleatoria de la población, se cruzan y se selecciona uno al azar de los dos nuevosgenerados para que pase a la siguiente generación. De esta forma se genera una des-cendencia de tamaño mu. Después, se selecciona mediante el operador de selecciónlambda individuos de la población y de la descendencia. Estos individuos selecciona-dos constituirán la población de la siguiente generación.

(a) eaMuCommaLambda (b) eaMuPlusLambda

(c) eaSimple

Figura 3.10: Algoritmos DEAP

eaMuCommaLambda: Presenta una estructura similar a eaMuPlusLambda, con la di-ferencia de que en lugar de seleccionar mu individuos de la población y de la descen-dencia, solo lo hace de la descendencia. Por la tanto, es una condición necesaria quelambda sea mayor o igual que mu.

35

Capítulo 4

Metodología

E N este capítulo se explica la metodología de gestión de proyectos utilizada para el desa-rrollo del presente TFG. Se ha utilizado Scrum como metodología de proyectos gene-

ral, definiendo así el marco en el que se desarrolla el TFG. Para los aspectos relacionadoscon el desarrollo de software se ha seguido la metodología eXtreme Programming (XP). Eneste capítulo se explica, en primer lugar, algunos conceptos relacionados con las medologíaságiles. Despúes, se describe qué es Scrum y XP y como han sido utilizadas en el proyecto.

4.1 Metodologías ágilesLas metodologías ágiles son una serie de técnicas de gestión de proyectos que surgieron

principalmente en el ámbito del desarrollo del software, como contraposición a las pesadasmetodologías de gestión desarrolladas hasta entonces [PdSI12].

En febrero de 2001, tras una reunión delebrada en Utah, nace el término ágil aplicado aldesarrollo del software. En esta reunión participan 17 expertos de la industria del softwa-re, incluyendo algunos cradores o impulsores de metodologías de software. El objetivo eraesbozar los valores y principios que deberían permitir a los equipos desarrollar software rápi-damente y respondiendo a los posibles cambios que pueden surgir a los largo de un proyecto.Así, tras esta reunión, se escribió el Manifiesto Ágil, un documento cuyo contenido se divideen cuatro valores y doce principios, los cuáles sintetizan la idea de la filosofía del desarrolloágil de software.

4.1.1 Valores del Manifiesto ÁgilEl Manifiesto Ágil se caracteriza principalmente por sus cuatro valores. Cada un de estos

valores es concretado de diferente manera por las metodologías ágiles.

Valorar a los individuos y las interacciones del equipo de desarrollo sobre el procesoy las herramientas. Se tienen en cuenta las buenas prácticas de desarrollo y de gestiónde los participantes del proyecto. Esto facilita el trabajo en equipo y disminuye losimpedimentos para que se realice el trabajo.

Desarrollar software que funciona más que conseguir una documentación exhaustiva.No es necesario producir documentos a menos que sean necesarios de forma inmediata

37

para tomar una decisión importante. Así, los documentos deben ser cortos y centrarseen lo fundamental.

La colaboración con el cliente más que la negociación de un contrato. Es necesaria unainteracción constante entre el cliente y el equipo de desarrollo.

Responder a los cambios más que seguir estrictamente un plan. Se busca la adaptaciónmás que una planificación detallada y estricta. La flexibilidad no es total, pero existenmuchos puntos donde se pueden adaptar las actividades. Uno de los objetivos princi-pales de cualquier proyecto ágil es proveer valor al cliente. Y para ello es necesarioque el cliente obtenga de forma iterativa pequeñas funcionalidades. De esta manerase pueden producir cambios y mejoras que aumenten el valor retornado al cliente porparte del producto software resultante.

4.1.2 Principios del Manifiesto ÁgilDe los cuatro valores anteriores surgen los doce principios del Manifiesto. Mediante estos

principios se puede identificar lo que diferencia a un proceso ágil de un proceso tradicional.Los principios, explicados en el Manifiesto Ágil, son los siguientes:

La prioridad es satisfacer al cliente mediante entregas tempranas y continuas de soft-ware que le aporten valor.

Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga unaventaja competitiva.

Entregar frecuentemente software que funcione desde un par de semanas a un par demeses, con el menor intervalo posible entre entregas.

La gente del negocio y los desarrolladores debe trabajar juntos a lo largo del proyecto.

Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyoque necesitan y confiar en ellos para finalizar el trabajo.

El diálogo cara a cara es el método más eficiente y efectivo para comunicar informa-ción dentro de un equipo de desarrollo.

El software que funciona es la medida fundamental del progreso.

Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolla-dores y usuarios deberían ser capaces de mantener una paz constante.

La atención continua a la calidad técnica y al buen diseño mejora la agilidad.

La simplicidad es esencial.

Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados porsí mismos.

En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo,y según esto ajusta su comportamiento.

38

4.2 Scrum

Scrum es una metodología ágil que proporciona un marco de trabajo para la gestión deproyectos, siendo hoy en día la metodología ágil más popular. El conjunto de buenas prácti-cas de Scrum se aplica esencialmente a la gestión de proyectos. Scrum constituye un marcode trabajo que es necesario adaptar. Su objetivo es obtener resultados rápidos adaptándosea los cambios de las necesidades de los clientes. Las características principales de Scrumpueden resumirse en dos:

EL desarrollo del software mediante iteraciones incrementales.

Las reuniones a lo largo del proyecto.

A continuación se detallarán los diferentes elementos de Scrum.

4.2.1 Equipo Scrum

Uno de los aspectos más importantes en cualquier proyecto ágil es el establecimiento delequipo, definiendo claramente los roles y responsabilidades que tienen los integrantes delmismo. Cada equipo de Scrum tiene tres roles:

Scrum Master: es el responsable de asegurar que el equipo Scrum siga las prácticas deScrum. Sus principales funciones son:

• Ayudar a que el equipo y la organización adopten Scrum.

• Liderar el equipo Scrum, buscando la mejora en la productividad y calidad de losentregables.

• Ayudar a la autogestión del equipo.

• Gestionar e intentar resolver los impedimentos con los que el equipo se encuentrapara cumplir las tareas del proyecto.

Product Owner: Es la persona responsable de gestionar las necesidades que serán sa-tisfechas por el proyecto y asegurar el valor del trabajo que el equipo lleva a cabo. Suaportación al equipo se basa en:

• Recolectar las necesidades o historias de usuario.

• Gestionar y ordenar las necesidades.

• Aceptar el producto al finalizar cada iteración.

• Maximizar el retorno de inversión al proyecto.

Equipo de desarrollo: Está formado por los desarrolladores que convertirán las necesi-dades del Product Owner en un conjunto de nuevas funcionalidades, modificaciones oincrementos del producto final.

39

4.2.2 Product BacklogEl Product Backlog permite tener una única visión durante todo el proyecto. Consiste en

un listado de historias de usuario que se incorporarán al producto a partir de incrementossucesivos. Este listado está ordenado, y aunque no existe un criterio preestablecido paraordenar las historias de usuario, el más aceptado es utilizar el valor que aporta al negocio laimplementación de ls historia de usuario.

4.2.3 SprintEn Scrum a cada iteración se le denomina Sprint. Scrum recomienta iteraciones cortas,

por lo que cada Sprint durará entre 1 y 4 semanas. Como resultado se creará un producto po-tencialmente entregable, un prototipo operativo. Las características que van a implementarseen el Sprint provienen del Product Backlog. El equipo de desarrollo selecciona las historiasde usuario que se van a desarrollar en el Sprint conformando el Sprint Backlog. La relaciónentre el Product Backlog, el Sprint Backlog y el Sprint se musetran en Fig. 4.1.

Figura 4.1: Ejemplo de proceso Scrum

4.2.4 ReunionesLas reuniones son un pilar importante dentro de Scrum. Hay diversos tipos de reunio-

nes:

Reunión de planificación del Sprint: Se lleva a cabo al principio de cada Sprint, defi-niendo en ella qué se va a realizar. Esta reunión da lugar al Sprint Backlog. El ProductOwner presenta el conjunto de historias de usuario en el Product Backlog y el equipode desarrollo selecciona las historias de usuario sobre las que trabajará.

Reunión diaria: Es una reunión diaria de no más de 15 minutos en la que participa todoel equipo de desarrollo y el Scrum Master. En esta reunión cada miembro del equipopresenta lo qué hizo el día anterior, lo que hará y los impedimentos que ha encontrado.

Reunión de revisión del Sprint: Se realiza al final del Sprint. Participan el equipo dedesarrollo, el Scrum Master y el Product Owner. Durante la misma se indica qué ha

40

podido completarse y qué no, presentando el trabajo realizado al Product Owner. Porsu parte, el Product Owner verifica el incremento del producto.

Retrospectiva del Sprint: También se realiza al final del Sprint, aunque puede que noal final de todos. Sirve para que los integrantes del equipo Scrum y el Scrum Masterden sus impresiones sobre el Sprint que acaba de terminar. Se utiliza para la mejoradel proceso.

4.3 Extreme ProgrammingProgramación Extrema o eXtreme Programming (XP) es una metodología ágil de desarro-

llo de software adaptativa y centrada en las personas. Además, agrega buenas prácticas queabarcan más allá de la gestión de proyectos software.

4.3.1 Buenas prácticas en XPXP enumera un conjunto de diez buenas prácticas que son la base para un correcto funcio-

namiento de esta metodología. A continuación se enumera cada una de ellas.

Planning Game: Determinar rápidamente el alcance de la siguiente iteración. Para ellose utilizarán tanto las prioridades del negocio como las estimaciones técnicas. En estesentido, los desarrolladores tienen un mayor peso en los aspectos técnicos: las estima-ciones ágiles, riesgos técnicos, orden en las actividades, etc. Y los jefes de proyecto o,en general, los encargados del negocio tendrán una perspectiva más global. Aportaránsu experiencia en aspectos tales como el establecimiento del alcance o la priorizaciónde las entregas.

Entregas pequeñas: Los ciclos de contrucción y despliegue de nuevas funcionalidadesdeben ser rápidos. Es necesario poner en producción rápidamente una nueva versióndel sistema para planificar la siguiente iteración. Las divisiones no deben ser forza-das, una nueva entrega no puede estar conformada por una funcionalidad sin que éstecompleta.

Metáfora: Es una historia simple, conocida y entendida por todos, para guiar a los desa-rrolladores acerca de cómo funciona el sistema. Cada proyecto software estará guiadopor una metáfora. Así, el grupo de desarrolladores y el cliente deben compartir esametafora para que puedan dialogar. Una buena metáfora debe ser fácil de comprenderpor el cliente y contener suficiente información para guiar la arquitectura del proyecto.

Diseño simple: Construir el diseño lo más simple posible para dar respuesta a las nece-sidades y requisitos actuales del sistema. Las complejidades extras deberán ser elimi-nadas tan pronto como sean descubiertas. De acuerdo a [AB04], un diseño simple esaquél que permite la ejecución de todas las pruebas, no contiene lógica duplicada, ex-pone todas las intenciones importantes del desarrollador y contiene la menor cantidadde clases y métodos posibles.

41

En este sentido, XP permite utilizar lenguajes de modelado como Unified ModelingLanguage (UML) siempre que aporten un valor de utilidad al proyecto. Explorar di-seños mediante diagramas antes de realizar el desarrollo puede ser provechoso paramantener la dirección única del proyecto. En las premisas descritas en [Fow01], seresaltan tres aspectos a tener en cuenta:

• Los diagramas deben ser pequeños. La cantidad de elementos capaces de serretenidos y analizados por las personas es limitada. Si se quiere favorecer la co-municación es necesario mantener esta premisa de simplicidad.

• Deben estar centrados en los detalles importantes. El código contiene la informa-ción detallada, los diagramas sólo comtendrán información a alto nivel y recal-carán los aspectos más importantes.

• Los diagramas son simplificaciones, guías, no un diseño final completamentedetallado. Debido a ese nivel de abstracción de los modelos y diagramas, si serealizan cambios en el diseño durante la construcción, no debería ser necesariomodificar los diagramas.

Pruebas: Los desarrolladores deben escribir pruebas unitarias de sus desarrollos. Esimportante mantener un criterio de cobertura de pruebas y priorizar los métodos quedeben ser probados. No es necesario realizar pruebas de cada método, pero las pruebassobre métodos y clases claves en el desarrollo deben ser amplias.

Refactorización: Los desarrolladores se encargarán de reestructurar el sistema, sincambiar la funcionalidad. De esta manera eliminarán código duplicado, disminuiránel acoplamiento, aumentarán la cohesión y agregarán flexibilidad. Las refactorizacio-nes deben realizarse cuando existe la necesidad de simplificar el diseño para hacerlomás mantenible, la imposibilidad de realizar una prueba unitaria de manera sencilla ola necesidad de introducir código duplicado porque el diseño actual así lo obliga.

Programación por pares: Se desarrolla por pares. Existen dos roles en cada par de desa-rrolladores. Uno es el encargado de escribir el código fuente y las pruebas; mientrasque el otro revisa el código y las pruebas, aportando una visión crítica y constructiva.De esta manera, el segundo desarrollador inspeccionará el código desde otra perspec-tiva, propondrá nuevas pruebas unitarias y revisará la simplicidad del diseño.

Propiedad colectiva del código: El código es propiedad de todo el equipo. Cualquierdesarrollador puede modificar cualquier parte del código fuente en cualquier momento.Esto significa que todos los desarroladores tienen responsabilidad por todo el sistema,aunque no todos conozcan todas las partes con el mismo nivel de detalles.

Integración continua: La integración de las diferentes partes del sistema, así comola ejecución de las pruebas unitarias, deben ser realizadas al final de cada prueba dedesarrollo.

42

Semana de 40 horas: Una de las premisas más importantes para ayudar a la planifica-ción es que la semana tiene 40 horas útiles de trabajo. No terminar el trabajo planifi-cado en el tiempo asignado es un síntoma de serios problemas en el proyecto.

Clientes en la misma ubicación que el equipo: Incluir una persona del cliente en elequipo de desarrollo que esté disponible para resolver cuestiones. En este contexto,cliente es alguién que utilizará el sistema en prducción.

Programación estándar: Los desarrolladores escribirán código fuente de acuerdo conlos estándares y buenas prácticas de codificación que favorezcan la comunicación entrelos miembros del equipo. Así, esto no debe implicar una gran cantidad de documenta-ción sobre cómo escribir el código fuente.

4.4 Aplicación de la metodologíaEl uso de Scrum junto con XP en el desarrollo de proyectos software es una práctica habi-

tual, tal y como se describe en [Kni07]. Esto se debe a que Scrum se enfoca a las prácticasde organización y gestión del proyecto, mientras que XP se centra más en las prácticas deprogramación. Además, ambas metodologías definen prácticas muy similares, lo cuál hacesencilla su combinación en el desarrollo de un proyecto software. La decisión de utilizarXP además de Scrum y no solo está última, se debe a la necesidad de usar una metodologíaapropiada para el desarrollo de código complejo de implementar y crítico para el éxito delproyecto. Dado que en XP el desarrollo de pruebas unitarias y refactorizaciones de códigoresultan pilares fundamentales de la metodología, se observo apropiado combinarla juntocon una metología de proyectos más general como Scrum. Además, XP se enfoca en con-seguir diseños lo más simples posibles, lo cual resulta importante para cualquier proyectosoftware.

La combinación de estas dos metologías se ajusta bien a la naturaleza imprevisible delTFG, al tratarse éste de un proyecto de investigación. En este tipo de proyectos, los obje-tivos planteados al principio pueden verse afectados tras observar los resultados obtenidos,haciendose necesaria la adaptación de los requisitos a la nueva realidad. Así, la selección deuna metodología que pueda lidiar con cambios constantes en los requisitos es indispensablepara la consecución del éxito del proyecto.

A continuación se detalla la aplicación de la metología en el proyecto, definiendo los roles,el Product Backlog y cada Sprint Backlog.

4.4.1 Definición de rolesLos roles definidos en Scrum serán tomados por los pariticipantes del presente TFG. El

director asumirá el rol de Product Owner. El responsable de adoptar Scrum será el autordel proyecto, por lo que tomará el papel de Scrum Master. También debido a que es elautor del TFG quién realizará las tareas de implementación, será él quién asumierá el rol

43

de Development Team.

Una de las buenas prácticas definidas en XP es la programación por pares, sin embargo,dada la naturaleza del proyecto, resulta imposible realizarla.

4.4.2 Definición del Product BacklogEl Product Backlog consta de las historias de usuario que serán implementadas en las

sucesivas iteraciones. Tiene un carácter dinámico, es decir, las historias de usuario se puedenañadir durante el desarrollo del proyecto y no tienen por qué estar todas definidas desdeel principio. Sin embargo, en este apartado, se muestra el Product Backlog completo en elCuadro 4.1, con todas las historias de usuario que se han sido implementadas, sin hacerreferencias a cómo se fueron añadiendo las mismas.

Historias de usuario

Investigación del entorno DEAP

Búsqueda de datos de naturaleza temporal

Estudio e implementación de soluciones existentes

Implementación de DTW y FastDTW en lenguaje C

Experimentos con las soluciones de la literatura

Implementación de algoritmo genético genérico

Experimentos con algoritmo genético genérico

Implementación de operador de cruce

Implementación de operador de mutación

Implementación e integración de la estructura del algoritmo genético

Experimentos para parametrizar operadores y comparar con los algoritmos anteriores

Implementación de algoritmo genético cooperativo

Experimentos con algoritmo genético cooperativo

Implementación de algoritmo K-Means con DTW

Implementación de algorimo NC con DTW

Experimentos con algoritmo NC

Clasificaciones difusas con NC

Implementación del servidor REST

Extensión del servidor REST para dar soporte al cliente web

Implementación del cliente Web

Cuadro 4.1: Product Backlog

Las historias de usuario se muestran en el Anexo A.

44

4.4.3 Sprints

En la elaboración del proyecto se han llevado a cabo un total de siete sprints. Cada unade los cinco primeros tiene una duración comprendida entre dos y cuatro semanas, mientrasque la duración de los dos últimos se redujo a dos semanas cada uno. Esta disminución enla duración se debe a la necesidad de acelerar los plazos para lograr finalizar el proyecto enlos plazos establecidos. A su vez, a lo largo de todo el proyecto se realizarón reuniones cadados semanas durante los cinco sprints y semanalmente durante los dos últimos.

Sprint 1

En el primer sprint del proyecto se lleva la cabo la primera toma de contacto con el entornode desarrollo de algoritmos evolutivos DEAP. También se procede a realizar una búsquedade datos de naturaleza temporal con los que poder probar los algoritmos desarrollados. Porúltimo, se lleva a cabo el estudio de las diferentes técnicas desarrolladas hasta la fecha parala resolución del problema de la búsqueda de la secuencia media de un conjunto de seriestemporales utilizando DTW como distancia. Una vez estudiadas, se reproducen los dos prin-cipales algoritmos para contrastar sus resultados y tomarlos como punto de partida en eldesarrollo del proyecto.

En esta iteración, tras concluir los tres objetivos marcados y observar la ineficiente y erró-nea implementación en Python de la función DTW de los respositorios oficiales, y dado elcarácter crítico de dicha función en los algoritmos que se pretenden desarrollar, se decideproceder a implementarla de una forma más óptima en lenguaje C. En el Cuadro. 4.2 semuestra el Sprint Backlog de esta iteración.

Historias de usuario Estimación

Investigación del entorno DEAP 6 horas

Búsqueda de datos de naturaleza temporal 5 horas

Estudio e implementación de soluciones existentes 30 horas

Implementación de DTW y FastDTW en lenguaje C 5 horas

Experimentos con las soluciones de la literatura 3 horas

Cuadro 4.2: Iteración 1: Sprint Backlog

Sprint 2

En este segundo sprint se tiene como objetivo implementar un algoritmo genético senci-llo con operadores definidos de forma genérica. Una vez implementado, se someterá a unabateria de pruebas similar a la de la iteración anterior para poder comparar los resultados. ElSprint Backlog de esta iteración se muestra en el Cuadro 4.3.

45

Sprint 3

La tercera iteración está centrada en implementar un algoritmo genético más avanzado queel desarrollado en la iteración anterior, con unos operadores más específicos sobre el dominiodel problema. La elaboración de unos operadores de mutación y cruce son tareas clave enesta iteración. Como en las iteraciones anteriores, será sometido el algoritmo implementadoa una bateria de puebas, comparándolo con los dos algoritmos anteriores.

Así, debido a la importancia de la implementación de unos operadores adecuados, se de-cide dividir el desarrollo del algoritmo genético en varias historias de usuario, a diferenciade lo que ocurría en la iteración anterior. De esta forma se pretende tener un control mayorsobre el desarrollo de los distintios componentes del algoritmo. En Cuadro 4.4 se muestra elSprint Backlog relativo a esta iteración.

Sprint 4

En esta iteración se desarrolla un algoritmo genético que mantiene las ideas principales delimplementado en la iteración anterior, pero que presenta una estrategia de evolución coope-rativa entre varias especies. Así, en esta iteración hay dos historias de usuario, la relativa a laimplementación del algoritmo cooperativo y la de implementación de una bateria de pruebas.El Sprint Backlog de esta iteración se muestra en Cuadro 4.5.

Sprint 5

La quinta iteración se centra en la implementación de dos algoritmos, uno de aprendizajesupervisado y otro de aprendizaje no supervisado haciendo uso del algoritmo genético desa-rrollado en las iteraciones anteriores. El primero de ellos corresponde al algoritmo K-Meansque utiliza como medida de distancia DTW. El segundo, es una modificación del algoritmoKNN que, en lugar de medir la distancia con el conjunto de entrenamiento entero para clasi-ficar un nuevo elemento, la mide solo con los centroides de las clases. A esta variación se ladenomina NC. En Cuadro 4.6 se muestra el Sprint Backlog de este sprint.

Sprint 6

En la sexta, se desarrolla un servidor REST que permite acceder a los distintos algoritmosdesarrollados. Este servidor proporiciona todas las funcionalidades desarrolladas hasta aho-ra: obtención del centroide con un algoritmo genético simple y cooperativo, ejecución delK-Means utilizando ambos algoritmos genéticos en el cálculo del centroide y clasificaciónde un conjunto de series temporales utilizando NC, usando también ambos algoritmos gené-ticos. En esta sprint se añade también la posibilidade de realizar clasificaciones difusas conel algoritmo NC. En Cuadro 4.7 se muestra el Sprint Backlog de este sprint.

46


Implementación de algoritmo genético genérico 12 horas

Experimentos con algoritmo genético genérico 3 horas



Implementación de operador de cruce 15 horas

Implementación de operador de mutación 15 horas

Implementación e integración de la estructura del algoritmo genético 10 horas

Experimentos para parametrizar operadores y comparar con los algoritmosanteriores

5 horas



Implementación de algoritmo genético cooperativo 15 horas

Experimentos con algoritmo genético cooperativo 4 horas



Investigación del entorno DEAP 6 horas

Búsqueda de datos de naturaleza temporal 5 horas

Estudio e implementación de soluciones existentes 30 horas

Implementación de DTW y FastDTW en lenguaje C 5 horas

Experimentos con las soluciones de la literatura 3 horas



Clasificaciones difusas con NC 3 horas

Implementación del servidor REST 35 horas


47

Sprint 7

El séptimo sprint está centrado en la implementación de un cliente web con una interfazgráfica en la que se observa el proceso evolutivo de las series temporales con el algoritmogenético introducido en el tercer sprint. El servidor implementado en la iteración anterior da-rá soporte al cliente web. Así que será necesario añadir una nueva funcionalidad al servidor.En Cuadro 4.8 se muestra el Sprint Backlog de esta iteración.


Extensión del servidor REST para dar soporte al cliente web 12 horas

Implementación del cliente Web 40 horas


4.5 Herramientas SoftwareA continuación se detallan los medios software utilizados en el desarrollo del proyecto.

En primer lugar se describen las herramientas software utilizadas en el desarrollo. Después,se explica qué herramientas se han utilizado para elaborar la documentación. Por último, sedetallan los lenguajes de programación y frameworks utilizados a lo largo del proyecto.

4.5.1 Herramientas para el desarrolloSpyder: Es un entorno de desarrollo interactivo para Python. Provee varias herramien-tas interesantes para depurar el código. También facilita la realización de pruebas deforma interactiva mediante terminales de IPython. En el TFG se ha utilizado princi-palmente para la implementación de los operadores de los algoritmos genéticos, yaque debido a la complejidad del código, ha sido importante el uso de herramientas dedepuración.

Jupyter: Es una aplicación web de código abierto que permite crear y compartir docu-mentos con código Python ejecutable integrado en ellos. Facilita la implementación descripts de forma interactiva y la presentación de resultados mediante gráficos. Ha sidoutilizado para realizar transformaciones sobre los ficheros de series temporales y parapresentar resultados mediante gráficas en las reuniones de seguimiento del TFG.

Atom: Es un editor de texto cuya principal característica es la amplia personalizaciónque ofrece. Ha sido utilizado para el desarrollo de la mayoría del código desarrolladoen el TFG, desde la API REST al cliente web.

Google Chrome: Este navegador ha sido utilizado en tareas de depuración y pruebasdel cliente web implementado.

Git: Los sistemas de control de versiones resultan vitales en el desarrollo del softwarepara la gestión de la configuración. En este proyecto se ha utilizado Git debido a su

48

gran popularidad y eficiencia a la hora de gestionar flujos de trabajo.

Bitbucket: Es una plataforma web que permite la creción y gestión de repositorios.Funciona enlazando una rama remota del sistema de gestión de versiones con el repo-sitorio alojado en esta plataforma, de forma que se apliquen también en él los cambios.

4.5.2 Herramientas para la documentaciónLATEX: Es un lenguaje de etiquetado que permite generar documentos de alta calidadde forma rápida y sencilla. En el TFG se ha utilizado para la generación de la docu-mentación.

GNU Emacs: Es un editor de texto con una gran cantidad de funciones, muy popularpara realizar tareas de programación. Ha sido utilizado para escribir la documentacióndebido a las facilidades que presenta para escribir documentos utilizando LATEX.

Inkscape: Es un editor de gráficos vectoriales gratuito y de código libre. Con él sepueden crear y editar diagramas de todo tipo, gráficos, logotipos, etc. Ha sido utilizadopara crear el logotipo que se encuentra en el cliente web, y varios gráficos y diagramas.

Balsamiq Mockups: Es una herramienta que permite el rápido prototipado de interfacesgráficas de usuario. Se ha utilizado para diseñar el prototipo de la interfaz del clienteweb.

Libreoffice: Es un paquete de ofimática muy utilizado en entornos GNU/Linux. Hasido utilizada en el proceso de documentación de las iteraciones y para la gestión delos resultados de los experimentos desarrollados.

4.5.3 Lenguajes de programación y frameworksC: Es un lenguaje de programación originalmente desarrollado por Dennis Ritchieentre 1969 y 1972. Al ser un lenguaje de bajo nivel, ha sido utilizado para implementaraquellas partes de los algoritmos en las que se requería un mayor rendimiento.

Python: Python es un lenguaje de programación creado por Guido van Rossum. Es unlenguaje interpretado y multiparadigma. Ha sido utilizado para la implementación delos algoritmos y de la API REST en conjunción con Flask.

Flask: Es un framework escrito en Python que permite crear aplicaciones web rápiday sencillamente. Ha sido utilizado para la implementación de la API REST.

Javascript: Es un lenguaje de programación interpretado, orientado a objetos, impera-tivo y débilmente tipado. Se utiliza ampliamente en el desarrollo web, y en el TFG hasido utilizado para implementar el cliente web.

HTML: En ingés HyperText Markup Language, es un lenguaje basado en etiquetaspara describir la estructura de las paginas web. Se ha utilizado para la implementaciónde la interfaz del cliente web.

49

Bootstrap: Es un framework para el diseño web. Contiene plantillas de diseño contipografía, formularios, botones, cuadros, menús de navegación, etc. Se ha usado en laimplementación del cliente web debido a las facilidades que presenta para que todoslos los elementos presentes en la interfaz tengan un diseño común.

JQuery: Es una librería de JavaScript que facilita la manipulación del código HTML, elmanejo de eventos, las animaciones y la comuniación con un servidor. Debido a estascaracterísticas, se ha utilizado para facilitar la implementación del cliente web.

CSS: Cascading Style Sheets en inglés, es un lenguaje utilizado para describir la pre-sentación de documentos HTML o XML. CSS describe como debe ser renderizado elelemento estructurado en pantalla. Se ha utilizado para definir partes del diseño delcliente web.

4.5.4 Librerías científicasDEAP: Es un framework para Python que facilita el prototipado rápido de algoritmosevolutivos. Ha sido ampliamente utilizado en el desarrollo de todo el TFG.

Scikit-learn: Es una librería libre de software de aprendizaje automático para Python.Contiene algoritmos de clasificación, regresión, clustering, preprocesamiento de datos,etc. Algunos de ellos han sido utilizados en algunos scripts en los que se realizanexperimentos y en la parte de preprocesamiento de algunos algoritmos.

Numpy: Es el paquete por excelencia para realizar computación científica en Python.Ha sido utilizada a lo largo del TFG en la implementación de la mayoría de los algorit-mos.

Pandas: Es una librería que provee herramientas para realizar análisis de datos me-diante Python. Presenta una serie de estructuras de datos, como el dataframe, muyoptmizadas para realizar operaciones con ellas.

Matplotlib: Es la librería por excelencia para la generación de gráficos mediante Pyt-hon. Ha sido utilizada para presentar gráficamente todos los resultados relacionadoscon los algoritmos implementados.

4.6 HardwareLas herramientas hardware utilizadas a lo largo de todo el TFG son las siguiente:

El equipo portátil en el que ha sido desarrollado el proyecto es un Toshiba SatelliteP50-A-14G que tiene las siguientes especificaciones:

• 8GB de memoria RAM

• Intel(R) Core(TM) i7-4700MQ

• Disco duro HDD 500GB.

50

El equipo utilizado para la realización de algunos experimentos presenta las siguientescaracterísticas.

• 4GB de memoria RAM

• Intel(R) Core(TM) i5

• Disco duro HDD 100GB.

51

Capítulo 5

Resultados

E N el presente capítulo se realiza una descripción de los resultados obtenidos en el desa-rrollo del proyecto. Se explican los distintos algoritmos diseñados, los resultados ex-

perimentales obtenidos y la implementación del servidor REST y del cliente web.

5.1 Visión global

En Fig. 5.1 se muestra el mapa conceptual de las cuestiones más importantes del proyecto.En él se relacionan los conceptos más relevantes, mostrándo cuál es el camino apropiado paraobtener el representante de un conjunto de series temporales. En los siguientes apartados sedetallan los algoritmos genéticos que se han implementado para obtener el representante deun conjunto de series temporales y su integración en una API REST y en un cliente web.

5.2 Sprint 1: Estudio e implementación de DBA y COMASA

En el primer Sprint del proyecto se llevo a cabo la primera toma de contacto con el entornode desarrollo algoritmos de evolutivos DEAP. En este entorno es en el que se desarrollan to-dos los prototipos de algoritmos genéticos a lo largo del proyecto. También se procede a rea-lizar una búsqueda de datos de naturaleza temporal con los que poder probar los algoritmosdesarrollados. Por último, se lleva a cabo el estudio de las diferentes técnicas desarrolladashasta la fecha para la resolución del problema de la búsqueda de el prototipo de un conjuntode series temporales utilizando DTW como distancia. Una vez estudiadas, se reproducen losdos principales algoritmos para contrastar sus resultados y tomarlos como punto de partidaen el desarrollo del proyecto. Los dos principales algoritmos son DBA y COMASA que hansido detallados anteriormente.

Tras concluir estos tres objetivos marcados y observar la ineficiente y errónea implemen-tación en Python de la función DTW de los respositorios oficiales y dado el carácter críticode dicha función en los algoritmos que se pretenden desarrollar, se decide proceder a imple-mentarla de una forma más óptima en lenguaje C.

53

Figura 5.1: Mapa conceptual

54

5.2.1 DatosPara poder alcanzar los objetivos marcados en el proyecto, es de vital importancia tener

suficientes datos de naturaleza temporal con los que probar los algoritmos desarrollados. Paralos experimentos mostrados a lo largo de este documento se ha utilizado la colección de datosdel archivo UCR de series temporales [CKH+15]. Esta colección contiene varios conjuntosde datos divididos en dos partes, entrenamiento y test. En ambas partes, las series estánetiquetadas con la clase a la que pertenecen. De esta forma se pueden realizar experimentosenfocados a diferentes contextos, aquellos en los que se calcula el centroide de una clase o enlos que se calcula un centroide de varias clases. Unos y otros corresponden respectivamentea tareas de aprendizaje supervisado y no supervisado respectivamente.

Durante el desarrollo del proyecto se han realizado múltiples experimentos con objetivosdistintos. Durante el periodo de implementación de los algoritmos se han realizado experi-mentos para probar su funcionamiento y buscar los mejores valores para algunos parámetros.Para estas tareas se han seleccionado ocho conjuntos de datos, correspondientes a las seriesde una clase de diversos datos del archivo UCR. En Fig. 5.2 se muestran algunas seriespertenecientes a cada conjunto de datos.

Una vez implementados los algoritmos, el objetivo es realizar experimentos que comparenlas soluciones de la bibliografía con los diferentes algoritmos propuestos en el TFG. Para ello,se realizan otras selecciones de datos que serán detalladas posteriormente.

5.2.2 Implementación de DTWLa función DTW constituye la parte más crítica de los algoritmos genéticos que se van

a desarrollar. Ésta es necesario aplicarla N · |S| veces cada vez que se evalúa un individuo,dondeN es el tamaño de la población y S el del conjunto de series del cuál se quiere calcularel centroide. Por ello, para poder trabajar con series de longitud mayor de veinte o treintaelementos y con conjuntos de series grandes, es necesario que la implementación de estafunción sea lo más eficiente posible.

La implementación en Python de los repositorios oficiales contiene un error en el cálculodel alineamiento entre las series, el cuál fue puesto en conocimiento del autor en cuanto fuedetectado. A parte de ésto, esta función es excesivamente lenta para poder introducirla en losalgoritmos genéticos, tal y como se muestra en el listado inferior, que es un resumen del re-sultado de medir mediante cProfile el tiempo de cálculo de cada función de una ejecución deCOMASA. La salida está ordenada por tiempo total de cálculo de cada función (la columnatottime), y se observa que se ha aplicado la función DTW 272780 veces en un tiempo totalde 511 segundos. La prueba realizada es sobre un conjunto de datos de 45 series con unalongitud de 24 elementos. Para series de longitud mayor de 100 elementos, es inviable suuso.

55

Figura 5.2: Selección de series

56

$ python -m -s tottime cProfile ag_comasa.py

1313261090 function calls (1275000988 primitive calls) in 584.660 seconds

Ordered by: internal time

ncalls tottime percall cumtime percall filename:lineno(function)

272780 266.607 0.001 511.858 0.002 dtw.py:90(dtw)

471363840 41.343 0.000 41.343 0.000 dtw.py:128(<lambda>)

157121280 39.362 0.000 50.637 0.000 dtw.py:90(<lambda>)

157394060 30.289 0.000 30.289 0.000 dtw.py:122(<genexpr>)

11808492 21.101 0.000 53.832 0.000 copy.py:226(_deepcopy_list)

26921745 19.160 0.000 55.326 0.011 copy.py:145(deepcopy)

157121280 11.275 0.000 11.275 0.000 {abs}

Dados los malos resultados de la función DTW implementada en Python, se proceció adesarrollar la misma función en C. La comunicación entre el código Python en el que seimplementan los algoritmos genéticos y el código C de la función se consigue mediante lalibrería ctypes de Python, que provee una serie de tipos compatibles con C y permite realizarllamadas a funciones escritas en C desde un programa Python.

Al ser C un lenguaje de más bajo nivel, los resultados son considerablemente mejores,permitiendo así la nueva implementación el uso de los algoritmos genéticos desarrolladossobre conjuntos de datos mayores. En el listado inferior se observan los resultados de cProfi-le sobre esta nueva implementación. Mientras que la versión anterior invierte 511 segundosen ejecutar la función DTW, la versión que utiliza la implementación en C emplea tan solo12 segundos. Esta enorme mejoría en el rendimiento ha permitido llevar a cabo pruebas enescenarios realistas con los algoritmos genéticos implementados.

$ python -m -s tottime cProfile ag_comasa.py

203716413 function calls (165492090 primitive calls) in 70.339 seconds

Ordered by: internal time

ncalls tottime percall cumtime percall filename:lineno(function)

263580 11.427 0.000 12.315 0.000 dtw.py:27(dtw)

11869511 4.521 0.000 5.701 0.000 copy.py:267(_keep_alive)

59846336 3.813 0.000 3.813 0.000 {method ’append’ of ’list’ objects}

2866 3.528 0.001 3.533 0.001 DBA.py:6(f)

38851194 3.428 0.000 3.428 0.000 {method ’get’ of ’dict’ objects}

50581106 2.462 0.000 2.462 0.000 {id}

1382 1.053 0.001 7.511 0.005 DBA.py:19(g)

1 0.641 0.641 69.572 69.572 ag_comasa.py:37(ag)

5.2.3 Resultados experimentalesA continuación se muestran los resultados de los experimentos llevados a cabo con COMASA.

No se muestran aquellos realizados con DBA, ya que al incluir COMASA a DBA como opti-mización individual en el proceso evolutivo, sus resultados siempre lo superan.

57

Los parámetros utilizados en los experimentos son los siguientes:

1. El número de generaciones es de 200.

2. El tamaño de la población se fija en 100.

3. La probabilidad de cruce es de 0,2.

4. La probabilidad de mutación es de 0.1

En el Cuadro 5.1 se muestra el fitness del mejor individuo obtenido en cada conjunto dedatos, así como el tiempo de cada ejecución.

Datos Fitness COMASA Tiempo(s) COMASA

50words 24598,25 1795,12cricket 177576.0 1431.23earthquakes 324345.58 3031.72gestures 280535.41 4767.26lighting 302188.67 5115.0medical images 4103.66 148.97syntetic control 13345.08 310.03yoga 562518.39 3107.32

Cuadro 5.1: Resultados de COMASA

En Fig 5.3 se muestra el conjunto de series de una clase de 50words, que es del conjuntodel que se mostrarán las secuencias medias obtenidas a lo largo del documento para ilustrarlos resultados obtenidos por los distintos algoritmos genéticos.

Figura 5.3: Una clase del conjunto de datos 50words

En Fig. 5.4 se muestra la secuencia media obtenida y en Fig. 5.5, la gráfica del fitness delmejor individuo en cada generación respecto al número de generaciones.

58

Figura 5.4: Centroide del conjunto de datos 50words

Figura 5.5: COMASA: Curva del fitness con una clase de 50words

5.3 Sprint 2: Desarrollo de AG-naiveEn este segundo Sprint se tiene como objetivo implementar un algoritmo genético sen-

cillo, llamado AG-naive, con operadores definidos de forma genérica, para contrastar susresultados con DBA y COMASA. En primer lugar, se describirá la forma en la que se repre-sentan los individuos y los operadores utilizados. Posteriormente se mostrarán los resultadosexperimentales obtenidos.

5.3.1 Algoritmo genéticoLa estructura del algoritmo es sencilla. Se parte de una población inicial de tamaño n. De

ella, se seleccionan n individuos permitiendo que haya repetidos en el conjunto seleccio-

59

nado. A los individuos de ese conjunto se les aplica primero, con la probabilidad indicada,el cruce y después la mutación. Este conjunto de n individuos pasará a formar la siguientegeneración.

Individuos

Cada individuo de la población del algoritmo genético es una serie temporal de la longitudde las series del conjunto del que se quiere obtener la secuencia media. Así, un individuoconstituye una serie candidata a ser el centroide del conjunto. De esta forma, el genotipo yfenotipo de cada individuo coincide. Podemos formalizar la representación de la poblaciónen una generación t de la siguiente manera:

Pt = {X1, ..., Xn} (5.1)

donde cada individuo se representa como:

Xi = (x1, ..., , xm), i ∈ {1, ...,m} (5.2)

Por lo que un gen del individuo es un elemento de una serie temporal candidata a ser elcentroide del conjunto.

Operadores

Los operadores definidos, al ser de carácter general y no especializados para el dominiodel problema, se han implementado haciendo uso de funciones ya definidas en DEAP, aexcepción de los operadores de evaluación y generación. La función utilizada para definirlosse muestra en Listado 5.1.

Los operadores utilizados son:

Generación: Los individuos de la población de partida son series seleccionadas alea-toriamente del conjunto de secuencias.

Evaluación: El fitness de un individuo se calcula midiendo su distancia DTW con cadaelemento del conjunto de series del que se quiere calcular la secuencia media. Cuantomenor sea el fitness, más apto será el individuo. Formalmente, el fitness de un indivi-duo I , se calcula como

Fi =n∑i=1

DTW 2(I, Si) (5.3)

donde S es el conjunto de series temporales del que se calcula el centroide.

Selección: Se utiliza una estrategia de selección mediante torneo. Así, al dar posibili-

60

dades a aquellos individuos no muy aptos a pasar a la siguiente generación se garantizala diversidad de la población.

Cruce: Este operador se define utilizando un cruce de dos puntos.

Mutación: Se utiliza el operador de mutación gaussiano.

1 def register_toolbox(S, mins, maxs):

2 toolbox = base.Toolbox()

3 toolbox.register(’generate’, generate.sample_generate, S=S)

4 toolbox.register(’population’, tools.initRepeat, list, toolbox.generate)

5 toolbox.register(’evaluate’, fitness.fitness, S=S)

6 toolbox.register(’mutate’, tools.mutation.mutGaussian, mu=0, sigma=0.02, indpb=0.1)

7 toolbox.register(’mate’, tools.crossover.cxTwoPoint)

8 toolbox.register(’select’, tools.selTournament, tournsize=10)

9 return toolbox

Listado 5.1: Función que registra los operadores utilizando la clase Toolbox de DEAP

5.3.2 Resultados experimentalesPara los experimentos llevados a cabo se han utilizado los mismos conjuntos de datos que

en en las pruebas de COMASA con el fin de poder comparar los resultados. También losparametros fijados son los mismos. En el Cuadro 5.2 se muestran los resultados obtenidosde las ejecuciones del algoritmo AG-naive, comparándolos con los resultados de COMASA.Tal y como se observa, COMASA supera en la mayoría de los conjuntos de datos al algoritmogenérico desarrollado en este Sprint. También se advierte de que COMASA es mucho máslento que AG-Naive.

Datos Fitness Tiempo(s) Fitness COMASA Tiempo(s) COMASA

50words 31851.98 364.32 24598,25 1795,12cricket 238463.58 307.56 177576.0 1431.23earthquakes 345084.36 739.50 324345.58 3031.72gestures 863674.01 1624.59 280535.41 4767.26lighting 524964.09 1965.69 302188.67 5115.0medical images 6133.40 105.71 4103.66 148.97syntetic control 13902.84 181.51 13345.08 310.03yoga 562518.39 3107.32 562518.39 3107.32

Cuadro 5.2: Resultados de AG-naive

En Fig. 5.6 se muestra la serie media del conjunto de datos 50words. Al utilizar en estealgoritmo, como población inicial series del conjunto del que se quiere calcular el centroi-de, se parte de una población mucho más apta que en COMASA. En Fig. 5.7 se observa laevolución del fitness del mejor individuo de cada generación a lo largo de las generaciones.A diferencia de COMASA, AG-naive necesita más generaciones para alcanzar la convergen-cia.

61

Figura 5.6: Centroide del conjunto de datos 50words

Figura 5.7: AG-Naive: Curva del fitness con una clase de 50words

5.4 Sprint 3: Desarrollo de AG-segments

El objetivo del tercer Sprint es implementar un algoritmo genético más avanzado que AG-Naive, con unos operadores específicos sobre el dominio del problema. Este algoritmo se hadenominado AG-segments. Los operadores de cruce y mutación elaborados resultan clavesen la notoria mejoría de este algoritmo respecto al desarrollado en el Sprint anterior. Unavez implementado, se muestran algunos experimentos realizados en los que se compara elrendimiento del algoritmo implementado con COMASA.

62

5.4.1 IndividuosLos individuos se representan de la misma forma que en el algoritmo AG-Naive. Así, el

genotipo y fenotipo de los individuos coincide. Siendo así los individuos series candidatasa ser el centroide del conjunto. Un gen queda, por tanto, definido como un elemento de unaserie candidata.

5.4.2 Operador de cruceLa idea subyacente al operador de cruce implementado es la de combinar de manera re-

levante las formas de los individuos que se cruzan. A diferencia del operador de cruce delalgoritmo anterior, en este caso no se intercambian secciones de los indiviudos definidas deforma arbitraria, sino que los segmentos intecambiados vienen definidos por el alineamientoproporcionado por DTW entre las dos series a cruzar.

Los segmentos considerados para el cruce son aquellas secciones de las series que estánrelacionadas. Esta relación la determina DTW mediante el alineamiento. Respetando las re-laciones entre las secciones, se evita intercambiar una parte de una forma de una serie y otraparte de una forma distinta de otra serie. Por ejemplo, intercambiar una sección de una seriedonde hay un crecimiento con una sección en la que hay un decrecimiento da lugar a unnuevo individo que nada tiene que ver con sus dos progenitores y que, probablemente, seaun individuo poco apto que será desechado pronto en las futuras generaciones.

En Fig. 5.8 se observa la idea de la división en segmentos que se obtiene alineando dosindividuos mediante DTW. Cada una de las líneas rectas representa un segmento. Así, en estecaso se tendrían seis segmentos diferentes. Esta división en segmentos se formaliza como sedetalla a continuación.

SeanX = x1, ..., xm e Y = y1, ..., ym dos individuos de la población. SeaW = w1, ...wk, ..., wL

el alineamiento óptimo entreX e Y resultado de aplicar DTW sobre ambos individuos, dondewk = (wxk , w

yk).

Se define S = s1, ..., sk, ..., sp como una secuencia de segmentos, donde sk = wini, ..., wfin

es una secuencia de puntos del alineamiento. S cumple las siguientes propiedades:

1. si ∩ sj = ∅, ∀i, j ∈ {1, ..., p}, i 6= j.

2.p∑i=1

|si| = L

3. Si wi es el primer punto de sk y wj es el primer punto de sk+1, entonces i < j.

Y cada segmento sk = wini, ..., wfin, cumple solo una de las siguientes propiedades:

1. wxi 6= wxj ∧ wyi 6= wyj , ∀i, j ∈ {ini, ..., f in}, i 6= j.

2. wxi = wxj ∧ wyi 6= wyj , ∀i, j ∈ {ini, ..., f in}, i 6= j.

3. wxi 6= wxj ∧ wyi = wyj , ∀i, j ∈ {ini, ..., f in}, i 6= j.

63

Figura 5.8: Ejemplo de segmentos de un alineamiento

El algoritmo que implementa la operación de cruce es el siguiente:

1. Calcula el alineamiento entre los dos individuos mediante DTW.2. Parte el alineamiento en segmentos.3. Selecciona de forma aleatoria una secuencia de segmentos.4. Intercambia los genes relacionados por el alineamiento en la secuencia de segmentosseleccionados entre ambos individuos5. Interpola las secuencias de genes intercambiadas.

La secuencia de segmentos es, en definitiva, una parte del alineamiento, es decir, unarelación establecida por DTW entre una subsecuencia de los genes de un individuo y y otrasubsecuencia de los genes de otro individuo. Estos genes son intercambiados entre ambosindividuos, dando como resultado dos nuevos individuos. Debido a que se pueden haberintercambiado secuencias de genes de distinta longitud, los individuos resultantes pueden notener el mismo tamaño que el resto de individuos de la población. Para resolver este problemase reinterpolan los individuos para que tengan la longitud deseada.

En las siguientes figuras se muestra un ejemplo de todos los pasos seguidos para cruzardos individuos. En Fig. 5.9 se encuentran los dos individuos que serán cruzados, es decir,los progenitores. En Fig. 5.10(a) muestra el alineamiento entre ambos individuos y cómo essegmentado. En Fig. 5.10(b) se observa la secuencia de segmentos seleccionada. Los genes

64

de los individuos que son relacionados mediante la secuencia de segmentos del alineamientoseleccionada son los que se cruzan. Las series, con los genes correspondientes a los segmen-tos del alinemiento seleccionados marcados en rojo, se muestran en Fig. 5.11. Por último,el resultado del cruce con la interpolación ya realizada sobre las secciones intercambiadasentre los individuos se muestra en Fig. 5.12.

(a) Individuo 1 (b) Individuo 2

Figura 5.9: Operador de cruce(I): Individuos a cruzar

(a) Alineamiento segmentado (b) Segmentos seleccionados

Figura 5.10: Operador de cruce(II): Alineamientos

En este ejemplo se observa cómo mediante este operador de cruce se seleccionan paraser cruzadas aquellas secciones de los individuos que corresponden a las mismas formas.En este caso concreto, se ha seleccionado aquel correspondiente al primer montículo. Cru-zar los individuos de esta forma supone una gran ventaja respecto al algoritmo AG-Naive,desarrollado en el Sprint anterior, que cruzaba los individuos de forma arbitraria.

65

(a) Individuo 1 (b) Individuo 2

Figura 5.11: Operador de cruce(III): Individuos con secciones a intercambiar marcadas

(a) Individuo mutado 1 (b) Individuo mutado 2

Figura 5.12: Operador de cruce(III): Individuos mutados

5.4.3 Operador de mutaciónLa mutación implementada en el algoritmo tiene como objetivo modificar las formas de la

serie temporal que representa cada individuo. A diferencia del operador de mutación gaus-siano utilizado en el algoritmo AG-naive que solo modificaba un gen de cada individuo, eloperador desarrollado mutará, en algunos casos, secuencias de genes.

El operador implementado se compone a su vez de tres operadores, que se aplican deforma excluyente con una probabilidad determinada. El primero de estos operadores es el deestrechamiento y ensanchamiento, el segundo, el de subida o bajada de zona y el último, elde subida o bajada radical.

Mediante la combinación de estos tres operadores se logra introducir una gran diversidaden los individuos mutados, que resulta interesante para ampliar el espacio de búsqueda ex-plorado a lo largo de la ejecución del algoritmo genético. A continuación se explica de formadetallada cada uno de estos operadores.

Estrechamiento/ensanchamiento

La idea básica consiste en seleccionar dos partes del individuo, disminuir la longitud deuna y ampliar la de la otra, preservando la forma de ambas. Esta selección de dos secciones

66

de la secuencia por la que está representada un individuo se realiza de forma aleatoria. Laconservación de la forma tras la disminución o ampliación de la longitud del segmento serealiza mediante interpolación.

El algoritmo que implementa este operador es el siguiente:

1. Determina aleatoriamente la longitud en la que será disminuida una de las secciones yampliada la otra.2. Selecciona aleatoriamente dos segmentos del individuo.3. Se decide aleatoriamente qué segmento es el que se estrecha y cuál es el que se amplia.4. Se reinterpolan ambos segmentos a las longitudes deseadas.

En el primer paso, la longitud en la que son disminuidas y ampliadas las secciones vieneacotada por el parámetro d, cuyos valores están comprendidos entre 0 y 1. El producto deeste parámetro por la longitud del individuo, será la cota superior del tamaño de la disminu-ción y ampliación. Así, cuanto menor sea el valor de d, mas conservadora será la mutaciónrealizada.

Por ejemplo, si se tiene un individuo de 20 elementos y d = 0,25, el conjunto de va-lores posibles a seleccionar para la disminución y ampliación serán {1, 2, 3, 4, 5}, ya que20 · 0,25 = 5. Se selecciona, por ejemplo, un valor de 3. Despúes de haber determinado lavariación, se seleccionan los segmentos aleatoriamente. Un segmento pasa a medir su longi-tud menos 3 y el otro su longitud más 3, reinterpolándolos.

En la Fig. 5.13 se muestran tres ejemplos de los individuos resultantes tras aplicar esteoperador de mutación. En Fig. 5.13(b), se aprecia como se ha ensanchado el segundo mon-tículo, mientras que la parte llana del final se ha estrechado. En Fig. 5.13(c), sin embargo,se estrecha la parte llana anterior al primer montículo y se amplía la que se encuentra entrelos dos montículos. En Fig. 5.13(d), se ha ensanchado el primer montículo, mientras queel segundo se ha estrechado. Se aprecia en estos ejemplos, que a medida que aumenta elvalor seleccionado para la disminución y ampliación de los segmentos, la mutación es me-nos conservadora. Por lo tanto, resulta importante buscar un valor adecuado de d, que acoteapropiadamente el tamaño máximo del estrechamiento y ensanchamiento producido sobrelos individuos.

En Cuadro 5.3, se muestran los experimentos realizados para seleccionar el valor de d. Paralos experimentos de parametrización realizados en esta sección y las siguientes se ejecutanlos algoritmos para cada conjunto de datos en tres ocasiones y se calcula la media de losfitness de los mejores individuos. Se hace de esta forma con el objetivo de minimizar laimportancia de la aleatoriedad en los resultados

Se miden los resultados con diferentes valores de d, que van desde 0, 01 a 0, 05. Se pruebasolo en este rango de valores de d porque con valores mayores la mutación es muy agresiva

67

(a) Individuo sin mutar (b) Variación = 3

(c) Variación = 4 (d) Variación = 5

Figura 5.13: Ejemplos de mutación

y dificulta la convergencia. Así, se observa que el mejor valor de d es 0,03, ya que se dan losmejores resultados con él en cinco de los nueve conjuntos de series, siendo en algún conjunto,como por ejemplo gestures, la diferencia respecto a los otros valores bastante importante. Portanto, se decide utilizar 0,03 como valor de d.

Datos 0.01 0.02 0.03 0.04 0.05

50words 23908.74 23627.79 23400.04 23635.89 23406.00cricket 243793.95 213630.40 214443.83 188209.90 237195.99earthquakes 387736.93 389564.51 391467.28 390560.85 397946.66gestures 447687.35 373401.44 353267.13 421639.16 410236.65lighting 332044.69 347760.43 357936.59 311837.78 321764.33medical_images 4958.69 4516.81 4634.98 4976.01 4481.02syntetic_control 14499.64 14562.67 14000.29 14473.84 14610.61yoga 441674.15 397962.26 359496.31 377992.37 400300.82

Cuadro 5.3: Parametrización de AG-segments (I)

La variabilidad aportada por este operador de mutación resulta clave en el algoritmo desa-rrollado, debido a que es capaz de mutar formas que resultan más relevantes para DTW quela mutación de un gen únicamente.

68

Subida/bajada

En este segundo operador, la idea de mutar formas en lugar de genes aislados se mantiene.Así, la mutación se aplica sobre conjuntos de genes y estos son modificados conjuntamen-te. La modificación de los genes seleccionados para mutarlos en este operador consiste endesplazarlos de forma vertical conjuntamente.

El algoritmo que implementa este operador de mutación es el siguiente:

1. Se selecciona de forma aleatoria una sección del individuo, es decir, una secuencia degenes.2. Se selecciona aleatorimante, mediante una distribución gaussiana, de media igual a ceroy desviación típica igual a σ, la intensidad del desplazamiento vertical de los genes de lasección selecionada.3. A cada uno de esos genes se les aplica el desplazamiento obtenido en el paso anterior conuna leve variación aleatoria en cada uno, determinada esta variación por una distribuciónuniforme.

De esta forma, se mutan secciones del individuo en la que todos los genes son desplazadossiguiendo una misma tendencia y no genes de forma aislada como ocurría en AG-naive.

Al igual que en el operador anterior, en este caso también es necesario fijar el valor de unparámetro, que en este caso es la desviación típica, σ, de la distribución gaussiana. Cuantomayor sea éste, más probable será que se produzcan mutaciones menos conservadores, difi-cultando la convergencia del algoritmo. Mientras que un valor de σ demasiado bajo podríaprovocar que el algoritmo progresará más lentamente porque la variablidad aportada por esteoperador sería muy baja.

Para que la parametrización de este operador tenga sentido, se hace necesario que losindividuos de la población inicial estén normalizados de la siguiente forma:

x′i =xi − xσ∗

(5.4)

donde xi es un gen de un individuo y x′i es el gen normalizado. La media, x, y la desviacióntípica, σ∗, se calculan de todos los individuos juntos.

En el Cuadro 5.4 se muestras los experimentos realizados para seleccionar el valor de σ.Se ejecuta el algoritmo con valores del parámetro σ comprendidos entre 0,005 y 0,03 sobrecada conjunto de datos. Los individuos han sido previamente normalizados. Se observa queel mejor valor para σ es 0,02, pues obtiene el mejor resultado en más conjuntos de datos.

69

Subida/bajada radical

Éste último operador modifica un solo gen del individuo. Para ello utiliza una mutacióngaussiana con una distribución normal de media igual a cero y de una desviación típica conun valor bastante mayor al del operador de mutación anterior. De esta forma, se permite lamutación de un gen de una forma más agresiva.

En el Cuadro 5.5 se muestran los experimentos realizados para seleccionar el valor de ladesviación típica. Los resultados obtenidos muestran que el mejor valor para la desviacióntípica de la distribución normal de la mutación gaussiana es 0,3.

5.4.4 Operador de evaluaciónEl fitness de los individuos se calcula sumando la distancia DTW del individuo con cada

serie del conjunto del cuál se calcula el centroide, tal y como se indicó en Eq. 5.3. Sinembargo, este operador no es escalable a conjuntos grandes de series, ya que siempre queobtenga un individuo nuevo, se debe ejecutar el algoritmo DTW una vez por serie que hayaen el conjunto. Lo que da lugar a una complejidad temporal lineal respecto al tamaño delconjunto de series.

Una modificación introducida en este nuevo algoritmo genético es la de evaluar un indi-viduo seleccionando solo un subconjunto de series con las que calcular el fitness. De estaforma, cuando el conjunto de series es grande, evaluar un individuo con solo una parte delconjunto seleccionada de forma aleatoria puede permitir obtener resultados aceptables en untiempo mucho menor.

Al principio de cada generación se selecciona aleatoriamente un subconjunto C del con-junto de series S. Toda la descendencia de la población de esa generación será evaluada solocon C. Nótese que a diferencia de los otros algoritmos genéticos detallados anteriormente, esnecesario reevaluar todos los individuos que pasarán a formar parte de la nueva generación,y no solo aquellos que han sufrido algún cambio. De esta forma se evita que un individuomantenga un fitness muy bueno que fue obtenido con un subconjuto C formado por unaselección de series favorable, y que no generaliza bien para todo S.

Esta variación introducida en el operador de evaluación, tal y como se mostrará en los re-sultados experimentales posteriormente, se obtiene una mejora muy importante en la rapidezde la convergencia del algortimo, sin que esta disminución del tiempo invertido en el cálculodel centroide lo empeore.

5.4.5 Estudio de complejidadEn esta sección se detalla la complejidad del algoritmo propuesto. Sea N el número de

secuencias del conjunto del que se quiere calcular el centroide, P el tamaño de la población,L la longitud de las secuencias, y por tanto de los individuos, G el número de generacionesy S la fracción del conjunto de series con las que se realiza la evaluación parcial. En el

70

Cuadro 5.6 se muestra la complejidad temporal de cada operador.

La complejidad total del algoritmo utilizando el operador de evaluación que calcula elfitness con todo el conjunto de series es:

O(G · (P · L+ P · L2 + P ·N · L2)) (5.5)

= O(G · P · L · (1 + L+N · L)) (5.6)

= O(G · P · L2 ·N) (5.7)

Si se utiliza el operador de evaluación parcial, la complejidad es la siguiente:

O(G · P · L2 ·N · S) (5.8)

Como S < 1, y en conjuntos de datos grandes, S << 1, el tiempo de cálculo requeridopara obtener el centroide resulta ser mucho menor utilizando una evaluación parcial.

Observando estas complejidades en comparación con las del algoritmo COMASA mos-tradas en Eq. 3.25, no se ven a priori diferencias significativas. Es más, si en COMASA seconsidera que L = T , las complejidades serían exactamente las mismas. Sin embargo, larepresentación de los individuos en COMASA resulta mucho más costosa, tanto en térmi-nos temporales como de memoria. Es por esto, por lo que en los experimentos realizados seobserva una diferencia temporal significativa entre el algoritmo AG-segments y COMASA,hasta el punto que hace inviable el uso de COMASA sobre algunos conjuntos de datos, mies-tras que AG-segmentes escala mucho mejor. Además los tamaños de las poblaciónes utili-zados en COMASA son mucho menores que en AG-segments debido a las limitaciones dememoria.

5.4.6 ExperimentosEn esta sección se muestran los diversos experimentos realizados con AG-segments y

comparándolo con COMASA. El objetivo de esta sección es comparar algoritmos y no im-plementaciones. Así, la versión del algoritmo COMASA utilizada sigue rigurosamente las in-dicaciones dadas en el trabajo original [PG12], y tanto para la implementación de COMASA

como de AG-segments se ha utilizado la función DTW implementada en C y el frameworkDEAP. Además, todos los resultados que se comparan entre sí se han obtenido ejecutando losdiferentes programas en la misma máquina y en las mismas condiciones.

Los experimentos realizados están enfocados a estudiar el rendimiento de los algoritmoscuando se utilizan en tareas de aprendizaje no supervisado y supervisado. En el primero deestos casos, se busca un centroide entre series distintas, que no tienen por qué seguir unmismo patrón. En el segundo caso, la búsqueda del centroide se hace sobre un conjunto de

71

Datos 0.005 0.01 0.015 0.02 0.025 0.03

50words 26264.75 22616.13 22605.49 21248.76 23557.50 22954.16cricket 238314.49 231119.11 234768.94 201284.65 186319.48 191637.74earthquakes 396202.85 388314.75 395921.55 396258.51 390698.65 397992.58gestures 380914.57 356672.81 476780.85 315414.88 440236.65 467036.53lighting 339109.38 360418.96 351668.70 338578.12 356509.14 339400.33medical_images 4515.69 5207.02 5308.44 4391.12 5192.96 5010.61syntetic_control 15287.69 15548.99 15377.29 14973.14 15113.83 15277.61yoga 441674.15 457962.26 431496.31 377992.37 448300.82 435645.23

Cuadro 5.4: Parametrización de AG-segments (II)

Datos 0.1 0.2 0.3

50words 21209.07 21662.21 20506.84cricket 224934.18 214596.13 180275.04earthquakes 393012.37 385832.21 393771.88gestures 392303.23 328749.26 249884.30lighting 306326.56 335398.01 325607.66medical_images 4486.60 4236.54 4065.57syntetic_control 14699.29 14389.24 14149.21yoga 352508.67 323992.10 287021.49

Cuadro 5.5: Parametrización de AG-segments (III)

Operación Complejidad temporal

Generación O(P )

Evaluación O(N · L2)

Evaluación parcial O(N · L2 · S−1)Mutación O(L)

Cruce O(L2)

Cuadro 5.6: Complejidad de los operadores

72

series que presentan patrones parecidos.

Experimentos: Aprendizaje no supervisado

Los datos utilizado para realizar estos experimentos corresponden a algunos de los cua-tro conjuntos de series más grandes de todo el Archivo UCR. En concreto el conjunto dedatos StarLightCurves es el más grande de todo el Archivo. En el Cuadro 5.7 se muestra ladescripción de los datos utilizados.

Nombre Series Longitud

ElectricDevices 16637 96uWaveGestureLibrary-X 4478 315Yoga 3300 426StarLightCurves 9236 1024

Cuadro 5.7: Conjunto de series: Experimentos de cálculo de centroide (I)

Debido al tamaño de los datos utilizados, no se ha ejecutado el algoritmo COMASA so-bre los conjuntos yoga y StarLightCurves por limitaciones de memoria. Los experimentosrealizados consisten en ejecutar el algoritmo AG-segments, utilizando diferentes tamaños desubconjuntos para la evaluación, y COMASA, cuando sea posible, sobre estos conjuntos dedatos. Se mide la disminución del fitness a lo largo del tiempo y no de las generaciones. Estose debe a que la duración de una generación utilizando un tamaño de subconjunto u otro esmuy diferente, siendo en algunos casos hasta 1000 veces más rápida dependiendo del tamañodel subconjunto elegido.

En Fig. 5.14 se muestran los resultados de COMASA y AG-segments sobre los conjun-tos de datos uWaveGestureLibrary-X y ElectricDevices. En estos gráficos se ilustra comoel algoritmo AG-segments cuando utiliza un porcenjaje, p, pequeño del conjunto de seriescompleto obtiene resultados mejores más rápidamente que COMASA. En estas ejecuciones,COMASA realiza tan solo dos generaciones, utilizando alrededor de 5 Gigabytes de memoria,mientras que las ejecuciones de AG-segments han utilizado alrededor de 300 Megabytes. Es-to se debe, tal y como ya se apuntó anteriormente, a que COMASA utiliza una representaciónde los individuos muy costosa en memoria, pues guarda el alineamiento de cada secuenciadel conjunto con la hipotética secuencia media.

En Fig. 5.15 se muestran los resultados de yoga y de StarLightCurves del algoritmo AG-segments.

Observando los resultados, destaca que cuanto menor es el valor de p, más rápido convergela evolución. Esto se debe a que, por ejemplo, en la ejecución en la que se utiliza un p =

0,1 %, se realizan 4000 generaciones en el mismo tiempo que se realizan 4 generaciones conun p = 5 %. Esta enorme diferencia en el número de generaciones que se ejecutan por unidadde tiempo permite que la evolución sea más rápida. Otro detalle interesante es que no solo se

73

(a) Curvas Fitness: ElectricDevices

(b) Curvas Fitness: uWaveGestureLibrary-X

Figura 5.14: Curvas de fitness para aprendizaje no supervisado (I)

obtienen resultados más rápidos cuanto menor es el valor de p, sino que son mejores. Comose ve en las gráficas, cuando el valor de p es alto, la evolución converge en valores de fitnessmás altos que cuando p es bajo. Otra observación interesante es que cuando p toma un valordemasiado pequeño, la evolución es inestable.

74

(a) Curvas Fitness: Yoga

(b) Curvas Fitness: StarLightCurves

Figura 5.15: Curvas de fitness para aprendizaje no supervisado (II)

Experimentos: Aprendizaje supervisado

En esta sección se muestran los experimentos realiazados con AG-segments y COMASA

sobre conjuntos de series temporales que pertenecen a una misma clase de un conjunto dedatos del Archivo UCR. En este caso, las series de las que se calcula el centroide presentanpatrones similares, por lo que AG-segments partirá de una población muy apta en muchoscasos. Se recuerda al lector que la inicialización de la población en COMASA es aleatoria,mientras que en AG-segments es una selección del conjunto de series.

75

Los conjuntos de datos utilizados para estos experimentos corresponden a aquellas clasesde conjuntos de series del Archivo UCR que contienen más de 50 series, para poder utilizarcorrectamente la evaluación parcial, y que tienen una longitud menor de 500, para que nosuponga una limitación la memoria ocupada en la ejecución de COMASA.

En Fig. 5.16 se muestran algunas gráficos similares a los mostrados en el apartado anterior,en los que se muestra la disminución del fitness respecto al tiempo.

Figura 5.16: Curvas de fitness para aprendizaje supervisado

El comportamiento del algoritmo cuando se realiza una evaluación parcial prqueña siguecomportándose mejor que cuando se calcula el fitness con todo el conjunto de series. Sinembargo, al ser conjuntos de series pequeños, la capacidad de generalización de la evaluaciónparcial disminuye. También se observa que la población inicial del algoritmo COMASA esmucho peor que la de AG-segments. En el caso del conjunto de series yoga se ilustra cómode importante es la diferencia en la generación de la población cuando las series del conjuntoya son muy parecidas entre sí.

Debido principalmente al operador de evaluación parcial y a que éste generaliza mejorcon conjuntos grandes de datos, los resultados obtenidos en los experimentos de aprendizajeno supervisado son mejores que los de supervisado. La razón de esto es el tamaño de losconjuntos de datos utilizados más que la naturaleza de los mismos.

5.5 Sprint 4: Desarrollo de AG-SEGMENTS-COOPEn esta iteración se desarrolla un algoritmo genético que mantiene las ideas principales de

AG-segments, pero que presenta una estrategia de evolución cooperativa entre varias espe-

76

cies.

5.5.1 Algoritmo genéticoLa idea subyacente a un esquema cooperativo en un algoritmo genético es la de combinar

varias poblaciones, o especies, que han evolucionado independientemente y que, por tanto,han explorado distinas regiones del especio de búsqueda del centroide. Al combinar estas es-pecies, se obtendrán individuos que no se habrían obtenido por ninguna de esas poblacionesde forma aislada, pudiendo conseguir así individuos más aptos.

La estrategia cooperativa diseñada consiste en el siguiente algoritmo:

1. Se generan las especies y se evalúa el fitness de cada individuo.2. Mientras no se hayan realizados todas las generaciones:

2.1. Para cada especie:2.1.1. Se cruzan y mutan los individuos.2.1.2. Se seleccionan los individuos que pasan a la siguiente generación.2.1.3. Se selecciona el mejor individuo de la especie como su representante

en esa generación.2.2. Si es generación de intercambio, se añade a cada especie los representantes

del resto de subpoblaciones.

Los operadores de cruce y mutación utilizados son los mismos que los del algoritmo ge-nético anterior.

5.5.2 Estudio de complejidadLa complejidad de los operadores es la misma que en el algoritmo AG-segments, pero la

complejidad general del algoritmo se ve modificada. Sea E el número de especies involucra-das en el proceso de evolución.

O(G · P · L2 ·N · E) (5.9)

La complejidad general del algoritmo en caso de que se utilice el operador de evaluaciónparcial es:

O(G · P · L2 ·N · S · E) (5.10)

5.6 Sprint 5: Desarrollo de algoritmos de aprendizajePara poder utilizar los algoritmos evolutivos implementados en tareas de aprendizaje su-

pervisado y no supervisado, se desarrollan dos algoritmos de cada uno de esos ámbitos. Para

77

el primero, se implementa el algoritmo K-Means, y para el segundo, una modificación delalgoritmo KNN, denominada NC.

5.6.1 K-Means con DTWAlgoritmo

El algoritmo K-Means calcula el centroide de cada grupo de elementos en cada iteración,para que en la siguiente se reagrupen los elementos perteneciendo a aquél cuyo centroide seamás cercano. Por tanto, el algoritmo genético implementado para el cálculo del representantede un conjunto de series temporales utilizando DTW se introduce en el algoritmo K-Meanspara el cálculo del centroide de cada grupo en cada iteración.

El algoritmo completo del K-Means con el algoritmo genético integrado en él es el si-guiente:

1. Mientras no se hayan inicializado los centroides N veces:1.1. Se generan los centroides aleatoriamente.1.2. Mientras no se hayan realizados todas las iteraciones:

1.2.1. Se calcula la distancia DTW entre cada elemento y cada centroide, yse asigna al grupo cuyo centroide es más cercano.

1.2.2. Se calcula el centroide de cada grupo utilizando el algoritmo genéticoAG-segments.

1.3. Si el agrupamiento obtenido tiene una inercia menor que el conseguidohasta este instante, se guarda el obtenido como el mejor agrupamiento.

2. Se devuelve el mejor agrupamiento.

En el algoritmo implementado se realizan varias ejecuciones del algoritmo K-Means condistintas inicializaciones aleatorias de los centroides, lo cuál permite mitigar la importanciade la inicialización en el resultado final del agrupamiento.

Para el reagrupamiento de los elementos, se utiliza la distancia DTW entre cada centroidey cada elemento, en lugar de la distancia Euclídea, y para el cálculo del centroide se utilizael algoritmo genético AG-segments.

Experimentos

En [NR07], se discute la incapacidad de poder utilizar el algoritmo K-Means con la dis-tancia DTW debido a la falta de un método que pueda calcular el centroide de un conjunto deseries temporales utilizando DTW. En él se indica que el centroide obtenido por los métodosactuales no son lo suficientemente buenos como para que funcione correctamente este algo-ritmo. Una de las razones que se da es la inconsistencia de las formas entre los centroidesobtenidos en diferentes ejecuciones del algoritmo propuesto en [GMTS96] al reordenar deforma diferente el conjunto de series sobre las que se aplicaba.

78

El método desarrollado en estre proyecto no obtiene el prototipo exacto de un conjunto deseries temporales, sino una estimación. Aún así, tal y como se muestra a continuación, loscentroides obtenidos en diferentes ejecuciones del algoritmo presentan formas muy simila-res, poniendose así de manifiesto la consistencia del método desarrollado.

Figura 5.17: Selección de series de Yoga

Figura 5.18: Centroides de Yoga obtenidos en diferentes ejecuciones

En Fig. 5.17 se muestra una selección de series del conjunto Yoga. Se ha decidido utilizarun conjunto con series tan diferentes para que no se observe ningún patrón evidente, y noresulte obvia la forma resultante que tendrá el centroide tras la ejecución del algoritmo.En Fig. 5.18 se observan los centroides obtenidos tras ejecutar cuatro veces el algoritmo

79

AG-segments. Estos centroides presentan formas muy similares, quedando así patente laconsistencia del algoritmo implementado, aún en un conjunto de datos tan caótico como elmostrado.

5.6.2 NC con DTWNC es un algoritmo de aprendizaje supervisado utilizado principalmente como clasificador.

Supone una variante del algoritmo KNN, en la que en lugar de clasificar un nuevo elementoconstruyendo una matriz de distancias y asignándole la clase mayoritaria de su vecindario,se clasifica atendiendo solo a las distancias respecto a los centroides de las clases. Por ello,es importante obtener buenos representantes de las diferentes clases para lograr buenos re-sultados.

Algoritmo

El algoritmo implementado integra la distancia DTW en él sustituyendo a la distanciaEuclídea. El uso de una distancia elástica, como es DTW, en el cálculo del centroide de lasclases, y en el posterior proceso de medir cada serie a clasificar respecto a los centroides,supone un factor diferencial en bastantes conjuntos de datos de naturaleza temporal. Estose debe principalmente a su habilidad para adaptar las formas de algunas deformacionesde las series en el tiempo cuando se mide la distancia, como ya se explicó en seccionesanteriores.

Además, se opta por implementar la variante NC del algoritmo KNN porque su complejidades mucho menor en el caso de que se utilice una distancia pseudométrica que no cumpla lainecuación del triángulo, el cúal es el caso de DTW. Así, el número de cálculos necesariopara clasificar una serie se ve reducido de n2/2 en el caso del algoritmo KNN, a n ·k con NC,donde n es el número de series del conjunto de entrenamiento y k el número de clases.

El algoritmo NC implementado que utiliza la distancia DTW en lugar de la distancia Eu-clidea para entrenar y clasificar nuevos individuos es el siguiente:

1. Se calcula el centroide de cada clase utilizando el algoritmo AG-segments.2. Para cada serie a clasificar:

2.1. Se mide la distancia DTW respecto a cada centroide.2.2. Se asigna la clase del centroide más cercano.

3. Devuelve los resultados de la clasificación.

Clasificación difusa

La clasificación de las series realizada mediante este algoritmo es rígida, es decir, solo seindica la clase a la que pertenece, y no un grado de creencia en la pertenencia a una claseu otra. Para realizar una clasificación difusa se introduce en el algoritmo NC anterior unavariación para indicar la pertenencia de cada serie clasificada a cada clase.

80

El grado de pertenencia de una serie si a una clase c se calcula mediante Eq. 5.11, dondei es el índice de la serie a clasificar, c la clase de la que se calcula el grado de pertenencia yk el número de clases.

Gpi,c = 1− DTW (si, Cc)∑kj=1DTW (si, Cj)

) (5.11)

Con el fin de que la suma de los k grados de pertenencia de una serie a las k clases sumeuno, se escalan como se muestra en Eq. 5.12.

Gpei,c =Gpi,c∑kj=1Gpi,j

(5.12)

Así, el grado de pertenencia indica la creencia en que una serie pertenece a cada clase, yla suma de las creencias a todas las clases es uno. De esta forma, el algoritmo facilita másinformación acerca de la clasificación, que puede ser útil en aquellos caso en los que seanecesario un alto grado de seguridad en la clasificación para la toma de alguna decisión.

Resultados experimentales

En este apartado se exponen una serie de experimentos realizados con el algoritmo NC.Los conjuntos de datos seleccionados del Archivo UCR corresponden a aquellos en los quecada una de sus clases tiene al menos 50 series, con el fin de poder utilizar el algoritmo AG-segments con la evaluación con subconjuntos. También se han descartado aquellos conjuntoscuyas series tienen una longitud mayor de 500, con el fin de que las ejecuciones de COMASA

se pudieran llevar a cabo. Siguiendo este criterio, los datos seleccionados se muestran enCuadro 5.8.

En Cuadro 5.9 se muestran una comparación de los errores de las clasificaciones de NC,utilizando para el cálculo del centroide el algoritmo COMASA Y AG-segments. También sehan realizado las clasificaciones utilizando la distancia Euclídea.

Los errores de las clasificaciones, utilizando una distancia no elástica, como la Euclídea,son en la mayoría de los casos superiores a los que se obtienen utilizando una distancia elás-tica. También se observa que los errores en la clasificiación obtenidos cuando se calculan loscentroides con el algoritmo AG-segments son inferiores a los que se obtienen con COMASA,debiendose principalmente a que los centroides obtenidos son más precisos en la mayoría delos casos. Una nota importante es que el cálculo de los centroides con COMASA ha supuestoun coste temporal de aproximadamente 10 veces el de AG-segments.

81

Nombre Clases Entrenamiento Test Longitud

Strawberry 2 370 613 235ChlorineConcentration 3 467 3840 166PhalangesOutlinesCorrect 2 1800 858 80DistalPhalanxOutlineCorrect 2 276 600 80uWaveGestureLibrary-X 8 896 3582 315uWaveGestureLibrary-Y 8 896 3582 315uWaveGestureLibrary-Z 8 896 3582 315Ham 2 109 105 431wafer 2 1000 6174 152Two-Patterns 4 1000 4000 128ProximalPhalanxOutlineCorrect 2 600 291 80ProximalPhalanxOutlineAgeGroup 3 400 205 80yoga 2 300 3000 426MiddlePhalanxOutlineCorrect 2 291 600 80

Cuadro 5.8: Experimentos NC: Comparación de tasas de errores

Datos COMASA AG-segments Euclídea

Strawberry 0,393 0,377 0,331ChlorineConcentration 0,645 0,719 0,672PhalangesOutlinesCorrect 0,427 0,338 0,369DistalPhalanxOutlineCorrect 0,393 0,519 0,527uWaveGestureLibrary-X 0,326 0,303 0,369uWaveGestureLibrary-Y 0,447 0,423 0,450uWaveGestureLibrary-Z 0,389 0,386 0,462Ham 0,278 0,298 0,230wafer 0,313 0,279 0,345Two-Patterns 0,038 0,007 0,536ProximalPhalanxOutlineCorrect 0,279 0,372 0,355ProximalPhalanxOutlineAgeGroup 0,225 0,191 0,181yoga 0,453 0,430 0,513MiddlePhalanxOutlineCorrect 0,442 0,524 0,450

Cuadro 5.9: Experimentos NC: Experimentos con NC

5.7 Sprint 6: Desarrollo de un servidor REST

Una vez implementados todos los algoritmos evolutivos y los algoritmos de aprendiza-je que hacen uso de ellos, se desarrolla un servidor que presenta una arquitectura de tipoREpresentational State Transfer (REST). Este servidor aceptará peticiones Hypertext Trans-fer Protocol (HTTP), a través de las cuales un usuario podrá solicitar la aplicación de losalgoritmos sobre un conjunto de series temporales. A continuación se describen las cuatroetapas que se han seguido en el desarrollo del servidor: diseño, implemetación, pruebas ydespliegue.

82

5.7.1 API REST: DiseñoCada operación definida en la API REST recibe un JavaScript Object Notation (JSON) que

contiene el conjunto de series temporales y una serie de parámetros para los algoritmos. LaAPI diseñada contiene la siguiente estructura de recursos:

/centroide

• /simple

• /coop

/kmeans

• /simple

• /coop

/nmean

• /simple

◦ /crisp◦ /fuzzy

/nmean

• /coop

◦ /crisp◦ /fuzzy

Cada uno de ellos acepta peticiones HTTP POST. Las dos primeras Uniform ResourceIdentifier (URI) corresponden a los algoritmos de la obtención del centroide de un conjuntode series temporales utilizando el algoritmo genético AG-segments simple y cooperativo. Elformato JSON que aceptan las operaciones definidas en estas URIs son presentan el siguienteformato:

“series”: Lista de series.

“pop-size”: Número entero que indica el tamaño de la población.

“ngen”: Número entero que indica el número de generaciones.

“nespecies”: Número entero que indica el número de especies.

“ngen-intercambio”: Número entero que indica cada cuantas generaciones se realizaráel intercambio de los representantes.

“cxpb”: Número real que indica la probabilidad de cruce.

“mutpb”: Número real que indica la probabiliadd de mutación.

“batch-avaluate”: Boolean que indica si se calcula el fitness con subconjuntos o no.

“batch-size”: Número real que indica la proporción del conjunto de series sobre la quese calcula el fitness.

83

Las dos siguientes URIs corresponden al algoritmo K-Means utilizando el algoritmo ge-nético simple y cooperativo. El formato que tienen los JSON aceptados por las operacionesPOST definidas sobre estos recursos es el siguiente:

“series”: Conjunto de series temporales.

“k”: Número de grupos en los que particionar el conjunto de series temporales.

“n-init”: Número de veces que se ejecutará el algoritmo K-Means con inicializacionesdistintas de los centroides.

“max-it”: Número de iteraciones del algotimo K-Means.

“params-ag”: Un JSON con el mismo formato que el aceptado por los endpoints delcálculo del centroide.

Los cuatro endpoints restantes corresponden al algoritmo NC con las variantes de calcularlos centroides mediante el algoritmo AG-segments cooperativo o simple y realizar clasifica-ciones rígidas o difusas. En estos endpoints el algoritmo NC tan solo realizará clasificacionesy no el cálculo de los centroides. Esta decisión de diseño se debe a que el servicio de cálculode los centroides ya está ofrecido en otros endpoints de la API. Por tanto si el usuario deseaobtener los centroides de unas clases y después clasificar un conjunto de series, en primerlugar deberá utilizar los endpoints relativos al cálculo del centroide y posteriormente algunode los cuatro endpoints correspondientes al algoritmo NC. El formato del JSON aceptado enestos endpoints es el siguiente:

“centroides”: Lista con los centroides de cada clase.

“params-ag”: Un JSON con el mismo formato que el aceptado por los endpoints delcálculo del centroide.

5.7.2 API REST: ImplementaciónPara la implementación de la API REST se ha utilizado el micro-framework Flask. Es-

ta librería facilita la implementación de servicios web mediante Python. A continuación semuestra el ejemplo básico de aplicación Flask. Después se explicarán los detalles más im-portantes de la implementación del servidor.

En Listado 5.2 se muestra el ejemplo básico de aplicación en Flask. La línea 1 correspondea la importación de la clase principal de Flask. Y en la línea 2 se crea una aplicación Flask.La línea 4 de código es una de la más importante, ya que representa la forma en la que setrabaja con esta librería. Es un decorador que asocia a la URI «/», cuando se realiza sobreella una petición HTTP de tipo GET, la función hello. La línea 9 ejecuta la aplicación conuna llamada a la función «run». En este caso la aplicación se ejecutará en localhost y en elpuerto 5000.

1 from flask import Flask

2 app = Flask(__name__)

84

4 @app.route("/", methods=[’GET’])

5 def hello():

6 return "Hello World!"

8 if __name__ == "__main__":

9 app.run(host=’127.0.0.1’, port=5000)

Listado 5.2: «Hello world» con Flask

Para desplegar la aplicación, basta con ejecutar el siguiente comando. Después se podrá ac-ceder a la dirección 127.0.0.1 desde un navegador y aparecerá el mensaje «Hello World!».python ./hello.py

La implementación del servidor que permite el acceso a los algoritmos vía peticionesHTTP es más compleja pero sigue el mismo esquema. Se implementan una serie de funcionesque dan acceso a los algoritmos, decorándolas con la URI desde la que se accede a ellos ycon las operaciones definidas sobre esas URI.

Una buena práctica durante el desarrollo de aplicaciones en Flask es mantener la opción deconfiguración DEBUG con un valor True, tal y como se muestra en el Listado 5.3. Esta op-ción activada facilita la depuración de la aplicación actualizando los cambios dinámicamentesin tener que parar y volver a desplegar la aplicación.

1 app.config[’DEBUG’] = True

Listado 5.3: Opción de depuración

Otra buena práctica, en este caso para manejar los errores HTTP adecuandamente y man-tener un código más limpio en los endpoints, es el definir unos manejadores de errores pordefecto. En el Listado 5.4 se muestran los manejadores definidos en el servidor. Para defi-nir un manejador de error, se debe decorar la función con la que se desea realizar la acciónapropiada cuando se produzca el error con un decorador como el de la línea 1, indicando elnúmero de error HTTP para el que será utilizada dicha función. En este caso se han implemen-tado manejadores para los errores HTTP 400, 404 y 405, que corresponden, respectivamente,a los errores de una petición recibida con un formato incorrecto, una petición a una URI queno está difinida y una petición con una operación que no está definida en el endpoint al quese realiza.

En la sentencia «return» de cada una de las funciones que definen los manejadores se ob-serva el uso de dos funciones, make-response y jsonify. La primera de ellas es utilizada paraconstruir respuestas HTTP fácilmente. En estos casos se crean respuestas indicando el códigode error HTTP. El contenido de estas respuestas se obtiene utilizando la funcion jsonify. Estáfunción facilita el uso de JSON en las respuestas, convirtiendo mutliples argumentos en un

85

array o múltiples argumentos con un nombre asociado en un diccionario dentro del JSON.

1 @app.errorhandler(400)

2 def bad_request(error):

3 return make_response(jsonify({’Error’:’Bad Request’}), 400)


6 def not_found(error):

7 return make_response(jsonify({’error’:’Not Found’}), 404)


10 def not_found(error):

11 return make_response(jsonify({’error’:’Method Not Allowed’}), 405)

Listado 5.4: Manejadores de errores

En el Listado 5.5 se muestra un endpoint del servidor implementado correspondiente alcálculo del centroide mediante una estrategia no cooperativa. La URI «/centroide/simple»tiene asociada la función ag_segments_simple cuando se realiza sobre ella una peteción HTTP

POST. A lo largo de todo el código se observa el uso del objeto request. En este objetoglobal, Flask parsea la petición entrante para que se pueda acceder a los distintos datos quelas conforman. El objeto request, en caso de que la petición recibida contenga una cabeceraContent-Type=application/json, contiene un atributo JSON. Y en él se encuentra el JSON

contenido en la petición.

En la línea 3, se comprueba si la petición contiene un JSON y, en caso de tenertlo, si tieneun atributo llamado series. Si alguna de estas condiciones no se cumple, se lanza un error depetición con formato incorrecto, que será tratado por el manejador de errores correspondien-te. En la línea 5 se obtiene el conjunto de series temporales de las que se quiere calcular elcentroide, contenido en el JSON. En la línea 6 se realia una llamada a otra función que extraelos diferentes parametros del algoritmo genético del JSON. En la línea 8 se realiza el cálculodel centroide y en la línea 9 se devuelve una respuesta HTTP cuyo contenido es un JSON condos atributos, el centroide del conjunto de series y su fitness. El código de la respuesta es el200, que es el estándar para peticiones correctas.

1 @app.route(’/centroide/simple’, methods=[’POST’])

2 def ag_segments_simple():

3 if not request.json or not ’series’ in request.json:

4 abort(400)

5 series = request.json[’series’]

6 params = get_params_ag(request.json)

7 AG = AG_segments(**params)

8 C, fitness_mejor, log = AG.calculate_centroids(series)

9 return make_response(jsonify({’centroide’:C, ’fitness’:fitness_mejor}), 200)

Listado 5.5: Ejemplo de endpoints en el servidor

86

Para desplegar la aplicación y que sea accesible desde el exterior, no se puede iniciar en laIP 127.0.0.1, o localhost, como se mostró anteriormente. En este caso se despliega en 0.0.0.0que es la IP que indica que la aplicación estará a la escucha en todas las interfaces de reddisponibles.

1 if __name__ == "__main__":

2 app.run(host=’0.0.0.0’, port=5000)

Listado 5.6: Despliegue de la aplicación Flask

5.7.3 API REST: Pruebas

La realización de pruebas para comprobar el correcto funcionamiento de cada endpoint esimportante. Además, este tipo de pruebas cobran especial valor cuando se utiliza una meto-dología ágil, en la es necesario asegurar el funcionamiento correcto del código implementadoantes de poder pasar a realizar otras tareas.

Las pruebas realizadas consisten en una serie de peticiones HTTP sobre cada endpointimplementado. En Listado 5.7 se muestra un ejemplo de una prueba unitaria del enpointque calcula el centroide de un conjunto de series con el algoritmo AG-segments simple. Enlas líenas 2 y 3 se importan dos librerías que permiten realizar peticiones HTTP y trabajarfácilmente con JSON respectivamente. En la línea 6 se se crea la cabecera que será añadidaa las peticiones. La función connect que aparece en la línea 9 realiza una conexión con elservidor. En este caso, al estar el servidor desplegado localmente, se realiza la conexión alpuerto 5000 en la dirección localhost. En la línea 13 se implementa el caso de prueba querealiza una petición al endpoint «/centroide/simple». En caso de que el estado HTTP devueltopor el servidor sea el 200, que indica que la petición fue satisfecha correctamente, el caso deprueba habrá finalizado con éxito.

1 import unittest

2 import httplib

3 import json

4 from read_series import read_series

6 headers = {’Content-type’:’application/json’}

7 series = read_series(’./test_data/45_series.csv’)

9 def connect():

10 return httplib.HTTPConnection(’localhost:5000’)

12 class TestBackend(unittest.TestCase):

13 def test_centroide_simple(self):

14 data = {’pop_size’:20,

15 ’ngen’:10,

16 ’cxpb’:0.2,

87

17 ’mutpb’:0.1,

18 ’batch_evaluate’:False,

19 ’series’:series

20 }

21 data = json.dumps(data)

22 con = connect()

23 con.request(’POST’, ’/centroide/simple’, data, headers)

24 response = con.getresponse()

25 resp = json.load(response)

26 self.assertTrue(response.status == 200)

Listado 5.7: Ejemplo de prueba de un endpoint

Tras corregir varios errores y obtener una ejecución correcta de todos los casos de prueba,el servidor ya está listo para ser desplegado en la nube.

5.7.4 Despliegue en BluemixUna vez implementado el servidor, éste es desplegado en Bluemix, un entorno de platafor-

ma como servicio desarrollado por IBM. La decisión de utilizar Bluemix y no otro servicioen la nube como App Engine de Google, se basa en que Bluemix ofrece una serie de con-tenedores modelo de aplicaciones entre los que se encuentra Flask. Un contenedor modeloconsiste en una aplicación mínima desplegada que contiene los requistos esenciales para quefuncione.

Bluemix también ofrece una cadena de herramientas integrada, que da soporte al desa-rrollo y despliegue de las aplicaciones. Integra un repositorio Git con el que se mantienesincronizada la aplicación y un IDE de Eclipse. En Fig. 5.19 se muestra la cadena de herra-mientas utilizada en la aplicación. La herramienta Issues se utiliza para notificar problemaso errores, y la herramienta Delivery Pipeline para observar el historial de despliegues de laaplicación y poder añadir etapas en las que se indique qué futuras tareas hay que realizar.

Para desplegar el servidor implementado en Bluemix, se deben crear tres ficheros: requi-rements.txt, manifest.yaml y Procfile. En ellos se indican diferentes aspectos necesarios parael correcto despliegue del servidor.

requirements.txt: En este fichero se indican que paquetes se tienen que instalar antesde que la aplicación sea desplegada. En Listado 5.8 se muestra el contenido de estearchivo. Para esta aplicación es necesario instalar Flask, la librería utilizada para laimplementación de los algoritmos genéticos DEAP y algunas librerías relacionadascon el análisis de datos.

1 Flask==0.10.1

2 deap

3 pandas

4 numpy

88

Figura 5.19: Cadena de herramientas

5 scikit-learn

Listado 5.8: Fichero requirements.txt

manifest.yaml: Las aplicaciones pueden ser desplegadas sin proveer un manifiesto.Sin embargo, hay varias ventajas en utilizarlo, como la consistencia y reproducibilidaddel despliegue, proporcionando portabilidad entre diferentes entornos en la nube. Elfichero manifest.yaml utilizado se muestra en Listado 5.9. En él se da una descripciónsobre la aplicación, como la cantidad de memoria a utilizar, el nombre de la aplicacióny del host, etc.

1 applications:

2 - path: .

3 memory: 128M

4 instances: 1

5 domain: mybluemix.net

6 name: backend-ag

7 host: backend-ag

8 disk_quota: 1024M

9 buildpack: python_buildpack

Listado 5.9: Fichero manifest.yaml

Procfile: Este fichero contiene detalles que son necesarios para que Bluemix puedaejecutar la aplicación. Más concretamente, este fichero es un artefacto que define eltipo de proceso en el que consiste la aplicación y el comando necesario para ejecutarla.En Listado 5.10 se muesrta el fichero utilizado para el servidor implementado. Seindica que es una aplicación web y el comando necesario para ejecutarla.

89

1 web: python backend.py

Listado 5.10: Fichero Procfile

5.8 Sprint 7: Diseño e implementación de un cliente web

Con el fin de mostrar el proceso evolutivo de la población a lo largo de la ejecución delalgoritmo genético AG-segments y poner de manifiesto la relevancia de éste, se ha imple-mentado un cliente web. En primer lugar se mostrará el prototipo inicial creado con BalsamiqMockups. Después se muestra el resultado de la implemtanción con una explicación de losdetalles más importantes.

5.8.1 Cliente web: Prototipo inicial

El protipo inicial se muestra en Fig. 5.20. En él se muestra la idea inicial que se pretendíaplasmar en el cliente web, con una interfaz en la que se hace especial hincapié en mostrartodos los procesos que están involucrados en la evolución.

El cuadro situado en la parte izquierda superior es en el que se deben mostrar las opera-ciones de mutación, indicando de alguna forma llamativa aquellas partes del individuo quehan sido modificadas. El cuadro que se muestra partido en tres es en el que se muestran losindividuos que se cruzan, en los dos cuadros pequeños, y en el grande aparecen los hijos delos individuos cruzados.

El cuadro grande y principal de la interfaz es el que contiene la población de todos losindividuos, o una selección de estos en caso de que hubiera demasiados para favorecer laclaridad. A la derecha de aparece un cuadro de texto en el que se muestran estadísticos ycaracterísticas de la población y la generación actual, además de algunas otras relacionadascon los mejores individuos obtenidos. Debajo de este cuadro se muestra el mejor indivi-duo obtenido hasta el momento, el que sería el candidato a centroide del conjunto de seriestemporales.

Este prototipo resume las ideas esenciales que se querían plasmar en el cliente web, sinembargo varias de ellas han sido modificadas y se han añadido varios detalles en la posteriorimplementación.

5.8.2 Cliente web: Versión final

La versión final del cliente web se muestra en Fig. 5.21. A primera vista el lector po-drá observar las modificaciones principales respecto al prototipo inicial. A continuación sedetallarán uno a uno los componentes de la interfaz.

90

Figura 5.20: Protipo inicial de la interfaz del cliente web

Gráfico de mutaciones

En cada generación se muestra una sola mutación para favorecer la claridad, ya que encaso de mostrarse todas las mutaciones producidas en cada generación, éstas permaneceríanmuy poco tiempo en el gráfico y sería deficil seguir el curso de la evolución. Cuando en unageneración se realizan varias operaciones de mutación, se selecciona una aleatoriamente paraser mostrada en la interfaz. También puede ocurrir el caso contrario, que no se produzca nin-guna mutación en una generación. En ese caso, se mantiene en el gráfico la última mutaciónmostrada. En Fig. 5.22, se muestran los tres tipos de mutación en el cliente web.

Gráfico de cruces

Al igual que ocurre con las mutaciones, en cada generación también se muestra una ope-ración de cruce. Como ya se explicó anteriormente, una operación de cruce se produce entredos individuos para dar como resultado otros dos individuos, resultado de la combinaciónde los dos primeros. De la misma forma que con las operaciones de mutación, tan solo semuestra una operación de cruce, o bien seleccionada aleatoriamente entre las producidas enla generación o, en caso de que no se haya producido ninguna, se conserva en el gráfico elúltimo cruce mostrado. Para favorecer la claridad del gráfico, se muestran los dos individuosprogenetores en tonos azulados, y tan solo uno de los hijos en un tono rojo. En Fig. 5.23 semuestra un ejemplo del gráfico de cruce.

Gráfico de población

En este gráfico se muestra el estado actual de la población en el proceso evolutivo. Labarra que se encuentra debajo se activa cuando ha concluido la ejecución del algoritmo. Aldesplazarla, permite observar el estado de la población en cada generación, de forma que el

91

Figura5.21:C

lientew

eb:Interfazcom

pleta

92

(a) Mutación: estrechamiento/ensanchamiento (b) Mutación: subida/bajada de zona

(c) Mutación: radical

Figura 5.22: Cliente web: Ejemplos de mutación

Figura 5.23: Cliente web: Ejemplo de cruce

usuario observa la tendencia evolutiva que han seguido los individuos de la población a lolargo de las generaciones. Tambíen al desplazar la barra se mostrarán la mutación, cruce ycentroide obtenidos en las diferentes generaciones.

Tablas de descripción de la evolución

Las dos tablas en las que muestra la descripción se observan en Fig. 5.24. En la primera deellas, la situada en la parte superior, se da una descripción general del estado de la poblaciónen la generación actual, indicando el número de la generación, y los fitness medio, máximo

93

y mínimo.

En la tabla inferior se mantiene un ranking de los mejores individuos obtenidos hasta elmomento actual. Indicando de ellos su fitness y la generación en la que fueron obtenidos.

Figura 5.24: Cliente web: Tablas de descripción

Centroide, evolución y parámetros

En la parte derecha e inferior de la interfaz aparece una estructura de tres pestañas, quecontiene el gráfico del centroide, un gráfico en el que se observa la disminución del fitnessen cada generación y una ventana para introducir algunos parámetros. En Fig. 5.25 se mustrael contenido de cada una de estas pestañas.

En la primera pestaña aparece el mejor individuo obtenido hasta el momento, cuyo fitnesscorresponde al que aparece en el puesto número uno del ranking de la tabla situada en laparte superior.

En la seguna pestaña se muestra una gráfica en la que el usuario puede observar la dismi-nución del fitness del mejor individuo a lo largo de las generaciones. De esta forma se puedeobservar fácilmente la relevancia del proceso de evolución realizado por el algoritmo.

En la última pestaña se le da la posibilidad al usuario de indicar los parámetros más impor-tantes del algoritmo genético. Estos son el número de individuos, el número de generaciones,la probabilidad de cruce y la probabilidad de mutación.

Acciones del usuario

El usuario puede pausar la ejecución del algoritmo cuando quiera pulsando el botón rojocon el símbolo de stop. Al igual, puede resetear la ejecución del algoritmo. Una vez finalizadao parada la ejecución del algoritmo, se activa el botón de «descargar centroide». Pulsándo-lo el usuario podrá descargar el mejor individuo obtenido hasta el momento en un ficheroCSV.

94

(a) Pestaña centroide (b) Pestaña evolución

(c) Pestaña parámetros

Figura 5.25: Cliente web: Pestañas

5.8.3 Comunicación con el servidor y arquitectura

Debido a que el servidor implementado presenta una arquitectura REST y una de sus ca-racterístcas principales, tal y como se ha explicado anteriormente, es que no mantiene unestado interno, es necesario definir una estrategia de comunicación para lograr ejecutar pasoa paso el algoritmo genético.

El cliente web recibirá por parte del usuario las series de las que se quiere calcular elcentroide. El cliente web enviará al servior el estado en el que se encuentra la evolución, juntocon una serie de parámetros, todo ello en formato JSON, y el servior calculará el siguienteestado y lo enviará de vuelta al cliente. Así, resulta necesario definir que datos constituyenel estado que será enviado al servidor y que forma tendrá la respuesta devuelta por éste.

Formato de los JSON

El estado enviado por el cliente está formado por la población en la generación actual enla que se encuentra. Junto con el estado, resulta necesario enviar al servidor los parámetrosgenerales del proceso evolutivo, definidos por el usuario, y el conjunto de series de las quese quiere calcular el centroide. Se recuerda al lector, que para calcular el fitness, se sumanlas distancias de un individuo a las series del conjunto del que se calcula el representante.Así, resulta necesario enviar el conjunto de series junto con el estado para que pueda sercalculada la siguiente genaración. El formato del JSON que es enviado al servidor se detallaa continuación:

“series”: Lista de series introducido por el usuario.

95

“poblacion”: Lista de individuos.

“cxpb”: Número real comprendido entre 0 y 1 que indica la probabilidad de cruce.

“mutpb”: Número real comprendido entre 0 y 1 que indica la probabilidad de muta-ción.

La resupuesta devuelta por el servidor está formada por la población, el fitness de cadaindividuo de la población, las mutaciones y cruces realizados, y una serie de datos acerca dela generación. El formato del JSON devuelto por el servidor es el siguiente:

“mutantes”: Lista de individuos resultantes de aplicar el operador de mutación durantela generación.

“no-mutantes”: Lista de individuos a los que se les ha aplicado el operador de muta-ción.

“progenitores”: Lista de individuos sobre los que se ha aplicado el operador de cruce.Están ordenados, es decir, los individuos situados en las posiciones primera y segundaconstituyen una pareja que ha dado lugar a dos hijos. Lo mismo ocurre con los situadosen la tercera y cuarta posición, quinta y sexta, etc.

“hijos”: Lista de individuos resultantes del operador de cruce. Presentan el mismoorden que la lista de progenitores.

“poblacion”: Lista de los individuos que conforman la población.

“fitness”: Lista de números reales que indican el fitness de los individuos de la pobla-ción. El primer número contenido en esta lista constituye el fitness del primer individuocontenido en la lista de la población.

“media-fitness”: Número real que indica el fitness medio de la población.

“min-fitness”: Número real que indica el fitness mínimo de la población.

“max-fitness”: Número real que indica el fitness máximo de la población.

“mejor”: Mejor individuo de la población.

Arquitectura

La arquitectura diseñada se muestra en Fig. 5.26. A continuación se detalla el proceso decomunicación que tiene lugar entre el cliente y el servidor.

Para realizar la primera comunicación entre el cliente y el servidor, es necesario que elcliente defina la población inicial del proceso evolutivo. Ésta será determinada como unaselección aleatoria de las series del conjunto introducido por el usuario. Una vez determinadala población inicial, se construye el JSON y es enviado al servidor.

Como se ya se explicó anteriormente, para que el algoritmo genético implementado fun-cione correctamente, es necesario normalizar las series de las cuáles se quiere calcular el

96

Figura 5.26: Cliente web: Arquitectura

centroide. Así, en primer lugar, el servidor normaliza el conjunto de series, guardando lamedia y la desviación típica para la posterior desnormalización. La población también esnormalizada con la media y la desviación típica del conjunto de series.

Una vez normalizadas las series y la población, se ejecuta el algoritmo genético AG-segments, con los parámetros recibidos, realizando tan solo una generación. El algortimoAG-segments es adaptado para almacenar los individuos que se mutan y los resultados deesas mutaciones, así como los individuos cruzados y los hijos generados. De esta manera seobtiene el siguiente paso de la evolución y su información relacionada.

La población obtenida se desnormaliza para que recupere su escala inicial, que es aquellacon la que se muestran los individuos en el cliente web. Una vez desnormalizada, se crea elJSON con toda la información de la nueva generación y es enviado al cliente web.

97

Capítulo 6

Conclusiones

En esta sección se exponen las conlusiones obtenidas tras la finalización del proyecto. Enprimer lugar, se analiza la consecución de los objetivos planteados al principio del mismo y,después, las competencias obtenidas. Por último, se detallan las posibles mejoras y trabajosfuturos.

6.1 Análisis de consecución de objetivosEl objetivo principal del proyecto se ha logrado con éxito. Se ha implementado un algo-

ritmo capaz de obtener un centroide de un conjunto de series temporales utilizando comomedida de distancia DTW. Además, el algoritmo implementado es escalable a grandes con-juntos de series, logrando obtener representantes más precisos en un tiempo menor que elresto de métodos hallados en la literatura.

Por otro lado, el algoritmo implementado ha sido integrado en otros algoritmos de apren-dizaje automático, tanto de agrupamiento como de clasificación, obteniendo en ambos casosresultados satisfactorios. Destaca el caso de la clasificación de series temporales utilizandoel algoritmo NC con el algoritmo genético implementado integrado en él, cuyos resultadosson mucho mejores que si se utilizará la distancia Euclídea.

Los objetivos específicos también se han conseguido de forma exitosa. El primero de ellos,relacionado con el uso de un método evolutivo para la obtención del centroide de un conjuntode series temporales ha sido satisfecho. La hipótesis de que un algoritmo genético era laestrategia correcta para obtener una buena estimación de un representante de un conjunto deseries resultó acertada.

El segundo objetivo específico también ha sido satisfecho. Se ha integrado correctamenteel algoritmo genético en otros algoritmos de aprendizaje automático, mejorando los resulta-dos que se obtienen utilizando un distancia rígida como la Euclidea.

Los tercer y cuarto objetivos específicos también se han conseguido. Se ha desarrolladoun servidor REST que ofrece como servicio todos los algoritmos implementados y ha sidodesplegado en Bluemix. Este servidor sirve como backend de un cliente web que ofrece alusuario una forma interactiva de obsrevar la evolución de la población de centroides en eltranscurso de las generaciones.

99

En definitiva, todos los objetivos propuestos han sido conseguidos, destacando los buenosresultados en el objetivo principal del proyecto.

6.2 CompetenciasLas principales competencias demostradas en desarrollo del proyecto son las siguien-

tes:

«Capacidad para tener un conocimiento profundo de los principios fundamentales ymodelos de la computación y saberlos aplicar para interpretar, seleccionar, valorar,modelar, y crear nuevos conceptos, teorías, usos y desarrollos tecnológicos relaciona-dos con la informática».

«Capacidad para evaluar la complejidad computacional de un problema, conocer es-trategias algorítmicas que puedan conducir a su resolución y recomendar, desarrollar eimplementar aquella que garantice el mejor rendimiento de acuerdo con los requisitosestablecidos».

«Capacidad para conocer los fundamentos, paradigmas y técnicas propias de los sis-temas inteligentes y analizar, diseñar y construir sistemas, servicios y aplicacionesinformáticas que utilicen dichas técnicas en cualquier ámbito de aplicación».

6.3 Trabajos futurosAunque el algoritmo implementado obtiene buenos resultados, todavía hay un margen de

mejora. A continuación se exponen una serie de posibles mejoras:

Aunque se ha implementado una versión de algoritmo genético utilizando una estra-tegia cooperativa, se puede seguir explorando nuevas posibilidades en este área. Porejemplo, diseñar algún criterio en el que cuando una especie deja de contribuir conbuenos individuos, se elimina, sustituyéndola por otra nueva.

En los operadores de mutación y cruce implementados se tienen que realizar interpo-laciones para mantener todas las series con la misma longitud. Para ello se ha utilizadoel método más sencillo: interpolación lineal. Sin embargo, otros tipos de interpolaciónpodrían conservar la estructura de las series de una forma más precisa, consiguiendoasí, seguramente, mejores resultados.

La distancia DTW, aunque muy útil para medir la distancia entre series similares quepresentan cierto tipo de desplazamientos, estrechamientos o ensanchamientos, puedecaer en cierto tipo de comportamientos poco deseables tal y como se detallo en sec-ciones anteriores. Además su complejidad resulta un factor a considerar cuando lalongitud de las series es grande. Por ello, puede resultar interesante permitir acotarel espacio de búsqueda en los alinemientos mediante alguna variante de DTW de lasdescritas en el Capítulo 3.

100

ANEXOS

101

Anexo A

Historias de usuario

Las historias de usuario implementadas a lo largo del proyecto son las siguientes:

Investigación del entorno DEAP

Número: 1 Prioridad: MediaRiesgo en desarrollo: Bajo Iteración asignada: 1Programador responsable: Pablo León Estimación temporal: 6 horasDescripción: Se investiga el entorno de desarrollo para el prototipado de algoritmosevolutivos DEAP y se estudiará su posible uso en el proyecto. Se debe implementarun problema básico.Validación: Se habrá completado la historia de usuario cuando el ejemplo implemen-tado funcione correctamente.

Cuadro A.1: Historia de usuario: Investigación sobre DEAP

Búsqueda de datos de naturaleza temporalNúmero: 2 Prioridad: MediaRiesgo en desarrollo: Medio Iteración asignada: 1Programador responsable: Pablo León Estimación temporal: 5 horasDescripción: Se deben buscar distintos conjuntos de datos de series temporales. Esimportante que estén etiquetadas de forma que sea posible clasificarlasValidación: La tarea habrá finalizado cuando se hayan obtenido al menos diez con-juntos de series temporales.

Cuadro A.2: Historia de usuario: Búsqueda de datos de naturaleza temporal

Estudio e implementación de soluciones existentesNúmero: 3 Prioridad: MediaRiesgo en desarrollo: Medio Iteración asignada: 1Programador responsable: Pablo León Estimación temporal: 30 horasDescripción: Se debe buscar bibliografía sobre la obtención del centroide de un con-junto de series temporales utilizando como medida de distancia DTW o alguna otradistancia elástica. Posteriormente se implementarán las soluciones encontradas. Dehaber muchas, solo se implemetarán aquellas que parezcan más relevantes.Validación: La historia de usuario se da por concluida cuando se tenga una versiónfuncional aquellas soluciones más relevantes.

Cuadro A.3: Historia de usuario: Estudio e implementación de soluciones existentes

103

Implementación de DTW y FastDTW en lenguaje CNúmero: 4 Prioridad: AltaRiesgo en desarrollo: Bajo Iteración asignada: 1Programador responsable: Pablo León Estimación temporal: 5 horasDescripción: Se deben implementar los algorimos DTW y FastDTW en lenguaje Cpara mejorar su rendimiento.Validación: La tarea se da por finalizada cuando los resultados, tanto la distanciacomo el alineamiento entre dos series proporcionado por ambas implementacionessea exactamente el mismo que el resultante de sus respectivas versiones en Python.

Cuadro A.4: Historia de usuario: Investigación sobre DEAP

Experimentos con las soluciones de la literaturaNúmero: 5 Prioridad: BjaRiesgo en desarrollo: Bajo Iteración asignada: 1Programador responsable: Pablo León Estimación temporal: 3 horasDescripción: Se debe implementar una batería de pruebas para ejecutar las solucio-nes de la literatura sobre distintos conjuntos de datos en varios ocasiones y medir lainercia de los centroides obtenidos.Validación: La tarea concluye cuando se hayan ejecutado correctamente todos losexperimentos.

Cuadro A.5: Historia de usuario: Experimentos con las soluciones de la literatura

Implementación de algoritmo genético genéricoNúmero: 6 Prioridad: AltaRiesgo en desarrollo: Bajo Iteración asignada: 2Programador responsable: Pablo León Estimación temporal: 12 horasDescripción: Hay que implementar un algoritmo genético que resuelva el problemade la obtención del centroide de un conjunto de series temporales utilizando DTWcomo medida de distancia de manera genérica. Para ello se han de utilizar operadoresgenéricos, sin prestar demasiada atención al dominio del problema que se pretenderesolver.Validación: La historia de usuario se da por finalizada cuando el algoritmo genéticofuncione correctamente y se obtiene una optimización relevante respecto a la pobla-ción inicial.

Cuadro A.6: Historia de usuario: Implementación de algoritmo genético genérico

Experimentos con algoritmo genético genéricoNúmero: 7 Prioridad: MediaRiesgo en desarrollo: Bajo Iteración asignada: 2Programador responsable: Pablo León Estimación temporal: 3 horasDescripción: Se debe adapatar la batería de pruebas de la iteración anterior para eje-cutar el algoritmo genético genérico obtenido sobre los mismos conjuntos de datos.Así se podrán comprar los resultados obtenidos.Validación: La historia de usuario concluye cuando se hayan ejecutado las pruebasy recopilado los resultados.

Cuadro A.7: Historia de usuario: Experimentos con el algoritmo genético genérico

104

Implementación de operador de cruceNúmero: 8 Prioridad: AltaRiesgo en desarrollo: Alto Iteración asignada: 3Programador responsable: Pablo León Estimación temporal: 15 horasDescripción: Hay que idear e implementar un operador de cruce que utilice informa-ción del alineamiento de dos series temporales utilizando DTW.Validación: Se da por finalizada la historia de usuario cuando las series cruzadascumplan las siguientes características: Tienen la misma longitud que sus progenito-ras, son combinación de éstas y se observa gráficamente dicha combinación.

Cuadro A.8: Historia de usuario: Implementación de operador de cruce

Implementación de operador de mutaciónNúmero: 9 Prioridad: AltaRiesgo en desarrollo: Alto Iteración asignada: 3Programador responsable: Pablo León Estimación temporal: 15 horasDescripción: Hay que idear e implementar un operador de mutación. Las variacionesque provoque en los individuos debe ser relevante respecto a DTW.Validación: Se da por finalizada la historia de usuario cuando las series mutadaspresenten la misma longitud que las no mutadas y se observen gráficamente las mu-taciones tal y como se idearon.

Cuadro A.9: Historia de usuario: Implementación de operador de mutación

Implementación e integración de la estructura del algoritmo genéticoNúmero: 10 Prioridad: AltaRiesgo en desarrollo: Alto Iteración asignada: 3Programador responsable: Pablo León Estimación temporal: 10 horasDescripción: Se implementa la estructura del algoritmo genético y se integran en éllos operadores desarrollados.Validación: La historia de usuario habrá finalizado cuando el algoritmo genéticofuncione y se produzca una optimización relevante de la población de individuosinicial.

Cuadro A.10: Historia de usuario: Implementación e integración de algoritmo genético

Experimentos para parametrizar operadores y comparar con los algoritmos anterioresNúmero: 11 Prioridad: BajaRiesgo en desarrollo: Bajo Iteración asignada: 3Programador responsable: Pablo León Estimación temporal: 5 horasDescripción: Se adapta la batería de experimentos de las iteraciones anteriores paraparametrizar los operadores. Una vez parametrizados, se ejecuta el algoritmo sobrelos mismos conjuntos de datos de las iteraciones anteriores para comparar los resul-tados.Validación: Concluye cuando los operadores estén parametrizados y se hayan obte-nido los resultados de los experimentos.

Cuadro A.11: Historia de usuario: Parametrización y comparación de resultados

105

Implementación de algoritmo genético cooperativoNúmero: 12 Prioridad: AltaRiesgo en desarrollo: Medio Iteración asignada: 4Programador responsable: Pablo León Estimación temporal: 15 horasDescripción: Hay que adaptar el algoritmo genético obtenido en la iteración anteriora una estrategia de evolución cooperativa en la que intervengan varias poblacionesque evolucionen independientemente en la búsqueda del centroideValidación: La historia de usuario se da por finalizada cuando el algoritmo genéticofuncione correctamente y se obtiene una optimización relevante respecto a la pobla-ción inicial.

Cuadro A.12: Historia de usuario: Implementación de algoritmo genético cooperativo

Experimentos con algoritmo genético cooperativoNúmero: 13 Prioridad: BajaRiesgo en desarrollo: Bajo Iteración asignada: 4Programador responsable: Pablo León Estimación temporal: 4 horasDescripción: Se debe adapatar la batería de pruebas de las iteraciónes anterior pa-ra ejecutar el algoritmo genético cooperativo sobre los mismos conjuntos de datos,comparando los resultados obtenidos.Validación: La historia de usuario concluye cuando se hayan ejecutado las pruebasy recopilado los resultados.

Cuadro A.13: Historia de usuario: Experimentos con algoritmo genético cooperativo

Implementación de algoritmo K-Means con DTW

Número: 14 Prioridad: AltaRiesgo en desarrollo: Bajo Iteración asignada: 5Programador responsable: Pablo León Estimación temporal: 8 horasDescripción: Se debe implementar un algoritmo K-Means que utilice el algoritmogenético desarrollado en la tercera iteración en el cálculo de los centroides.Validación: Se da por finalizada la historia de usuario cuando se hayan ejecutadopruebas con diferentes conjuntos de datos.

Cuadro A.14: Historia de usuario: Implementación de algoritmo K-Means con DTW

Implementación de algorimo NC con DTW

Número: 15 Prioridad: AltaRiesgo en desarrollo: Bajo Iteración asignada: 5Programador responsable: Pablo León Estimación temporal: 8 horasDescripción: Se debe implementar el algoritmo NC. Este algoritmo calcula la mediade cada clase utilizando el algoritmo genético implementado en la tercera iteración.Validación: La historia de usuario finaliza cuando el algoritmo es capaz de clasificarseries temporales.

Cuadro A.15: Historia de usuario: Implementación de algorimo NC con DTW

106

Experimentos con algoritmo NC

Número: 16 Prioridad: BajaRiesgo en desarrollo: Bajo Iteración asignada: 5Programador responsable: Pablo León Estimación temporal: 5 horasDescripción: Se implementará una batería de pruebas mayor a la de las iteracionesanteriores. Se adapta el algoritmo NC para poder utilizar las soluciones de la litera-tura para calcular el centroide y así poder comparar los resultados con el algoritmodesarrollado en la iteración 3.Validación: La historia de usuario finaliza cuando se hayan obtenido todos los resul-tados, tanto de los algoritmos de la literatura como el del desarrollado en el proyecto

Cuadro A.16: Historia de usuario: Experimentos con algoritmo NC

Clasificaciones difusas con NC

Número: 17 Prioridad: MediaRiesgo en desarrollo: Bajo Iteración asignada: 6Programador responsable: Pablo León Estimación temporal: 3 horasDescripción: Se extiende el algoritmo NC implementado en la iteración anterior paraque pueda dar como resultado la creencia de la pertenencia a una clase u otra, enlugar de asignar una clase directamente.Validación: Se da por finalizada cuando la funcionalidad esté implementada y pro-bada.

Cuadro A.17: Historia de usuario: Clasificaciones difusas con NC

Implementación del servidor REST

Número: 18 Prioridad: AltaRiesgo en desarrollo: Medio Iteración asignada: 6Programador responsable: Pablo León Estimación temporal: 35 horasDescripción: Se debe implementar un servidor REST que preste todos los servciosdesarrollados en las iteraciones anteriores: Obtención del centroide utilizando el algo-ritmo genético simple y el cooperativo, aplicación del algoritmo K-Means utilizandoDTW como medida de distancia y clasificación mediante el algoritmo NC.Validación: Habrá concluido la historia de usuario cuando todas las funcionalidadesestén implementadas y hayan pasado los tests correspondientes.

Cuadro A.18: Historia de usuario: Implementación del servidor REST

Extensión del servidor REST para dar soporte al cliente webNúmero: 19 Prioridad: AltaRiesgo en desarrollo: Medio Iteración asignada: 7Programador responsable: Pablo León Estimación temporal: 12 horasDescripción: Se debe extender el servidor REST para que proporcione un nuevo ser-vicio que de soporte al cliente web. Esta nueva funcionalidad consiste en una funciónque aplicandose sobre una población de individuos devuelve la siguiente, junto conuna serie de estadísticos relevantes.Validación: Se da por finalizada cuando ha la nueva funcionalidad este implementaday haya pasado las pruebas.

Cuadro A.19: Historia de usuario: Extensión del servidor REST

107

Implementación del cliente webNúmero: 20 Prioridad: AltaRiesgo en desarrollo: Medio Iteración asignada: 7Programador responsable: Pablo León Estimación temporal: 40 horasDescripción: Se implementa un cliente web que permita visualizar la evolución dela población de individuos en el algoritmo genético implementado en la tercera itera-ción.Validación: Finaliza cuando el cliente web esté implementado y haya pasado laspruebas.

Cuadro A.20: Historia de usuario: Implementación del cliente web

108

Anexo B

Manual de usuario

Para calcular el centroide de un conjunto de series haciendo uso del cliente web se debenseguir los siguientes pasos:

Figura B.1: Cliente web

1. Haga clic en la pestaña «Parámetros» en la parte inferior derecha de la pantalla e indi-que el número de individuos de la población, el número de generaciones que se reali-zarán en el prceso evolutivo, la probabilidad de cruce y la probabilidad de mutación.Los intervalos recomendados son los siguientes:

Población: 20-200

Generaciones: 100-200

Probabilidad de cruce: 0.1-0.3

Probabilidad de mutación: 0.01-0.15

2. Pulse el botón «Seleccionar archivo» y escoja el fichero CSV en el que se encuen-tran las series de las que quiere calcular el centroide. Cada fila del archivo debe estarformada por una serie temporal.

109

Figura B.2: Series en archivo CSV

3. Pulse el botón verde «Play» para que comience la ejecución del algoritmo. Si todoha transcurrido correctamente se verán en los diferentes gráficos las distintas seriestemporales que componen la población y las operaciones realizadas sobre ellas.

4. Espere a que se realice el número de generaciones indicado o pulse el botón rojo «stop»para parar el proceso evolutivo.

5. Utilice la barra de desplazamiento que hay debajo del gráfico de la población paraobservar cómo ha evolucionado la población. Si lo desea, puede descargar el centroidepulsando el botón «descargar centroide».

6. Puede continuar el proceso evolutivo pulsando el botón verde «Play» o resetear laejecución pulstando el botón azul «Reset».

110

Referencias

[AB04] Cynthia Andres y Kent Beck. Extreme Programming Explained: EmbraceChange. Reading: Addison-Wesley Professional, 2004.

[BBM93a] David Beasley, David R Bull, y Ralph Robert Martin. An overview of geneticalgorithms: Part 1, fundamentals. University computing, 15(2):56–69, 1993.

[BBM93b] David Beasley, David R Bull, y Ralph Robert Martin. An overview of gene-tic algorithms: Part 2, research topics. University computing, 15(4):170–181,1993.

[BC94] Donald J Berndt y James Clifford. Using Dynamic Time Warping to FindPatterns in Time Series. En KDD workshop, number 16, páginas 359–370.Seattle, WA, 1994.

[CKH+15] Yanping Chen, Eamonn Keogh, Bing Hu, Nurjahan Begum, Anthony Bagnall,Abdullah Mueen, y Gustavo Batista. The UCR Time Series Classification Ar-chive, July 2015. www.cs.ucr.edu/~eamonn/time series data/.

[CNOT07] Yueguo Chen, Mario A Nascimento, Beng Chin Ooi, y Anthony KH Tung.Spade: On shape-based pattern detection in streaming time series. En Data En-

gineering, 2007. ICDE 2007. IEEE 23rd International Conference on, páginas786–795. IEEE, 2007.

[FDG+12] Félix-Antoine Fortin, François-Michel De Rainville, Marc-André Gardner,Marc Parizeau, y Christian Gagné. DEAP: Evolutionary Algorithms MadeEasy. Journal of Machine Learning Research, 13:2171–2175, jul 2012.

[Fow01] Martin Fowler. Is design dead? SOFTWARE DEVELOPMENT-SAN

FRANCISCO-, 9(4):42–47, 2001.

[Fu11] Tak-chung Fu. A review on time series data mining. Engineering Applications

of Artificial Intelligence, 24(1):164–181, 2011.

[GH88] David E Goldberg y John H Holland. Genetic algorithms and machine learning.Machine learning, 3(2):95–99, 1988.

111

www.cs.ucr.edu/~eamonn/time_series_data/

[GL85] DE Goldberg y R LINGLE. Alleles, loci, and the TSP. Iš Grefenstette JJ. EnProceedings of the First International Conference on Genetic Algorithms and

their Applications, páginas 154–159, 1985.

[GMTS96] Lalit Gupta, Dennis L Molfese, Ravi Tammana, y Panagiotis G Simos. Non-linear alignment and averaging for estimating the evoked potential. IEEE

Transactions on Biomedical Engineering, 43(4):348–356, 1996.

[Gol91] David Goldberg. The theory of virtual alphabets. Parallel problem solving from

nature, páginas 13–22, 1991.

[Hol92] John H Holland. Adaptation in natural and artificial systems: an introductory

analysis with applications to biology, control, and artificial intelligence. MITpress, 1992.

[Ita75] Fumitada Itakura. Minimum prediction residual principle applied to speechrecognition. IEEE Transactions on Acoustics, Speech, and Signal Processing,23(1):67–72, 1975.

[JM91] Cezary Z Janikow y Zbigniew Michalewicz. An experimental comparison ofbinary and floating point representations in genetic algorithms. En ICGA, pá-ginas 31–36, 1991.

[KE09] Leonidas Karamitopoulos y Georgios Evangelidis. A dispersion-based paa re-presentation for time series. En Computer Science and Information Enginee-

ring, 2009 WRI World Congress on, volume 4, páginas 490–494. IEEE, 2009.

[Kni07] Henrik Kniberg. Scrum y XP desde las trincheras. C4Media Inc. InfoQ, 2007.

[KP01] Eamonn J Keogh y Michael J Pazzani. Derivative Dynamic Time Warping. EnSdm, volume 1, páginas 5–7. SIAM, 2001.

[KR05] Eamonn Keogh y Chotirat Ann Ratanamahatana. Exact indexing of dynamictime warping. Knowledge and information systems, 7(3):358–386, 2005.

[Lia05] T Warren Liao. Clustering of time series data—a survey. Pattern recognition,38(11):1857–1874, 2005.

[Llo82] Stuart Lloyd. Least squares quantization in PCM. IEEE transactions on infor-

mation theory, 28(2):129–137, 1982.

[LXF+16] Yang Li, Dong Xue, Erik Forrister, George Lee, Brian Garner, y YoungwookKim. Human Activity Classification Based on Dynamic Time Warping of anOn-Body Creeping Wave Signal. IEEE Transactions on Antennas and Propa-

gation, 64(11):4901–4905, 2016.

112

[MJ91] Zbigniew Michalewicz y Cezary Z Janikow. Handling constraints in geneticalgorithms. En ICGA, páginas 151–157, 1991.

[MRR80] Cory Myers, Lawrence Rabiner, y Aaron Rosenberg. Performance tradeoffs indynamic time warping algorithms for isolated word recognition. IEEE Transac-

tions on Acoustics, Speech, and Signal Processing, 28(6):623–635, 1980.

[Mül07] Meinard Müller. Information retrieval for music and motion, volume 2. Sprin-ger, 2007.

[NR07] Vit Niennattrakul y Chotirat Ann Ratanamahatana. On clustering multimediatime series data using k-means and dynamic time warping. En Multimedia and

Ubiquitous Engineering, 2007. MUE’07. International Conference on, páginas733–738. IEEE, 2007.

[PDJ00] Mitchell A Potter y Kenneth A De Jong. Cooperative coevolution: An ar-chitecture for evolving coadapted subcomponents. Evolutionary computation,8(1):1–29, 2000.

[PdSI12] Javier Garzás Parra, Juan A. Enríquez de S., y Emanuel Irrazábal. Gestión ágil

de proyectos software. Kybele Consulting, 2012.

[PG12] François Petitjean y Pierre Gançarski. Summarizing a set of time series byaveraging: From Steiner sequence to compact multiple alignment. Theoretical

Computer Science, 414(1):76–91, 2012.

[PKG11] François Petitjean, Alain Ketterlin, y Pierre Gançarski. A global averagingmethod for dynamic time warping, with applications to clustering. Pattern

Recognition, 44(3):678–693, 2011.

[Pos00] Marcos Gestal Pose. Introducción a los algoritmos genéticos. Departamento de

Tecnologías de la Información y las Comunicaciones Universidad de Coruña,2000.

[RK04] Chotirat Ann Ratanamahatana y Eamonn Keogh. Everything you know aboutdynamic time warping is wrong. En Third Workshop on Mining Temporal and

Sequential Data. Citeseer, 2004.

[RM03] Toni M Rath y Raghavan Manmatha. Word image matching using dynamic ti-me warping. En Computer Vision and Pattern Recognition, 2003. Proceedings.

2003 IEEE Computer Society Conference on, volume 2, páginas II–II. IEEE,2003.

113

[SC78] H. Sakoe y S. Chiba. Dynamic programming algorithm optimization for spo-ken word recognition. IEEE Transactions on Acoustics, Speech, and Signal

Processing, 26(1):43–49, Feb 1978.

[SC07] Stan Salvador y Philip Chan. Toward accurate dynamic time warping in lineartime and space. Intelligent Data Analysis, 11(5):561–580, 2007.

[SVG87] Jung Y Suh y D Van Gucht. Incorporating lleuristic Information into GeneticSearch. JJ Grefen, 1987.

[THNC02] Robert Tibshirani, Trevor Hastie, Balasubramanian Narasimhan, y Gilbert Chu.Diagnosis of multiple cancer types by shrunken centroids of gene expression.Proceedings of the National Academy of Sciences, 99(10):6567–6572, 2002.

[Vin68] Taras K Vintsyuk. Speech discrimination by dynamic programming. Cyberne-

tics and Systems Analysis, 4(1):52–57, 1968.

[WMD+13] Xiaoyue Wang, Abdullah Mueen, Hui Ding, Goce Trajcevski, Peter Scheuer-mann, y Eamonn Keogh. Experimental comparison of representation methodsand distance measures for time series data. Data Mining and Knowledge Dis-

covery, 26(2):275–309, 2013.

[WW03] Teddy Siu Fung Wong y Man Hon Wong. Efficient subsequence matching forsequences databases under time warping. En Database Engineering and Ap-

plications Symposium, 2003. Proceedings. Seventh International, páginas 139–148. IEEE, 2003.

114

Este documento fue editado y tipografiado con LATEX empleandola clase esi-tfg (versión 0.20170702) que se puede encontrar en:

https://bitbucket.org/arco group/esi-tfg

115

https://bitbucket.org/arco_group/esi-tfg

ag-costane: algoritmos genéticos para el cálculo del

Documents