Integración de Algoritmos de Inducción y...

INTEGRACIÓN DE ALGORITMOS DE INDUCCIÓN

Y AGRUPAMIENTO.

ESTUDIO DEL COMPORTAMIENTO.

TESIS DE GRADO EN INGENIERÍA EN INFORMÁTICA

Laboratorio de Sistemas Inteligentes

Facultad de Ingeniería

Universidad de Buenos Aires

Tesista: Sr. Ariel Yosef KOGAN ZAHAVI Directores: Prof. Dr. Ramón GARCÍA MARTÍNEZ Prof. M. Ing. Paola BRITOS Prof. M. Ing. Claudio RANCÁN

Mayo 2007

INTEGRACIÓN DE ALGORITMOS DE INDUCCIÓN

Y AGRUPAMIENTO.

ESTUDIO DEL COMPORTAMIENTO.

TESIS DE GRADO EN INGENIERÍA EN INFORMÁTICA

Laboratorio de Sistemas Inteligentes

Facultad de Ingeniería

Universidad de Buenos Aires

Sr. Ariel Yosef Kogan Zahavi Prof. Dr. Ramón García Martínez Tesista Director

Prof. M. Ing. Paola Britos Prof. M. Ing. Claudio Rancán Co-Directora Co-Director

Mayo 2007

Agradecimientos

Al Dr. García Martínez por darme la posibilidad de finalizar mi carrera de grado gozando de aprender y ayudarme a desafiar mi intelecto de forma permanente. Por haber aportado a mi formación sin limitarse a lo académico. Por su gran dedicación plasmada, entre otras cosas, en la enorme cantidad de horas de su tiempo dedicadas a mi tesis.

A la M. Ing. Britos por su continua orientación y por hacer tan ameno nuestro trabajo. Al M. Ing. Rancán por su dedicación y paciencia en ayudarme a no dejar ningún detalle sin atender.

A mi hermano Jonathan por su forma de ser vertiginosa, por nunca permitir que un día sea igual (de tranquilo) al anterior, logrando así mantenerme conectado con lo verdaderamente importante. Por traer la alegría a la casa y por su gran sinceridad cuando tiene algo que enseñarme.

A mis padres, por haberme transmitido el valor sin igual de la educación. Por su apoyo permanente. Por haber dedicado todos sus esfuerzos a brindarme las condiciones para formarme sin otra preocupación que la de estudiar.

A mi padre por sus pragmáticos consejos y su enseñanza mediante el ejemplo. Y a mi madre quien con esta tesis finaliza la carrera conmigo, después de haber vivido como propio cada momento de estudio y festejado (más que yo) la aprobación de cada examen.

Resumen

En esta tesis se estudia cómo se comporta la integración de los algoritmos de agrupamiento e inducción al ir variando sus parámetros en condiciones de laboratorio. Adicionalmente se intentará medir la calidad de las reglas obtenidas y la degradación de dicha calidad como consecuencia de la variación de los parámetros controlados en los experimentos.

Abstract

This thesis studies the behavior of the integration of induction and clustering algorithms varying its parameters under laboratory conditions. The quality of the obtained rules will try to be measured as a consequence of the variation of the parameters being controlled on the experiments.

Integración de Algoritmos de Inducción y Agrupamiento. Estudio del Comportamiento.

Índice Ariel Kogan i

Índice

1 Introducción .............................................................................................................. 1

2 Estado del Arte .......................................................................................................... 4

2.1 Self Organizing Maps (SOM) ............................................................................... 4

2.1.1 Algoritmo del SOM ...................................................................................... 4

2.1.2 Aplicaciones ............................................................................................... 12

2.2 Árboles de decisión – TDIDT ............................................................................. 12

2.2.1 Características de los árboles de decisión ................................................. 12

2.2.2 Construcción de los árboles de decisión ................................................... 12

2.2.3 Descripción general de los algoritmos ...................................................... 16

2.2.4 Presentación de los resultados .................................................................. 23

3 Descripción del Problema ........................................................................................ 24

4 Solución Propuesta .................................................................................................. 25

4.1 Identificación de los parámetros del problema ................................................ 25

4.2 Definiciones ...................................................................................................... 26

4.2.1 Cubrimiento de una regla sobre otra ........................................................ 26

4.2.2 Cubrimiento de una regla original por reglas descubiertas ...................... 28

4.2.3 Concentración de las reglas que indican la pertenencia a cada clase ...... 29

4.3 Método de generación de casos de experimentación ..................................... 30

4.3.1 Descripción del método ............................................................................. 30

4.3.2 Ejemplo de generación de un caso de experimentación .......................... 32

4.4 Descripción del Banco de Pruebas .................................................................... 35

4.4.1 Funcionalidades ......................................................................................... 35

4.4.2 Dinámica del Banco de Pruebas ................................................................ 37

5 Experimentación ...................................................................................................... 39

5.1 Definición de Variables ..................................................................................... 39

5.2 Delimitación del Universo de Estudio ............................................................... 40

5.3 Dominio Patrón ................................................................................................. 42

5.4 Formato de los Resultados ............................................................................... 42

5.5 Estrategia de Rastrillaje .................................................................................... 44

5.5.1 Requerimientos ......................................................................................... 44

5.5.2 Solución Adoptada ..................................................................................... 44


ii Ariel Kogan Índice

5.5.3 Selección de los pares de variables independientes a ser estudiados ...... 45

5.5.4 Diccionario de Parámetros Según Enfoque ............................................... 46

5.6 Análisis de los Experimentos ............................................................................ 47

5.6.1 Variación del número de clases que rigen el dominio para distinta cantidad de atributos que tienen los ejemplos ....................................................... 47

5.6.2 Variación del número de clases que rigen el dominio para distinta cantidad de valores que puede tomar cada atributo .............................................. 49

5.6.3 Variación del número de clases que rigen el dominio para distinta cantidad de reglas que indican la pertenencia a cada clase ................................... 51

5.6.4 Variación del número de reglas que indican la pertenencia a cada clase para distinta cantidad de atributos que tienen los ejemplos ........................ 53

5.6.5 Variación del número de reglas que indican la pertenencia a cada clase para distinta cantidad de clases que rigen el dominio ................................... 55

5.6.6 Variación del número de posibles valores que puede tomar cada atributo para distinta cantidad de atributos que conforman los ejemplos ............ 57

5.6.7 Variación del número de posibles valores que puede tomar cada atributo para distinta cantidad de reglas que indican la pertenencia a cada clase ................................................................................................................... 59

5.6.8 Variación del número de atributos que conforman los ejemplos para distinta cantidad de posibles valores que puede tomar cada uno ................. 61

5.6.9 Variación del número de atributos que conforman los ejemplos para distinta cantidad de clases que rigen el dominio ............................................ 63

5.6.10 Variación del número de atributos que conforman los ejemplos para distinta cantidad de reglas que indican la pertenencia a cada clase .............. 65

5.6.11 Estudio de dominios variando la especificidad del cubrimiento de cada regla sobre sus ejemplos asociados, para distinta cantidad de estos ............ 67

5.6.12 Estudio de dominios variando la especificidad del cubrimiento de cada regla sobre sus ejemplos asociados, para distinta concentración de las reglas que indican la pertenencia a cada clase ....................................................... 69

5.6.13 Estudio de dominios variando la concentración de las reglas que indican la pertenencia a cada clase, para distinta cantidad de ejemplos que dan soporte a cada regla ......................................................................................... 71

5.6.14 Estudio de dominios variando la concentración de las reglas que indican la pertenencia a cada clase, para distinta especificidad del cubrimiento de cada regla sobre sus ejemplos asociados ...................................... 73

5.6.15 Estudio de dominios variando el número de ejemplos que dan soporte a cada regla, para distinta especificidad del cubrimiento de cada regla sobre sus ejemplos asociados ........................................................................ 75

5.6.16 Estudio de dominios variando el número de ejemplos que dan soporte a cada regla, para distinta concentración de las reglas que indican la pertenencia a cada clase ......................................................................................... 77


Índice Ariel Kogan iii

5.7 Unificación de los resultados experimentales .................................................. 79

5.7.1 Enfoque orientado al dominio ................................................................... 79

5.7.2 Enfoque orientado a los ejemplos ............................................................. 82

6 Conclusiones ............................................................................................................ 84

6.1 Aportes .............................................................................................................. 84

6.2 Futuras líneas de trabajo .................................................................................. 85

6.2.1 Análisis de los resultados obtenidos mediante la aplicación de minería de datos ...................................................................................................... 85

6.2.2 Inclusión de los parámetros de la red SOM como variables del experimento ............................................................................................................ 86

6.2.3 Otras líneas de trabajo .............................................................................. 87

7 Referencias .............................................................................................................. 88

A Metodología ............................................................................................................ 92

A.1 Requerimientos ................................................................................................. 92

A.2 Análisis .............................................................................................................. 92

A.2.1 Diagrama de Clases .................................................................................... 92

A.2.2 Casos de Uso .............................................................................................. 94

A.2.3 Diagrama de transición de estados ........................................................... 96

A.3 Diseño ............................................................................................................... 97

A.3.1 Ejecución de experiencias ......................................................................... 98

A.3.2 Graficación de resultados .......................................................................... 99

A.3.3 Unificación de los resultados obtenidos para su análisis en conjunto ..... 99

A.4 Codificación ....................................................................................................... 99

A.5 Implementación .............................................................................................. 100

A.5.1 Procesos y Pantallas ................................................................................ 100

A.6 Pruebas ........................................................................................................... 102

A.6.1 Plan de pruebas ....................................................................................... 102

A.6.2 Documento de diseño de la prueba ........................................................ 102

A.6.3 Especificación de los casos de prueba ..................................................... 103

A.6.4 Especificación del procedimiento de prueba .......................................... 105

A.6.5 Informe de los casos de prueba ejecutados ............................................ 106

A.6.6 Informe de la prueba ............................................................................... 107

A.7 Gestión de configuración ................................................................................ 107

A.7.1 Identificación de la configuración ........................................................... 107

A.7.2 Control de configuración ......................................................................... 108

A.7.3 Generación de informes de estado ......................................................... 109


iv Ariel Kogan Índice

B Manual de Usuario ................................................................................................ 113

B.1 Introducción .................................................................................................... 113

B.1.1 Descripción de los componentes............................................................. 113

B.1.2 Plataforma y lenguaje .............................................................................. 113

B.1.3 Librerías utilizadas ................................................................................... 114

B.1.4 Presentación del producto ...................................................................... 114

B.2 Requerimientos ............................................................................................... 115

B.2.1 Máquina virtual Java ................................................................................ 115

B.2.2 PostgreSQL ............................................................................................... 115

B.2.3 JFreeChart ................................................................................................ 116

B.3 Configuración del entorno .............................................................................. 116

B.3.1 Classpath .................................................................................................. 116

B.3.2 Creación del esquema de base de datos ................................................. 118

B.4 Utilización del banco de pruebas .................................................................... 118

B.4.1 Procedimientos comunes a todas las operaciones ................................. 118

B.4.2 Ejecución de experiencias ....................................................................... 122

B.4.3 Unificación de datos ................................................................................ 125

B.4.4 Graficación ............................................................................................... 126


Índice de tablas Ariel Kogan v

Índice de tablas Tabla ‎4.1: Parámetros identificados del problema ........................................................ 26

Tabla ‎5.1: Definición de variabilidad o no de cada uno de los parámetros ................... 40

Tabla ‎5.2: Rango de variación de las variables ............................................................... 41

Tabla ‎5.3: Rango de variación de las variables involucradas en la figura 5.1 ................ 43

Tabla ‎5.4: Origen de pertenencia de las variables ......................................................... 45

Tabla ‎5.5: Combinación de variables de los experimentos a realizar ............................ 46

Tabla ‎5.6: Diccionario de parámetros según el enfoque ............................................... 47


vi Ariel Kogan Índice de Figuras

Índice de Figuras Figura ‎2.1: Estructuras de los mapas ................................................................................. 5

Figura ‎2.2: Vecindario de una neurona ............................................................................. 6

Figura ‎2.3: Funciones de vecindario .................................................................................. 9

Figura ‎2.4: Tasas de aprendizaje ..................................................................................... 10

Figura ‎2.5: U-Matrix ......................................................................................................... 11

Figura ‎4.1: Definición gráfica de una clase que rige el dominio...................................... 29

Figura ‎4.2: Atributos de un ejemplo del dominio ........................................................... 33

Figura ‎4.3: Valores posibles que pueden tomar los atributos de un ejemplo ................ 33

Figura ‎4.4: Definición gráfica de una clase que rige el dominio...................................... 34

Figura ‎4.5: Definición gráfica de reglas que indican la pertenencia a una clase ............. 34

Figura ‎4.6: Experimento en 3 pasos ................................................................................ 37

Figura ‎5.1: Ejemplo de una de las gráficas como resultado de un experimento.

Estudio de dominios variando la cantidad de reglas que indican la

pertenencia a cada clase, para distinta cantidad de atributos que tienen las

reglas. ...................................................................................................................... 43

Figura ‎A.1: Diagrama de clases fundamentales del banco de pruebas ........................... 93

Figura ‎A.2: Diagrama de casos de uso de alto nivel de abstracción ............................... 94

Figura ‎A.3: Diagrama de casos de uso de ejecución de experiencias ............................. 95

Figura ‎A.4: Diagrama de casos de uso de iteraciones ..................................................... 96

Figura ‎A.5: Diagrama de transición de estados de ejecución de experiencias ............... 97


Índice de Gráficas Ariel Kogan vii

Índice de Gráficas Gráfica ‎5.1: Estudio de dominios variando la cantidad de clases que los rigen,

para distinta cantidad de atributos que tienen los ejemplos ................................. 48

Gráfica ‎5.2: Estudio de dominios variando la cantidad de clases que los rigen,

para distinta cantidad de valores posibles que pueden tomar cada atributo ........ 50

Gráfica ‎5.3: Estudio de dominios variando la cantidad de clases que los rigen,

para distinta cantidad de reglas que indican la pertenencia a cada clase .............. 52

Gráfica ‎5.4: Estudio de dominios variando la cantidad de reglas que indican la

pertenencia a cada clase, para distinta cantidad de atributos que conforman

los ejemplos ............................................................................................................. 54

Gráfica ‎5.5: Estudio de dominios variando la cantidad de reglas que indican la

pertenencia a cada clase, para distinta cantidad de clases que rigen los

dominios .................................................................................................................. 56

Gráfica ‎5.6: Estudio de dominios variando la cantidad de valores posibles que

puede tomar cada uno de los atributos que tienen las reglas, para distinta

cantidad de atributos que tienen las reglas ............................................................ 58

Gráfica ‎5.7: Estudio de dominios variando la cantidad de valores posibles que

puede tomar cada uno de los atributos que conforman las reglas, para

distinta cantidad de reglas que indican la pertenencia a cada clase ...................... 60

Gráfica ‎5.8: Estudio de dominios variando la cantidad de atributos que

conforman los ejemplos, para distinta cantidad de valores posibles que

pueden tomar cada uno de estos atributos ............................................................ 62

Gráfica ‎5.9: Estudio de dominios variando la cantidad de atributos que tienen las

reglas, para distinta cantidad clases que rigen los dominios .................................. 64

Gráfica ‎5.10: Estudio de dominios variando la cantidad de atributos que tienen

las reglas, para distinta cantidad de reglas que indican la pertenencia a cada

clase ......................................................................................................................... 66

Gráfica ‎5.11: Estudio de dominios variando la especificidad del cubrimiento de

cada regla sobre sus ejemplos asociados, para distinta cantidad de estos ............ 68


viii Ariel Kogan Índice de Gráficas

Gráfica ‎5.12: Estudio de dominios variando la especificidad del cubrimiento de

cada regla sobre sus ejemplos asociados, para distinta concentración de

reglas que indican la pertenencia a cada clase ....................................................... 70

Gráfica ‎5.13: Estudio de dominios variando la concentración de las reglas que

indican la pertenencia a cada clase, para distinta cantidad de ejemplos que

dan soporte a cada regla ......................................................................................... 72

Gráfica ‎5.14: Estudio de dominios variando la concentración de las reglas que

indican la pertenencia a cada clase, para distinta especificidad del

cubrimiento de cada regla sobre sus ejemplos asociados ...................................... 74

Gráfica ‎5.15: Estudio de dominios variando el número de ejemplos que dan

soporte a cada regla, para distinta especificidad del cubrimiento de cada

regla sobre sus ejemplos asociados ........................................................................ 76

Gráfica ‎5.16: Estudio de dominios variando el número de ejemplos que dan

soporte a cada regla, para distinta concentración de las reglas que indican la

pertenencia a cada clase ......................................................................................... 78


Introducción Ariel Kogan 1

1 Introducción

Se denomina Minería de Datos al conjunto de técnicas y herramientas aplicadas al proceso no trivial de extraer y presentar conocimiento implícito, previamente desconocido, potencialmente útil y humanamente comprensible, a partir de grandes conjuntos de datos, con objeto de predecir de forma automatizada tendencias y comportamientos y describir de forma automatizada modelos previamente desconocidos [Piatetski-Shapiro et al., 1991; Chen et al., 1996; Mannila, 1997; Britos et al., 2005].

El caso particular de la Minería de Datos Inteligente [Evangelos & Han, 1996; Michalski et al., 1998] consiste en la aplicación de métodos de aprendizaje automático [Michalski et al., 1983; Holsheimer & Siebes, 1991] para descubrir y enumerar patrones presentes en los datos o mejorar procesos predictivos [Felgaer et al., 2006].

Un procedimiento recurrente a la hora de realizar minería de datos inteligente consiste en tomar el conjunto de datos a estudiar, aplicar un algoritmo de clustering [Kaski, 1997, Hall y Colmes, 2003] para separarlo en distintos grupos (clases) y sobre cada uno de estos grupos intentar generar reglas que caractericen su conformación, también utilizando un determinado algoritmo a tales efectos [Grosser et al., 2005; Cogliati et al., 2006].

Una de las opciones para llevar adelante el proceso de clustering es dada por el uso de los mapas auto-organizados [Kohonen, 1982, Kohonen, 1990, Kohonen, 1995, Kohonen et al., 1996], los cuales son un algoritmo de redes neuronales que ha sido utilizado para una gran variedad de aplicaciones, principalmente para problemas de ingeniería, pero también para análisis de datos.

En cuanto a la inducción de reglas, dada la caracterización de las entidades que se utilizan comúnmente con la minería de datos, fuertemente basada en los valores de sus atributos y no en las relaciones establecidas entre estos, se suelen emplear métodos atribucionales. Uno de los más claros y difundidos son los árboles de decisión o clasificación [Michalski et al., 1998; Grossman et al., 1999] en los cuales se cuenta con nodos que modelizan cada atributo, ramas que se originan en estos nodos, una por cada valor que el atributo puede tomar, y finalmente las hojas que corresponden a las clases individuales. Recorriendo un árbol desde su nodo padre hasta las distintas hojas, se pueden generar de forma muy simple las reglas a las cuales la clasificación responde. Una de las herramientas aplicadas al mencionado proceso es la familia de algoritmos TDIDT [Quinlan, 1986; Servente y García-Martínez, 2002]. Sin embargo, estos pasos se realizan únicamente bajo la presunción de obtener un resultado representativo del conjunto de datos sobre el que se trabaja.

En este contexto, en esta tesis se estudia cómo se comporta la integración de los algoritmos de inducción y agrupamiento al ir variando sus parámetros en condiciones de laboratorio. Adicionalmente se intentará medir la calidad de las reglas


2 Ariel Kogan Introducción

obtenidas y la degradación de dicha calidad como consecuencia de la variación de los parámetros controlados en los experimentos.

En el capítulo del Estado del Arte se presenta el contexto teórico para el estudio de la integración de agrupamiento por SOM e inducción de reglas por TDIDT como método de descubrimiento de conocimiento. Se describen los mapas auto-organizados SOM, el algoritmo que los gobierna y las aplicaciones de esta red neuronal. Se presentan los árboles de decisión TDIDT, sus características, el método para la construcción de estos, se hace una descripción general de sus algoritmos y se expone la forma en la que se muestran los resultados obtenidos.

En el capítulo de la Descripción del Problema se presenta el problema a resolver, se fundamenta el porqué de su elección y se señala su importancia en el contexto de estudio.

En el capítulo de la Solución Propuesta se describe la respuesta al problema planteado. Se identifican los parámetros del problema, se plantean definiciones necesarias como el cubrimiento de una regla sobre otra, el cubrimiento de una regla original por reglas descubiertas y el concepto de concentración de reglas que indican la pertenencia a una clase. Se aborda el método de generación de casos de experimentación describiéndolo y dando un ejemplo para su mejor comprensión. Finalmente, se realiza una descripción del Banco de Pruebas, abordando sus funcionalidades y describiendo su dinámica de funcionamiento.

En el capítulo de Experimentación se exponen los resultados obtenidos de los experimentos realizados. Se han definido los parámetros a variar, delimitado el universo de estudio, determinado un dominio patrón y establecido el formato de los resultados a obtener. Se ha definido una estrategia de aspectación de valores de variables en base a requerimientos sobre ésta, habiéndose adoptado una solución en particular. Para esta solución, se han determinado los pares de variables a estudiar y se ha confeccionado un diccionario de variables dependientes e independientes según el enfoque adoptado para una comprensión más clara. Se han analizado e interpretado los experimentos y se han sistematizado las proposiciones experimentales formuladas, tanto para el enfoque orientado al dominio como para el enfoque orientado a los ejemplos.

En las Conclusiones se resumen los aportes formulados en la tesis y se

presentan futuras líneas de trabajo proponiendo minería de datos para el análisis de los resultados, incluir la variación de los parámetros de la red SOM en futuros estudios y líneas complementarias.

En el anexo A se describe la metodología empleada para la construcción del

banco de pruebas. Se enumeran los requerimientos, se hace el análisis del sistema mediante diagramas de clase, determinación de casos de uso, y diagramas de transición de estados. Se realiza el diseño de la aplicación para sus componentes de ejecución de experiencias, graficación de resultados y unificación de los resultados obtenidos para su análisis en conjunto. Se aborda la codificación de la solución y su


Introducción Ariel Kogan 3

implementación describiendo sus procesos y pantallas. Finalmente, se cubre la etapa de pruebas estableciendo un plan de pruebas, documentando el diseño de cada prueba, especificando los casos de prueba, los procedimientos, se confecciona un informe de los casos de prueba ejecutados, así como un informe de la prueba. Se determina la gestión de configuración en cuanto a su identificación, control y generación de informes de estado.

En el anexo B se transcribe el manual de usuario del banco de pruebas. Se

introduce el banco de pruebas describiendo sus componentes, la plataforma y el lenguaje para los cuales está desarrollado, las librerías utilizadas y se presenta el producto. Se enumeran los requerimientos previos para poner en funcionamiento el producto, se detalla el procedimiento para configurar el entorno de trabajo mediante el establecimiento del classpath apropiado y la creación del esquema necesario para la base de datos. Finalmente, se describe la forma de utilizar el banco de pruebas, tanto para los procedimientos comunes a todas las operaciones, como para la ejecución de experiencias, unificación de datos y graficación de resultados.


4 Ariel Kogan Estado del Arte

2 Estado del Arte

En este capítulo se presenta el contexto teórico para el estudio de la integración de agrupamiento por SOM e inducción de reglas por TDIDT como método de descubrimiento de conocimiento. Se describen los mapas auto-organizados SOM (sección 2.1), el algoritmo que los gobierna (sección 2.1.1) y las aplicaciones de esta red neuronal (sección 2.1.2). Se presentan los árboles de decisión TDIDT (sección 2.2), sus características (sección 2.2.1), el método para la construcción de estos (2.2.2), se hace una descripción general de sus algoritmos (sección 2.2.3) y se expone la forma en la que se muestran los resultados obtenidos (sección 2.2.4).

2.1 Self Organizing Maps (SOM) Existen evidencias que demuestran que en el cerebro hay neuronas que se organizan en muchas zonas, de forma que las informaciones captadas del entorno a través de los órganos sensoriales se representan internamente en forma de mapas bidimensionales [Beveridge, 1996]. Por ejemplo, en el sistema visual se han detectado mapas del espacio visual en zonas del córtex (capa externa del cerebro); también en el sistema auditivo se detecta una organización según la frecuencia a la que cada neurona alcanza mayor respuesta [Hilera González & Martínez Hernando, 2000].

Aunque en gran medida esta organización neuronal está predeterminada genéticamente, es probable que parte de ella se origine mediante el aprendizaje. Esto sugiere, por tanto, que el cerebro podría poseer capacidad inherente de formar mapas topológicos de las informaciones recibidas del exterior.

A partir de estas ideas, Teuvo Kohonen presentó en 1982 [Kohonen, 1982] un sistema con un comportamiento semejante; se trata de un modelo de red neuronal con capacidad para formar mapas de características de manera similar a como ocurre en el cerebro. El objetivo de Kohonen era demostrar que un estímulo externo (información de entrada) por sí solo, suponiendo una estructura propia y una descripción funcional del comportamiento de la red, era suficiente para forzar la formación de mapas. Estudiaremos, entonces, este modelo llamado Self Organizing Maps (SOM) que se basa en el principio de formación de mapas topológicos para establecer características comunes entre las informaciones (vectores) de entrada a la red. Este modelo es uno de los más populares que se utilizan en redes neuronales artificiales y pertenece a la categoría de redes con aprendizaje competitivo.

2.1.1 Algoritmo del SOM

El algoritmo de aprendizaje del SOM está basado en el aprendizaje no supervisado y competitivo, lo cual quiere decir que no se necesita intervención humana durante el mismo y que se necesita saber muy poco sobre las características


Estado del Arte Ariel Kogan 5

de la información de entrada. Podríamos, por ejemplo, usar un SOM para clasificar datos sin saber a qué clase pertenecen los mismos [Hollmen, 1996]. El mismo provee un mapa topológico de datos que se representan en varias dimensiones utilizando unidades de mapa (las neuronas) simplificando el problema [Kohonen, 1995]. Las neuronas usualmente forman un mapa bidimensional por lo que el mapeo de un problema ocurre con muchas dimensiones en el espacio a un plano [Hollmen, 1996]. La propiedad de preservar la topología significa que el mapeo preserva las distancias relativas entre puntos [Kohonen, 1982]. Los puntos que están cerca unos de los otros en el espacio original de entrada son mapeados a neuronas cercanas en el SOM; por lo tanto, el SOM sirve como herramienta de análisis de clases de datos de muchas dimensiones [Vesanto & Alhoniemi, 2000]; además tiene la capacidad de generalizar [Essenreiter, Karrenbach & Treitel, 1999], lo que implica que la red puede reconocer o caracterizar entradas que nunca antes ha encontrado; una nueva entrada es asimilada por la neurona a la cual queda mapeada.

El SOM es un vector bidimensional de neuronas:

𝑀 = 𝑚1, … , 𝑚𝑝×𝑞

Una neurona es un vector llamado patrón representado de la siguiente forma:

𝑚𝑖 = 𝑚𝑖1, … , 𝑚𝑖𝑛

La neurona tiene las mismas dimensiones que los vectores de entrada (datos de entrada), es decir que es n-dimensional. Las neuronas están conectadas a las neuronas adyacentes por una relación de vecinos. Esta dicta la topología, o la estructura, del mapa; usualmente, las neuronas están conectadas unas con otras en una topología hexagonal o rectangular. En la figura 2.1 podemos observar (a) una estructura rectangular y (b) una estructura hexagonal.

Figura ‎2.1: Estructuras de los mapas



Se puede definir una distancia entre las neuronas de acuerdo a su relación de topología; las mismas pueden ser vecinas inmediatas (las neuronas adyacentes) que pertenecen al vecindario 𝑁𝑐 de la neurona 𝑚𝑐 . La función de vecindario es una función decreciente en el tiempo: 𝑁𝑐 = 𝑁𝑐 𝑡 .

Figura ‎2.2: Vecindario de una neurona

En la figura 2.2 podemos observar vecindarios de distintos tamaños. En el

hexágono más pequeño se encuentran todas las neuronas vecinas que pertenecen al vecindario más pequeño de la neurona ubicada en el centro.

En el algoritmo básico del SOM, las relaciones topológicas y el número de neuronas son fijos desde el comienzo; este número de neuronas determina la escala o la granularidad del modelo resultante. La selección de la granularidad afecta la certeza y la capacidad de generalizar del modelo. Debe tenerse en cuenta que la granularidad y la generalización son objetivos contradictorios [Hollmen, 1996]. Mejorando el primero, se pierde en el segundo, y viceversa. Esto se debe a que si aumentamos el primero se obtendrán muchos más grupos para poder clasificar los datos de entrada, evitando que se pueda generalizar el espacio en clases más abarcativas. De manera inversa, si se generaliza demasiado se puede perder información que caracterice a un grupo específico que quede incluido en otro por la falta de granularidad. 2.1.1.1 Pre-procesamiento de los datos

Los datos que alimentan al SOM incluyen toda la información que toma la red. Si se le presenta información errónea, el resultado es erróneo o de mala calidad. Entonces, el SOM, tanto como los otros modelos de redes neuronales, deben eliminar la información “basura” para que no ingrese al sistema. Por lo cual se debe trabajar con un subconjunto de los datos; estos deben ser relevantes para el modelo a analizar. También se deben eliminar los errores en los datos; si los mismos se obtienen a través de una consulta a una base de datos, el resultado puede incluir datos erróneos debido a la falta de integridad de la base; entonces estos deben ser filtrados usando conocimientos previos del dominio del problema y el sentido común.



Comúnmente los componentes de los datos de entrada se normalizan para tener una escala de 0 a 1. Esto asegura que por cada componente, la diferencia entre dos muestras contribuye un valor igual a la distancia medida calculada entre una muestra de entrada y un patrón. Es decir que los datos deben previamente codificarse (normalizarse). De lo contrario no será posible usar la distancia como una medida de similitud. Esta medida debe ser cuantificable por lo que la codificación debe ser armónica con la medida de similitud utilizada. La medida mayormente utilizada es la distancia Euclídea. Los datos simbólicos no pueden ser procesados por un SOM como tales, por lo que deben ser transformados a una codificación adecuada. 2.1.1.2 Inicialización

Existen varios tipos de inicializaciones para los valores de las neuronas (patrones): entre ellos se pueden nombrar la inicialización al azar y la inicialización utilizando usando las primeras muestras. En la inicialización al azar se asignan valores aleatorios a los patrones; se utiliza cuando se sabe muy poco o nada sobre los datos de entrada en el momento de comenzar el entrenamiento. La inicialización utilizando las primeras muestras utiliza los primeros datos de entrada asignándolos a los patrones; tiene la ventaja que automáticamente se ubican en la parte correspondiente del espacio de entrada. 2.1.1.3 Entrenamiento

El entrenamiento es un proceso iterativo a través del tiempo. Requiere un esfuerzo computacional importante, y por lo tanto, consume mucho tiempo. Este consiste de muestras del conjunto de datos de entrada que van ingresando a la red para que la misma las “aprenda”. El aprendizaje consiste en elegir una neurona ganadora por medio de una medida de similitud y actualizar los valores de los patrones en el vecindario del ganador; este proceso se repite varias veces para poder ir refinando (acotando) el error y acercar las neuronas a una representación más adecuada de los datos de entrada.

En un paso del entrenamiento, un vector muestra se toma de los datos de entrada; este vector es presentado a todas las neuronas en la red y se calcula la medida de similitud entre la muestra ingresada y todos los patrones. La unidad más parecida o Best Matching Unit (BMU) se elige como el prototipo con la mayor similitud con la muestra de entrada; esta similitud usualmente se define con una medida de distancia vectorial. Por ejemplo, en el caso de la distancia Euclídea la BMU es la neurona más cercana a la muestra presentada en el espacio representado por todos los datos de entrada. La norma Euclídea de un vector x se define como:

𝑥 = 𝑥𝑖2

𝑛

𝑖=1



donde: 𝑥𝑖 : corresponde al valor de la componente 𝑖 del vector 𝑥. 𝑛: corresponde a la dimensión del vector 𝑥.

Por lo tanto, la distancia Euclídea en términos de la diferencia de la norma Euclídea entre dos vectores se define como:

𝑑𝑒 𝑥, 𝑦 = 𝑥 − 𝑦 donde: 𝑥: corresponde al vector 𝑥. 𝑦: corresponde al vector 𝑦.

La BMU, usualmente denotada con 𝑚𝑐 , es el patrón que más se parece al vector de entrada 𝑥. Se define formalmente como la neurona para la cual

𝑥 − 𝑚𝑐 = min𝑖

𝑥 − 𝑚𝑖

donde: 𝑥: corresponde al vector de entrada 𝑥. 𝑚𝑐 : corresponde al vector que representa la BMU. 𝑖: corresponde a la neurona 𝑖. 𝑚𝑖 : corresponde al vector que representa la neurona 𝑚𝑖 .

Luego de encontrar la BMU, se actualizan todas las neuronas del SOM. Durante el procedimiento de actualización, la BMU se actualiza para acercarse aún más al vector de entrada. Los vecinos topológicos de la BMU también se actualizan de manera similar utilizando una tasa de aprendizaje de menor valor. Este procedimiento acerca a la BMU y a sus vecinos topológicos hacia la muestra ingresada. El esfuerzo computacional consiste en encontrar una BMU entre todas las neuronas y actualizar cada uno de los patrones en el vecindario de la unidad ganadora. Si el vecindario es grande, entonces más patrones deberán ser actualizados; este es el caso que se presenta en el comienzo del entrenamiento, donde se recomienda utilizar vecindarios grandes. En el caso de redes con muchas neuronas, gran parte del tiempo se utiliza buscando a la ganadora. Obviamente que dependiendo del diseño del software utilizado y el hardware estas consideraciones serán más o menos significativas.

A través del procedimiento de actualización descripto, la red forma una red elástica que durante el aprendizaje cae en una nube formada por los datos de entrada. Los patrones tienden a posicionarse allí donde los datos son densos, mientras que se tiende a tener pocos patrones donde los datos de entrada están más dispersos. Por lo



tanto, la red tiende a aproximar la función de densidad de probabilidad de los datos de entrada [Kohonen, 1995].

La regla de actualización del SOM para una unidad 𝑚𝑖 , es la siguiente:

𝑚𝑖 𝑡 + 1 = 𝑚𝑖 𝑡 + ℎ𝑐𝑖 𝑡 𝑥 𝑡 − 𝑚𝑖 𝑡 dónde: 𝑡: representa un estado en el tiempo.

Por lo tanto, y como se mencionó anteriormente, este es un proceso de entrenamiento a través del tiempo. El vector de entrada 𝑥 𝑡 es tomado en instante 𝑡 para ser procesado, ℎ𝑐𝑖 es una función de vecindario alrededor de la unidad ganadora 𝑚𝑐 decreciente en el tiempo.

La función de vecindario que incluye la tasa de aprendizaje 𝛼 𝑡 determina la forma en que serán actualizadas las neuronas vecinas. La misma se puede escribir como:

ℎ𝑐𝑖 𝑡 = 𝛼 𝑡 𝑒−

𝑟𝑖−𝑟𝑐 2

2𝜎 𝑡 2 en el caso de una función de vecindario Gaussiana alrededor de la neurona 𝑚𝑐 .

Se pueden utilizar otras funciones de vecindario como las funciones que se presentan en la figura 2.3. La única restricción es que sean decrecientes alrededor de la neurona 𝒎𝒄. Por lo tanto, también podrían ser constantes alrededor de la neurona ganadora.

Figura ‎2.3: Funciones de vecindario

En la figura 2.3 se pueden observar dos funciones de vecindario: (a) función Gaussiana, (b) función constante.



La tasa de aprendizaje utilizada en la función vecindario es una función

decreciente en el tiempo. Dos formas comúnmente usadas son la función lineal y la inversamente proporcional al tiempo 𝑡.

Figura ‎2.4: Tasas de aprendizaje

En la figura 2.4 se pueden observar tipos de tasas de aprendizaje: (a) la función

lineal decrece a cero linealmente durante el aprendizaje, (b) la función inversamente proporcional decrece rápidamente desde su valor inicial.

Los valores de la tasa de aprendizaje 𝛼 se definen de la siguiente manera:

𝛼 𝑡 = 𝛼 0 1 − 𝑡𝑟 , para el caso de la función inversa y

𝛼 𝑡 = 𝐶𝛼 0 𝐶 + 𝑡 , para el caso de la función lineal donde 𝐶 se puede definir como 𝑟

100 y 𝑟 corresponde a la cantidad total de vectores muestra utilizados en el

entrenamiento.

Se debe determinar el valor inicial de 𝛼, que define el valor inicial de la tasa de aprendizaje. Usualmente, cuando se utiliza una función inversa el valor inicial puede ser mayor que en el caso lineal. El aprendizaje se realiza usualmente en dos fases:

- En la primera vuelta se utilizan valores relativamente altos de 𝛼 (desde 0,3 a 0,99).

- En la segunda vuelta se utilizan valores más pequeños. Esto corresponde a adaptaciones que se van haciendo hasta que la red funciona correctamente [Kohonen, 1995].

La elección de los valores iniciales de 𝛼 y la forma en que estos van variando

pueden modificar sensiblemente los resultados obtenidos.



2.1.1.4 Visualización

El SOM es una aproximación de la función de densidad de probabilidad de los datos de entrada [Kohonen, 1995] y puede representarse de una manera visual.

La representación U-Matrix (unified distance matrix) del SOM visualiza la distancia entre neuronas adyacentes [Kohonen, 1995]. La misma se calcula y se presenta con diferentes colores entre los nodos adyacentes. Un color oscuro entre neuronas corresponde a una distancia grande que representa un espacio importante entre los valores de los patrones en el espacio de entrada. Un color claro, en cambio, significa que los patrones están cerca unos de otros. Las áreas claras pueden pensarse como “clases” y las oscuras como “separadores”. Esta puede ser una representación muy útil de los datos de entrada sin tener información a priori sobre las clases.

Figura ‎2.5: U-Matrix

En la figura 2.5 podemos observar las neuronas indicadas por un punto negro. La representación revela que existe una clase separada en la esquina superior derecha de la red. Las clases están separadas por una zona negra. Este resultado se logra con aprendizaje no supervisado, es decir, sin intervención humana. Enseñar a un SOM y representarla con la U-Matrix ofrece una forma rápida de analizar la distribución de los datos.

2.1.1.5 Validación

Se pueden crear la cantidad de modelos que se quiera, pero antes de utilizar alguno de ellos, deben ser validados. La validación significa que el modelo debe ser probado para asegurar que devuelve valores razonables y certeros. La misma debe realizarse usando un conjunto independiente de datos; este es similar al utilizado para el entrenamiento pero no parte de él; puede verse a este conjunto de prueba como un caso representativo del caso general.



2.1.2 Aplicaciones

Se ha demostrado que los SOM son muy útiles en aplicaciones técnicas. En la industria, se ha utilizado, por ejemplo, en monitoreo de procesos y máquinas [Alander & Frisk, 1991; Cumming, 1993; Alhoniemi, 1995], identificación de fallas [Vapola, Simula & Kohonen, 1994] y control de robots [Ritter, Martinetz & Schulten, 1992].

La capacidad de dividir el espacio en clases y patrones representativos lo hace muy poderoso también para la clasificación y segmentación de los datos.

2.2 Árboles de decisión – TDIDT

La familia de los Top Down Induction of Decision Trees (TDIDT) pertenece a los métodos inductivos del aprendizaje automático que aprenden a partir de ejemplos preclasificados; en minería de datos, ésta se utiliza para modelar las clasificaciones en los datos mediante árboles de decisión.

2.2.1 Características de los árboles de decisión

Los árboles de decisión representan una estructura de datos que organiza eficazmente los descriptores; dichos árboles son construidos de forma tal que en cada nodo se realiza una prueba sobre el valor de los descriptores y de acuerdo con la respuesta se va descendiendo en las ramas, hasta llegar al final del camino donde se encuentra el valor del clasificador. Se puede analizar un árbol de decisión como una caja negra en función de cuyos parámetros (descriptores) se obtiene un cierto valor del clasificador, también puede analizarse como una disyunción de conjunciones, donde cada camino desde la raíz hasta las hojas representa una conjunción, y todos los caminos son alternativos, es decir, son disyunciones.

2.2.2 Construcción de los árboles de decisión

Los árboles TDIDT, a los cuales pertenecen los generados por el ID3 y por el C4.5, se construyen a partir del método de Hunt [Hunt et al., 1966]. El esqueleto de este método para construir un árbol de decisión a partir de un conjunto 𝑇 de datos de entrenamiento se detalla a continuación; sean las clases 𝐶1, 𝐶2, … , 𝐶𝑘 , existen tres posibilidades:

1. 𝑇 contiene uno o más casos, todos pertenecientes a una única clase 𝐶𝑗 :

El árbol de decisión para 𝑇 es una hoja identificando la clase 𝐶𝑗 .



2. 𝑇 no contiene ningún caso:

El árbol de decisión es una hoja, pero la clase asociada debe ser determinada por información que no pertenece a 𝑇. Por ejemplo, una hoja puede escogerse de acuerdo a conocimientos de base del dominio, como ser la clase mayoritaria.

3. 𝑇 contiene casos pertenecientes a varias clases: En este caso, la idea es refinar 𝑇 en subconjuntos de casos que tiendan, o parezcan tender hacia una colección de casos pertenecientes a una única clase. Se elige una prueba basada en una única variable, que tiene uno o más resultados, mutuamente excluyentes 𝑂1, 𝑂2, … , 𝑂𝑛 , 𝑇 se particiona en los subconjuntos 𝑇1, 𝑇2, … , 𝑇𝑛 donde 𝑇𝑖 contiene todos los casos de 𝑇 que tienen el resultado 𝑂𝑖 para la prueba elegida. El árbol de decisión para 𝑇 consiste en un nodo de decisión identificando la prueba, con una rama para cada resultado posible. El mecanismo de construcción del árbol se aplica recursivamente a cada subconjunto de datos de entrenamiento, para que la i-ésima rama lleve al árbol de decisión construido por el subconjunto 𝑇𝑖 de datos de entrenamiento.

2.2.2.1 Cálculo de la ganancia de información

En los casos en los que el conjunto 𝑇 contiene ejemplos pertenecientes a distintas clases, se realiza una prueba sobre las distintas variables y se realiza una partición según la “mejor” variable. Para encontrar la “mejor” variable, se utiliza la teoría de la información, que sostiene que la información se maximiza cuando la entropía se minimiza, la entropía determina la azarosidad o desestructuración de un conjunto, si se supone que se tienen ejemplos positivos y negativos, la entropía del subconjunto 𝑆𝑖 , 𝐻 𝑆𝑖 puede calcularse como:

𝐻 𝑆𝑖 = −𝑝𝑖+ log 𝑝𝑖

+ − 𝑝𝑖−𝑝𝑖

−

donde 𝑝𝑖

+ es la probabilidad de que un ejemplo tomado al azar de 𝑆𝑖 sea positivo. Esta probabilidad puede calcularse como:

𝑝𝑖+ =

𝑛𝑖+

𝑛𝑖+ + 𝑛𝑖

−

siendo 𝑛𝑖

+ la cantidad de ejemplos positivos de 𝑆𝑖 y 𝑛𝑖− la cantidad de ejemplos

negativos.

La probabilidad 𝑝𝑖− se calcula en forma análoga a 𝑝𝑖

+, reemplazando la cantidad de ejemplos positivos por la cantidad de ejemplos negativos, y viceversa.

Generalizando la expresión anterior para cualquier tipo de ejemplos, obtenemos la fórmula general de la entropía:



H Si = −𝑝𝑖 log 𝑝𝑖

𝑛

𝑖=1

En todos los cálculos relacionados con la entropía, definimos 0 log 0 = 0.

Si la variable 𝑎𝑡 divide el conjunto 𝑆 en los subconjuntos 𝑆1, 𝑆2, … , 𝑆𝑛 , entonces

la entropía total del sistema de subconjuntos será:

H Si , 𝑎𝑡 = 𝑃 𝑆𝑖 ⋅ 𝐻 𝑆𝑖

𝑛

𝑖=1

donde 𝐻 𝑆𝑖 es la entropía del subconjunto 𝑆𝑖 y 𝑃 𝑆𝑖 es la probabilidad de que un ejemplo pertenezca a 𝑆𝑖 ; puede calcularse utilizando los tamaños relativos de los subconjuntos, como:

𝑃 𝑆𝑖 = 𝑆𝑖

𝑆

La ganancia en información puede calcularse como la disminución en entropía.

Es decir:

𝐼 𝑆, 𝑎𝑡 = 𝐻 𝑆 − 𝐻 𝑆, 𝑎𝑡 donde 𝐻 𝑆 es el valor de la entropía a priori, antes de realizar la subdivisión, y 𝐻 𝑆, 𝑎𝑡 es el valor de la entropía del sistema de subconjuntos generados por la partición según 𝑎𝑡. 2.2.2.2 Poda de los árboles generados

Existen varias razones para la poda de los árboles generados por los métodos de TDIDT [Michalski et al., 1998], entre ellas podemos nombrar la sobre-generalización, la evaluación de variables poco importantes o significativas, y el gran tamaño del árbol obtenido. En el primer caso, un árbol puede haber sido construido a partir de ejemplos con ruido, con lo cual algunas ramas del árbol pueden ser engañosas; en cuanto a la evaluación de variables no relevantes, éstas deben podarse ya que sólo agregan niveles en el árbol y no contribuyen a la ganancia de información. Por último, si el árbol obtenido es demasiado profundo o demasiado frondoso, se dificulta la interpretación por parte del usuario, con lo cual hubiera sido lo mismo utilizar un método de caja negra.

Existen dos enfoques para podar los árboles: la pre-poda (preprunning) y la post-poda (postprunning). En el primer caso se detiene el crecimiento del árbol cuando la ganancia de información producida al dividir un conjunto no supera un umbral determinado, en la post-poda se podan algunas ramas una vez que se ha terminado de construir el árbol. El primer enfoque, tiene la ventaja de que no se pierde tiempo en



construir una estructura que luego será simplificada en el árbol final; el método típico en estos casos es buscar la mejor manera de partir el subconjunto y evaluar la partición desde el punto de vista estadístico mediante la teoría de la ganancia de información, reducción de errores, etc., si esta evaluación es menor que un límite predeterminado, la división se descarta y el árbol para el subconjunto es simplemente la hoja más apropiada; sin embargo, este tipo de método tiene la contra de que no es fácil detener un particionamiento en el momento adecuado, un límite muy alto puede terminar con la partición antes de que los beneficios de particiones subsiguientes parezcan evidentes, mientras que un límite demasiado bajo resulta en una simplificación demasiado leve. El segundo enfoque utilizado por el ID3 y el C4.5, procede a la simplificación una vez construido el árbol según los criterios propios de cada uno de los algoritmos. 2.2.2.3 El Principio de longitud de descripción mínima (MDL)

El principio de longitud de descripción mínima (MDL) [Joachims et al., 1995; Mitchell, 2000; Quinlan, 1993c; Quinlan, 1995; Quinlan & Cameron-Jones, 1995] sostiene que la mejor teoría para un conjunto de datos es aquella que minimiza el tamaño de la teoría y la cantidad de información necesaria para especificar las excepciones, desde el punto de vista del aprendizaje automático esto significa que dado un conjunto de instancias, un sistema de aprendizaje infiere una teoría a partir de ellas; supóngase una analogía con el campo de las comunicaciones: la teoría con las excepciones debe ser transmitida por un canal perfecto. El MDL sostiene que la mejor generalización es aquella que requiere la menor cantidad de bits para transmitir la generalización junto con los ejemplos a partir de la cual fue generada. Esto evita las teorías que satisfacen los datos al extremo sobre-ajuste, ya que los ejemplos se transmiten también, y las teorías demasiado extensas serán penalizadas. Por otro lado, también se puede transmitir la teoría nula que no ayuda en lo más mínimo al transmitir los ejemplos. Entonces, pueden transmitirse tanto las teorías simples como aquellas muy complejas y el MDL provee una forma de medir la performance de los algoritmos basándose en los datos de entrenamiento únicamente. Esta parece ser la solución ideal al problema de medir la performance.

Veamos cómo se aplica el principio MDL. Supongamos que un sistema de aprendizaje genera una teoría 𝑇, basada en un conjunto de entrenamiento 𝐸, y requiere una cierta cantidad de bits 𝐿 𝑇 para codificar la teoría. Dada la teoría, el

conjunto de entrenamiento puede codificarse en una cantidad 𝐿 𝐸 𝑇 de bits. 𝐿 𝐸 𝑇

está dada por la función de ganancia de información sumando todos los miembros del conjunto de entrenamiento. La longitud de descripción total de la teoría es 𝐿 𝐸 +

𝐿 𝐸 𝑇 . El principio MDL recomienda la teoría 𝑇 que minimiza esta suma.

Hay que recordar que los algoritmos de la familia TDIDT realizan una búsqueda

en el espacio de hipótesis posibles, constituido por todos los árboles de decisión posibles. Su sesgo inductivo, siguiendo el principio de la Afeitadora de Occam, es una preferencia sobre los árboles pequeños frente a los árboles más profundos y frondosos.



2.2.3 Descripción general de los algoritmos

El algoritmo principal de los sistemas de la familia TDIDT, a la cual pertenecen el ID3 y su descendiente el C4.5, es el proceso de generación de un árbol de decisión inicial a partir de un conjunto de datos de entrenamiento. La idea original está basada en un trabajo de Hoveland y Hunt de los años ‘50, culminado en el libro Experiments in Induction [Hunt et al., 1966] que describe varios experimentos con varias implementaciones de sistemas de aprendizaje de conceptos (Concept Learning Systems – CLS). 2.2.3.1 División de los datos

El método “divide y reinarás” realiza en cada paso una partición de los datos del nodo según una prueba realizada sobre la “mejor” variable. Cualquier prueba que divida a 𝑇 en una manera no trivial, tal que al menos dos subconjuntos distintos 𝑇𝑖 no estén vacíos, eventualmente resultará en una partición de subconjuntos de una única clase, aún cuando la mayoría de los subconjuntos contengan un solo ejemplo. Sin embargo, el proceso de construcción del árbol no apunta meramente a encontrar cualquier partición de este tipo, sino a encontrar un árbol que revele una estructura del dominio y, por lo tanto, tenga poder predictivo. Para ello, se necesita un número importante de casos en cada hoja o, dicho de otra manera, la partición debe tener la menor cantidad de clases posibles. En el caso ideal, se busca elegir en cada paso la prueba que genere el árbol más pequeño; es decir, se busca un árbol de decisión compacto que sea consistente con los datos de entrenamiento. Para ello se pueden explorar todos los árboles posibles y elegir el más simple, pero desafortunadamente un número exponencial de árboles debería ser analizado. El problema de encontrar el árbol de decisión más pequeño consistente con un conjunto de entrenamiento es de complejidad NP-completa.

La mayoría de los métodos de construcción de árboles de decisión, incluyendo el C4.5 y el ID3, no permiten volver a estados anteriores, es decir, son algoritmos “golosos” sin vuelta atrás. Una vez que se ha escogido una prueba para particionar el conjunto actual, típicamente basándose en la maximización de alguna medida local de progreso, la partición se concreta y las consecuencias de una elección alternativa no se exploran. Por este motivo, la elección debe ser bien realizada. 2.2.3.1.1 Elección del criterio de división:

Para realizar la división de los datos en cada paso, Quinlan propone la utilización de los métodos de la teoría de la información. En un principio, el ID3 utilizaba la ganancia como criterio de división, sin embargo a partir de numerosas pruebas se descubrió que este criterio no era efectivo en todos los casos y se obtenían mejores resultados si se normalizaba el criterio en cada paso, por lo tanto, comenzó a



utilizarse la proporción de ganancia de información, con mayor éxito; a continuación se presentan ambos criterios. 2.2.3.1.1.1 Criterio de ganancia:

La definición de ganancia se presenta de la siguiente forma. Supongamos que tenemos una prueba posible con 𝑛 resultados que particionan al conjunto 𝑇 de entrenamiento en los subconjuntos 𝑇1, 𝑇2, … , 𝑇𝑛 . Si la prueba se realiza sin explorar las divisiones subsiguientes de los subconjuntos 𝑇𝑖 , la única información disponible para evaluar la partición es la distribución de clases en 𝑇 y sus subconjuntos.

Consideremos una medida similar luego de que 𝑇 ha sido particionado de acuerdo a los 𝑛 resultados de la prueba 𝑋. La información esperada (entropía) puede determinarse como la suma ponderada de los subconjuntos, de la siguiente manera:

𝐻 𝑇, 𝑋 = 𝑇𝑖

𝑇𝑥𝐻 𝑇𝑖

𝑛

𝑖=1

La cantidad 𝐼 𝑇, 𝑋 = 𝐻 𝑇 − 𝐻 𝑇, 𝑋 mide la información ganada al partir 𝑇

de acuerdo a la prueba 𝑋. El criterio de ganancia, entonces, selecciona la prueba que maximice la ganancia de información, es decir, antes de particionar los datos en cada nodo, se calcula la ganancia que resultaría de particionar el conjunto de datos según cada una de las variables posibles y se realiza la partición que resulta en la mayor ganancia. 2.2.3.1.1.2 Criterio de proporción de ganancia:

El criterio de ganancia tiene un defecto muy serio, y es que presenta una tendencia muy fuerte a favorecer las pruebas con muchos resultados. Analicemos una prueba sobre una variable que sea la clave primaria de un conjunto de datos, en la cual obtendremos un único subconjunto para cada caso y para cada subconjunto tendremos 𝐼 𝑇, 𝑋 = 0, entonces la ganancia de información será máxima. Desde el punto de vista de la predicción, este tipo de división no es útil.

Esta tendencia inherente al criterio de ganancia puede corregirse mediante una suerte de normalización, en la cual se ajusta la ganancia aparente atribuible a pruebas con muchos resultados. Consideremos el contenido de información de un mensaje correspondiente a los resultados de las pruebas. Por analogía a la definición de la 𝐼 𝑆 tenemos:

𝐼_𝑑𝑖𝑣𝑖𝑠𝑖ó𝑛 𝑋 = − 𝑇𝑖

𝑇 𝑥 log2

𝑇𝑖

𝑇

𝑛

𝑖=1



Esto representa la información potencial generada al dividir 𝑇 en 𝑛 subconjuntos, mientras que la ganancia de información mide la información relevante a una clasificación que nace de la misma división. Entonces:

𝑝𝑟𝑜𝑝𝑜𝑟𝑐𝑖ó𝑛_𝑑𝑒_𝑔𝑎𝑛𝑎𝑛𝑐𝑖𝑎 𝑋 =𝐼 𝑇, 𝑋

𝐼_𝑑𝑖𝑣𝑖𝑠𝑖ó𝑛 𝑋

expresa la proporción útil de información generada en la partición. Si la partición es casi trivial, la información de la división será pequeña y esta proporción se volverá inestable. Para evitar este fenómeno, el criterio de proporción de ganancia selecciona una prueba que maximice la expresión anterior, sujeta a la restricción de que la información de la división sea grande, al menos tan grande como la ganancia promedio sobre todas las pruebas realizadas. 2.2.3.2 Construcción de árboles 2.2.3.2.1 ID3

El algoritmo ID3, diseñado en 1993 por J. Ross Quinlan [Quinlan, 1993a, Quinlan, 1993b], toma objetos de una clase conocida y los describe en términos de una colección fija de propiedades o de variables, produciendo un árbol de decisión sobre estas variables que clasifica correctamente todos los objetos [Quinlan, 1993b]. Hay ciertas cualidades que diferencian a este algoritmo de otros sistemas generales de inferencia. La primera se basa en la forma en que el esfuerzo requerido para realizar una tarea de inducción crece con la dificultad de la tarea. El ID3 fue diseñado específicamente para trabajar con masas de objetos, y el tiempo requerido para procesar los datos crece sólo linealmente con la dificultad, como producto de:

La cantidad de objetos presentados como ejemplos.

La cantidad de variables dadas para describir estos objetos.

La complejidad del concepto a ser desarrollado (medido por la cantidad de nodos en el árbol de decisión).

Esta linealidad se consigue a costa del poder descriptivo ya que los conceptos

desarrollados por el ID3 sólo toman la forma de árboles de decisión basados en las variables dadas, y este “lenguaje” es mucho más restrictivo que la lógica de primer orden o la lógica multivaluada, en la cual otros sistemas expresan sus conceptos [Quinlan, 1993b].

El ID3 fue presentado como descendiente del CLS creado por Hunt y, como contrapartida de su antecesor, es un mecanismo mucho más simple para el descubrimiento de una colección de objetos pertenecientes a dos o más clases. Cada objeto debe estar descripto en términos de un conjunto fijo de variables, cada una de las cuales cuenta con su conjunto de posibles valores. Por ejemplo, la variable humedad puede tener los valores {alta, baja}, y la variable clima, {soleado, nublado, lluvioso}.



Una regla de clasificación en la forma de un árbol de decisión puede construirse

para cualquier conjunto 𝐶 de variables de esta forma [Quinlan, 1993b]:

Si 𝐶 está vacío, entonces se lo asocia arbitrariamente a cualquiera de las clases.

Si 𝐶 contiene los representantes de varias clases, se selecciona una variable y se particiona 𝐶 en conjuntos disjuntos 𝐶1, 𝐶2, … , 𝐶𝑛 , donde 𝐶𝑖 contiene aquellos miembros de 𝐶 que tienen el valor 𝑖 para la variable seleccionada. Cada uno de estos subconjuntos se maneja con la misma estrategia.

El resultado es un árbol en el cual cada hoja contiene un nombre de clase y

cada nodo interior especifica una variable para ser testeada con una rama correspondiente al valor de la variable. 2.2.3.2.1.1 Descripción del ID3

El objetivo del ID3 es crear una descripción eficiente de un conjunto de datos mediante la utilización de un árbol de decisión. Dados datos consistentes, es decir, sin contradicción entre ellos, el árbol resultante describirá el conjunto de entrada a la perfección. Además, el árbol puede ser utilizado para predecir los valores de nuevos datos, asumiendo siempre que el conjunto de datos sobre el cual se trabaja es representativo de la totalidad de los datos. Dados:

Un conjunto de datos.

Un conjunto de descriptores de cada dato.

Un clasificador/conjunto de clasificadores para cada objeto.

Se desea obtener un árbol de decisión simple basándose en la entropía, donde los nodos pueden ser:

Nodos intermedios: en donde se encuentran los descriptores escogidos según el criterio de entropía, que determinan cuál rama es la que debe tomarse.

Hojas: estos nodos determinan el valor del clasificador.

Este procedimiento de formación de reglas funcionará siempre, dado que no existen dos objetos pertenecientes a distintas clases pero con idéntico valor para cada uno de sus variables; si este caso llegara a presentarse, las variables son inadecuadas para el proceso de clasificación.

Hay dos conceptos importantes a tener en cuenta en el algoritmo ID3 [Blurock, 1996]: la entropía y el árbol de decisión. La entropía se utiliza para encontrar el parámetro más significativo en la caracterización de un clasificador. El árbol de decisión es un medio eficiente e intuitivo para organizar los descriptores que pueden ser utilizados con funciones predictivas.



2.2.3.2.1.2 Algoritmo ID3

A continuación se presenta el algoritmo del método ID3 para la construcción de árboles de decisión en función de un conjunto de datos previamente clasificados. Función ID3

(R: conjunto de atributos no clasificadores, C: atributo clasificador, S: conjunto de entrenamiento) devuelve un árbol de decisión;

Comienzo

Si S está vacío, Devolver un único nodo con Valor Falla;

Si todos los registros de S tienen el mismo valor para el atributo clasificador, Devolver un único nodo con dicho valor;

Si R está vacío, entonces Devolver un único nodo con el valor más frecuente del atributo clasificador en los registros de S [Nota: habrá errores, es decir, registros que no estarán bien clasificados en este caso];

Si R no está vacío, entonces D atributo con mayor Ganancia(D,S) entre los atributos de R; Sean {dj| j=1,2, .., m} los valores del atributo D; Sean {Sj| j=1,2, .., m} los subconjuntos de S correspondientes a los valores de dj respectivamente; Devolver un árbol con la raíz nombrada como D y con los arcos nombrados d1, d2,.., dm que van respectivamente a los árboles ID3(R-{D}, C, S1), ID3(R-{D}, C, S2), .., ID3(R-{D}, C, Sm);

Fin 2.2.3.2.1.3 Poda de los árboles de decisión

La poda de los árboles de decisión se realiza con el objetivo de que éstos sean más comprensibles, lo cual implica que tengan menos niveles y/o sean menos frondosos. La poda aplicada en el ID3 se realiza una vez que el árbol ha sido generado y es un mecanismo bastante simple: si de un nodo nacen muchas ramas, las cuales terminan todas en la misma clase, entonces se reemplaza dicho nodo por una hoja con la clase común, en caso contrario, se analizan todos los nodos hijos. 2.2.3.2.1.4 Limitaciones al ID3

El ID3 puede aplicarse a cualquier conjunto de datos, siempre y cuando las variables sean discretas. Este sistema no cuenta con la facilidad de trabajar con variables continuas ya que analiza la entropía sobre cada uno de los valores de una variable, por lo tanto, tomaría cada valor de una variable continua individualmente en el cálculo de la entropía, lo cual no es útil en muchos de los dominios. Cuando se trabaja con variables continuas, generalmente se piensa en rangos de valores y no en valores particulares.

Existen varias maneras de solucionar este problema del ID3, como la agrupación de valores presentada en [Gallion et al., 1993] o la discretización de los



mismos explicada en [Blurock, 1996; Quinlan, 1993c]. El C4.5 resolvió el problema de los atributos continuos mediante la discretización. 2.2.3.2.2 C4.5

El C4.5 se basa en el ID3, por lo tanto, la estructura principal de ambos métodos es la misma. El C4.5 construye un árbol de decisión mediante el algoritmo “divide y reinarás” y evalúa la información en cada caso utilizando los criterios de entropía y ganancia o proporción de ganancia, según sea el caso. A continuación, se explicarán las características particulares de este método que lo diferencian de su antecesor. 2.2.3.2.2.1 Algoritmo C4.5

El algoritmo del método C4.5 para la construcción de árboles de decisión es a grandes rasgos muy similar al del ID3. Varía en la manera en que realiza las pruebas sobre las variables, tal como se detalla en las secciones siguientes. Función C4.5

(R: conjunto de atributos no clasificadores, C: atributo clasificador, S: conjunto de entrenamiento) devuelve un árbol de decisión;

Comienzo

Si S está vacío, Devolver un único nodo con Valor Falla;

Si todos los registros de S tienen el mismo valor para el atributo clasificador, Devolver un único nodo con dicho valor;

Si R está vacío, entonces Devolver un único nodo con el valor más frecuente del atributo clasificador en los registros de S [Nota: habrá errores, es decir, registros que no estarán bien clasificados en este caso];

Si R no está vacío, entonces D atributo con mayor Proporción de Ganancia(D,S) entre los atributos de R; Sean {dj| j=1,2, .., m} los valores del atributo D; Sean {Sj| j=1,2, .., m} los subconjuntos de S correspondientes a los valores de dj respectivamente; Devolver un árbol con la raíz nombrada como D y con los arcos nombrados d1, d2,.., dm que van respectivamente a los árboles C4.5(R-{D}, C, S1), C4.5(R-{D}, C, S2), .., C4.5(R-{D}, C, Sm);

Fin 2.2.3.2.2.2 Características particulares del C4.5

En cada nodo, el sistema debe decidir cuál prueba escoge para dividir los datos. Los tres tipos de pruebas posibles propuestas por el C4.5 son [Quinlan, 1993c]:

1. La prueba “estándar” para las variables discretas, con un resultado y una rama para cada valor posible de la variable.



2. Una prueba más compleja, basada en una variable discreta, en donde los valores posibles son asignados a un número variable de grupos con un resultado posible para cada grupo, en lugar de para cada valor.

3. Si una variable 𝐴 tiene valores numéricos continuos, se realiza una prueba binaria con resultados 𝐴 ≤ 𝑍 y 𝐴 > 𝑍, para lo cual debe determinarse el valor límite 𝑍.

Todas estas pruebas se evalúan de la misma manera, mirando el resultado de la

proporción de ganancia, o alternativamente, el de la ganancia resultante de la división que producen. Ha sido útil agregar una restricción adicional: para cualquier división, al menos dos de los subconjuntos 𝑇𝑖 deben contener un número razonable de casos. Esta restricción, que evita las subdivisiones casi triviales, es tenida en cuenta solamente cuando el conjunto 𝑇 es pequeño. 2.2.3.2.2.3 Poda de los árboles de decisión

El método recursivo de particionamiento para construir los árboles de decisión descriptos anteriormente, subdividirá el conjunto de entrenamiento hasta que la partición contenga casos de una única clase, o hasta que la prueba no ofrezca mejora alguna. Esto da como resultado, generalmente, un árbol muy complejo que sobre-ajusta los datos al inferir una estructura mayor que la requerida por los casos de entrenamiento [Mitchell, 2000; Quinlan, 1995]. Además, el árbol inicial generalmente es extremadamente complejo y tiene una proporción de errores superior a la de un árbol más simple. Mientras que el aumento en complejidad se comprende a simple vista, la mayor proporción de errores puede ser más difícil de visualizar.

Para entender este problema, supongamos que tenemos un conjunto de datos con dos clases, donde una proporción 𝑝 ≥ 0,5 de los casos pertenecen a la clase mayoritaria. Si un clasificador asigna todos los casos con valores indeterminados a la clase mayoritaria, la proporción esperada de error es claramente 1 − 𝑝. Si, en cambio, el clasificador asigna un caso a la clase mayoritaria con probabilidad 𝑝 y a la otra clase con probabilidad 1 − 𝑝, su proporción esperada de error es la suma de:

La probabilidad de que un caso perteneciente a la clase mayoritaria sea asignado a la otra clase, 𝑝 1 − 𝑝 .

La probabilidad de que un caso perteneciente a la otra clase sea asignado a la clase mayoritaria, 1 − 𝑝 𝑝.

que da como resultado 2𝑝 1 − 𝑝 . Como 𝑝 es al menos 0,5, esto es generalmente superior a 1 − 𝑝, entonces el segundo clasificador tendrá una mayor proporción de errores. Un árbol de decisión complejo tiene una gran similitud con este segundo tipo de clasificador. Los casos no se relacionan a una clase, entonces, el árbol manda cada caso al azar a alguna de las hojas.

Un árbol de decisión no se simplifica borrando todo el árbol a favor de una rama, sino que se eliminan las partes del árbol que no contribuyen a la exactitud de la



clasificación para los nuevos casos, produciendo un árbol menos complejo, y por lo tanto, más comprensible.

2.2.4 Presentación de los resultados

Tanto el ID3 como el C4.5 generan un clasificador de la forma de un árbol de decisión, cuya estructura es [Quinlan 1993c]:

Una hoja, indicando una clase, o

Un nodo de decisión que especifica alguna prueba a ser realizada sobre un único atributo, con una rama y subárbol para cada valor posible de la prueba.

El árbol de decisión generado por el C4.5 cuenta con varias características

particulares, entre ellas cada hoja tiene asociados dos números, que indican el número de casos de entrenamientos cubiertos por cada hoja y la cantidad de ellos clasificados erróneamente por la hoja; es en cierta manera, un estimador del éxito del árbol sobre los casos de entrenamiento. El ID3, en cambio, no clasifica erróneamente a los datos de entrenamiento, con lo cual no son necesarios este tipo de indicadores; es por ello que este algoritmo, a diferencia del C4.5, corre el riesgo de caer en sobre-ajuste.


24 Ariel Kogan Descripción del Problema

3 Descripción del Problema

En este capítulo se presenta el problema a resolver, se fundamenta el porqué de su elección y se señala su importancia en el contexto de estudio.

La integración de agrupamiento e inducción como técnica de descubrimiento de conocimiento utilizada frecuentemente en trabajos de campo [Grosser et al., 2005; Britos et al., 2006; Cogliati et al., 2006; Ferrero et al., 2006; Salgueiro et al., 2006], no cuenta con estudios sobre resultados o lineamientos ni métricas que permitan optimizar su desempeño.

Por otra parte, dicha integración forma parte de estudios más abarcativos

[Rancán et al., 2007] que tienden a la integración entre sistemas basados en conocimiento y sistemas de descubrimiento de conocimiento. El mejoramiento de una base de conocimiento mediante la incorporación de piezas de conocimiento descubiertas de forma automática, puede conducir a la degradación de la base de conocimiento original. Es por eso que resulta necesario explorar la degradación de la calidad del proceso de descubrimiento de conocimiento mediante el uso de la integración de agrupamiento e inducción.

La no existencia de conceptualización de dominios que permita el estudio

sistemático de estos, es una limitación que debería ser tenida en cuenta al realizar cualquier estudio.

La ausencia de un sistema que permita la experimentación controlada en un

ambiente de laboratorio, presenta el desafío de proveer una solución para llevar adelante una experimentación sistemática con el objetivo de adquirir resultados para el análisis del problema a resolver.

En este contexto, puede plantearse el estudio del comportamiento de la integración de los algoritmos de agrupamiento por SOM e inducción por TDIDT como mecanismo de descubrimiento de conocimiento.


Solución Propuesta Ariel Kogan 25

4 Solución Propuesta

En este capítulo se describe la respuesta al problema planteado. Se identifican los parámetros del problema (sección 4.1), se plantean definiciones necesarias (sección 4.2) como el cubrimiento de una regla sobre otra (sección 4.2.1), el cubrimiento de una regla original por reglas descubiertas (sección 4.2.2) y el concepto de concentración de reglas que indican la pertenencia a una clase (sección 4.2.3). Se aborda el método de generación de casos de experimentación (sección 4.3) describiéndolo (sección 4.3.1) y dando un ejemplo para su mejor comprensión (sección 4.3.2). Finalmente, se realiza una descripción del Banco de Pruebas (sección 4.4), abordando sus funcionalidades (sección 4.4.1) y describiendo su dinámica de funcionamiento (sección 4.4.2).

4.1 Identificación de los parámetros del problema

No existe una conceptualización de dominios que permita el estudio sistemático de estos en términos de los parámetros que los rigen [Perez-Rey et al., 2004; Chen et al., 2005; Pandey y Mishra, 2005; Gupta et al., 2006; Song et al., 2006]. Es así como en esta sección se identifican los parámetros de este problema y se propone un método para la generación de dominios de manera controlada, de forma tal de emular dominios posibles para la aplicación de descubrimiento de conocimiento. Estos dominios deben ser generados en base a parámetros conocidos por el experimentador y permitir su variación con el objetivo de llevar adelante experimentos sobre dominios cualitativamente diferentes.

Los parámetros del problema que han sido identificados se muestran en la tabla 4.1:

Descripción del Parámetro Nemotécnico

Cantidad de atributos de cada ejemplo. attributesNumber

Cantidad de posibles valores que puede tomar cada atributo.

attPossibleValues

Cantidad de clases que rigen los ejemplos. classPossibleValues

Cantidad de reglas que indican la pertenencia a cada clase.

rulesPerClass

Cantidad de atributos sobre los cuales las reglas imponen condiciones.

attUsedInRule

Cantidad de ejemplos de cada regla. instancesByRule


26 Ariel Kogan Solución Propuesta

Porcentaje de la cantidad de valores posibles que puede tomar cada atributo, mediante el cual -para los atributos sobre los que se imponen condiciones- se generará un subconjunto de los valores posibles para cada atributo, de forma tal de establecer un subespacio correspondiente a una clase.

classAttPossibleValuesPercentage

Indicación de si los ejemplos se encuentran distribuidos aleatoriamente antes de ser procesadas por la combinación de SOM y TDIDT o no.

mix

Indicación de si se permite una concepción no estricta del cubrimiento de una regla o no.

allowMultipleCoverage

Porcentaje de desviación en la cantidad de instancias cubiertas, para considerar que la regla ha sido cubierta.

allowedCoverageDesviation

Cantidad de veces que se somete a la SOM el conjunto de datos, para entrenarla.

somTrainingIterationsMultiplier

Ancho del mapa SOM, cantidad de neuronas en horizontal

somMapWidth

Alto del mapa SOM, cantidad de neuronas en vertical

somMapHeight

Tabla ‎4.1: Parámetros identificados del problema

4.2 Definiciones

Para la mejor comprensión de cierta terminología utilizada en el presente trabajo, es útil realizar algunas definiciones.

4.2.1 Cubrimiento de una regla sobre otra

Para el presente trabajo, se ha definido un criterio para determinar si una regla es cubrimiento de otra. El mismo consiste en:



Criterio de cubrimiento de una regla sobre otra

Comparando cada uno de los atributos de las reglas entre sí, se debe cumplir para todos los atributos que si la regla a cubrir impone condiciones y la regla que cubre también lo hace, las condiciones deben ser las mismas.

Considérese un caso en el que se tienen las siguientes 2 reglas:

Regla que cubre:

𝑎1 𝑎2 𝑎3 𝒂𝟒 = 𝒗𝟐 𝑎5 𝒂𝟔 = 𝒗𝟑

Regla a cubrir:

𝑎1 𝒂𝟐 = 𝒗𝟏 𝑎3 𝒂𝟒 = 𝒗𝟐 𝑎5 𝑎6

De acuerdo al criterio expuesto, la primera sí cubre a la segunda: La regla que

cubre no impone condiciones sobre el 2º atributo, mientras que la regla a cubrir sí lo hace. Esto no es un problema ya que la regla a cubrir es más específica que la regla que cubre. En el caso del 4º atributo, ambas reglas imponen condiciones y éstas son las mismas. En el caso del 6º atributo, la regla que cubre impone condiciones, pero la regla a cubrir no. Esto quiere decir que según la regla a cubrir, el valor del 6º atributo de sus ejemplos no está condicionado, mientras que para la regla que cubre sí lo está.

Supóngase la siguiente situación. Sean:

Regla que cubre:

* * * 7 * 5

Regla a cubrir:

* 3 * 7 * *

Y considérese el siguiente ejemplo:

1 3 2 7 3 4

Este ejemplo cumple con la regla a cubrir, pero no con la regla que cubre, ya

que el valor del 6º atributo no es 5. Sin embargo, como se dijo, bajo el criterio definido para el presente trabajo, la primera regla sí cubre a la segunda.

El motivo por el cual el criterio utilizado para el presente trabajo hace esta concesión se debe a que, de acuerdo a lo observado de forma experimental, la determinación al azar de los valores de los atributos libres, puede arrojar ejemplos en los cuales varias veces se repite el mismo valor. Es decir que para la original:



Supuesta regla original

Se pueden generar ejemplos como:

Supuesto ejemplo 1 Supuesto ejemplo 2 Supuesto ejemplo 3

Y tras el proceso de educción de conocimiento, obtener una regla:

Supuesta regla descubierta

La regla descubierta no impone condiciones sobre el 2º atributo porque quizás

haciéndolo sobre el 4º ya logró determinar un grupo de ejemplos. Sin embargo, la coincidencia que el 6º atributo de los ejemplos haya tomado el mismo valor para todos ellos, bien pudo haber provocado que la regla descubierta imponga condiciones sobre este atributo ya que no hay manera de controlar dicha coincidencia y diferenciarla de un patrón intencionado.

Se observó que si no se realizaba esta concesión al criterio de cubrimiento de una regla sobre otra, el análisis de la cantidad de reglas cubiertas de forma correcta no resultaba preciso.

4.2.2 Cubrimiento de una regla original por reglas descubiertas Experimentalmente se observó que las reglas descubiertas no necesariamente imponían condiciones sobre los mismos atributos que las reglas originales. Sin embargo, era posible notar que -a pesar de imponer condiciones sobre otros atributos- las reglas eran cubrimiento del mismo conjunto de ejemplos. Es así como no se pudo utilizar como criterio de cubrimiento entre reglas, el hecho que impongan las condiciones sobre los mismos atributos. El proceso utilizado fue el siguiente:

1. Para cada una de las reglas originales, se toma del conjunto de reglas descubiertas aquellas que la cubren.

2. Se suma la cantidad de ejemplos que responden al conjunto de reglas descubiertas determinado en el paso 2.

* 3 * 7 * *

6 3 4 7 1 5

4 3 1 7 3 5

2 3 5 7 8 5

* * * 7 * 5



3. Si la suma de ejemplos computada en el paso 2 está comprendida entre la cantidad de ejemplos que se sabe se generaron para la regla original y esta cantidad sumada a una desviación, se considera que la regla original ha sido correctamente cubierta.

La condición del paso 3 responde a los siguientes criterios:

Para considerar que una regla original ha sido correctamente cubierta, las reglas descubiertas que la cubren deben cubrir al menos la misma cantidad de ejemplos que la regla original.

Debido a que las reglas descubiertas no necesariamente imponen condiciones sobre los mismos atributos que la regla original, es posible que cubran ciertos ejemplos que no eran cubrimiento de la regla original. Sin embargo, es posible aceptar una cierta desviación en el cubrimiento. Esta desviación puede ser modelada como un cierto porcentaje de la cantidad de ejemplos que cubría la regla original. Este porcentaje corresponde al parámetro allowedCoverageDesviation.

4.2.3 Concentración de las reglas que indican la pertenencia a cada clase

Para la definición de la concentración de las reglas que indican la pertenencia a

cada clase, es útil hacer uso de la figura 4.1, la cual define gráficamente una clase que rige el dominio.

A6A5A4A3A2A1

v8

v7

v6

v5

v4

v3

v2

v1

v8

v7

v6

v5

v4

v3

v2

v1

v8

v7

v6

v5

v4

v3

v2

v1

v8

v7

v6

v5

v4

v3

v2

v1

v8

v7

v6

v5

v4

v3

v2

v1

v8

v7

v6

v5

v4

v3

v2

v1

Figura ‎4.1: Definición gráfica de una clase que rige el dominio



Esta clase impone condiciones de “es igual” únicamente sobre los atributos A2 y A4. En el caso del atributo A2, las condiciones pueden ser con los valores v1, v3, v4 y v7, mientras que con el atributo A4, pueden ser con los valores v2, v5, v7 y v8.

Las reglas que pueden ser formuladas para esta clase, pueden imponer 4 condiciones distintas de “es igual” sobre los atributos sobre los cuales se imponen condiciones, existiendo 8 valores para cada atributo. Si se pudieran imponer únicamente 3 condiciones distintas de “es igual” con los mismos 8 valores posibles por cada atributo, las reglas que indicaran la pertenencia a esta clase, estarían más concentradas.

Esta proporción entre los valores posibles que puede tomar un atributo sobre el que se imponen condiciones y la cantidad de valores posibles que puede tomar cada atributo, corresponde al parámetro classAttPossibleValuesPercentage.

Es así como:

A mayor classAttPossibleValuesPercentage, menor concentración de las reglas que indican la pertenencia a cada clase.

A menor classAttPossibleValuesPercentage, mayor concentración de las reglas

que indican la pertenencia a cada clase.

4.3 Método de generación de casos de experimentación

4.3.1 Descripción del método 4.3.1.1 Conjuntos utilizados

Sea 𝑉 = 𝑣1, 𝑣2 , … , 𝑣𝑎𝑡𝑡𝑃𝑜𝑠𝑠𝑖𝑏𝑙𝑒𝑉𝑎𝑙𝑢𝑒𝑠 el conjunto de valores posibles que puede tomar cada atributo, de cardinalidad 𝑉 = 𝑎𝑡𝑡𝑃𝑜𝑠𝑠𝑖𝑏𝑙𝑒𝑉𝑎𝑙𝑢𝑒𝑠 y que verifica que ∀𝑖 ≠ 𝑗, 𝑣𝑖 ≠ 𝑣𝑗 .

Sea 𝑥 = 𝑎1, 𝑎2, … , 𝑎𝑎𝑡𝑡𝑟𝑖𝑏𝑢𝑡𝑒𝑠𝑁𝑢𝑚𝑏𝑒𝑟 un ejemplo del dominio compuesto por

attributesNumber atributos que verifican que ∀𝑖, 𝑎𝑖 ∈ 𝑉.

Sea 𝐶 = 𝑐1, 𝑐2, … , 𝑐𝑐𝑙𝑎𝑠𝑠𝑃𝑜𝑠𝑠𝑖𝑏𝑙𝑒𝑉𝑎𝑙𝑢𝑒𝑠 el conjunto de clases que rigen el dominio, de cardinalidad 𝐶 = 𝑐𝑙𝑎𝑠𝑠𝑃𝑜𝑠𝑠𝑖𝑏𝑙𝑒𝑉𝑎𝑙𝑢𝑒𝑠.

Sea 𝐺𝑐𝑖= 𝑔1

𝑐𝑖 , 𝑔2𝑐𝑖 , … , 𝑔𝑎𝑡𝑡𝑈𝑠𝑒𝑑𝐼𝑛 𝑅𝑢𝑙𝑒

𝑐𝑖 el conjunto de subíndices de los atributos

sobre los que se imponen condiciones para la generación de las reglas que indican la

pertenencia a la clase 𝑐𝑖 , de cardinalidad 𝐺𝑐𝑖 = 𝑎𝑡𝑡𝑈𝑠𝑒𝑑𝐼𝑛𝑅𝑢𝑙𝑒.

Considerando:

𝑐𝑙𝑎𝑠𝑠𝐴𝑡𝑡𝑃𝑜𝑠𝑠𝑖𝑏𝑙𝑒𝑉𝑎𝑙𝑢𝑒𝑠 =𝑎𝑡𝑡𝑃𝑜𝑠𝑠𝑖𝑏𝑙𝑒𝑉𝑎𝑙𝑢𝑒𝑠 ×𝑐𝑙𝑎𝑠𝑠𝐴𝑡𝑡𝑃𝑜𝑠𝑠𝑖𝑏𝑙𝑒𝑉𝑎𝑙𝑢𝑒𝑠𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑎𝑔𝑒

100, sea

𝑊𝑎𝑔

𝑗

𝑐𝑖= 𝑤1

𝑎𝑔

𝑗

𝑐𝑖

, 𝑤2

𝑎𝑔

𝑗

𝑐𝑖

, … , 𝑤𝑐𝑙𝑎𝑠𝑠𝐴𝑡 𝑡𝑃𝑜𝑠𝑠𝑖𝑏𝑙𝑒𝑉𝑎𝑙𝑢𝑒𝑠

𝑎𝑔

𝑗

𝑐𝑖

el conjunto de posibles valores que



puede tomar el atributo 𝑎𝑔

𝑗

𝑐𝑖 sobre el que se imponen condiciones para la generación

de las reglas que indican la pertenencia a la clase 𝑐𝑖 , de cardinalidad 𝑊𝑎𝑔

𝑗

𝑐𝑖 =

𝑐𝑙𝑎𝑠𝑠𝐴𝑡𝑡𝑃𝑜𝑠𝑠𝑖𝑏𝑙𝑒𝑉𝑎𝑙𝑢𝑒𝑠.

Se define la cantidad de elementos del conjunto 𝑅 de reglas que indicarán la pertenencia a cada una de las clases (rulesPerClass).

Sea 𝑅𝑐𝑖= 𝑟1

𝑐𝑖 , 𝑟2𝑐𝑖 , … , 𝑟𝑟𝑢𝑙𝑒𝑠𝑃𝑒𝑟𝐶𝐿𝑎𝑠𝑠

𝑐𝑖 el conjunto de reglas que indican la

pertenencia a la clase 𝑐𝑖 , de cardinalidad 𝑅𝑐𝑖 = 𝑟𝑢𝑙𝑒𝑠𝑃𝑒𝑟𝐶𝑙𝑎𝑠𝑠 y que verifica que

∀𝑗 ≠ 𝑘, 𝑟𝑗𝑐𝑖 ≠ 𝑟𝑘

𝑐𝑖 . Cada regla es de la forma 𝑟𝑘𝑐𝑖 = 𝑎

𝑔1

𝑐𝑖 , 𝑎𝑔2

𝑐𝑖 , … , 𝑎𝑔𝑎𝑡𝑡𝑈𝑠𝑒𝑑𝐼𝑛𝑅𝑢𝑙𝑒

𝑐𝑖 donde

𝑎𝑔

𝑗

𝑐𝑖 ∈ 𝑊𝑎𝑔

𝑗

𝑐𝑖.

Sea 𝐸𝑟𝑘

𝑐𝑖 = 𝑒1

𝑟𝑘

𝑐𝑖

, 𝑒2

𝑟𝑘

𝑐𝑖

, … , 𝑒𝑖𝑛𝑠𝑡𝑎𝑛𝑐𝑒𝑠𝐵𝑦𝑅𝑢𝑙𝑒

𝑟𝑘

𝑐𝑖

el conjunto de ejemplos que da

soporte a la regla 𝑟𝑘𝑐𝑖 , de cardinalidad 𝐸

𝑟𝑘

𝑐𝑖 = 𝑖𝑛𝑠𝑡𝑎𝑛𝑐𝑒𝑠𝐵𝑦𝑅𝑢𝑙𝑒, donde cada ejemplo

es de la forma 𝑒𝑟𝑘

𝑐𝑖 = 𝑎𝑚 ∈ 𝑊𝑎𝑚/𝑚 ∈ 𝐺𝑐𝑖

∪ 𝑎𝑚 ∈ 𝑉/𝑚 ∉ 𝐺𝑐𝑖 .

Sea 𝑅 = 𝑅𝑐𝑖

𝑐𝑙𝑎𝑠𝑠𝑃𝑜𝑠𝑠𝑖𝑏𝑙𝑒𝑉𝑎𝑙𝑢𝑒𝑠𝑖=1 el conjunto total de reglas que rigen al dominio.

Sea 𝐸𝑐𝑖= 𝐸

𝑟𝑘

𝑐𝑖𝑟𝑢𝑙𝑒𝑠𝑃𝑒𝑟𝐶𝑙𝑎𝑠𝑠𝑘=1 el conjunto de ejemplos que da soporte a las

reglas que indican la pertenencia a la clase 𝑐𝑖 .

Sea 𝐸 = 𝐸𝑐𝑖

𝑐𝑙𝑎𝑠𝑠𝑃𝑜𝑠𝑠𝑖𝑏𝑙𝑒𝑉𝑎𝑙𝑢𝑒𝑠𝑖=1 el conjunto total de ejemplos que da soporte al

conjunto de reglas 𝑅.

Sea 𝑅′ el conjunto de reglas que se obtiene como resultado de aplicar a 𝐸 agrupamiento seguido por inducción de reglas mediante TDIDT.

Sea 𝑅′′ = 𝑟 ∈ 𝑅/∃𝑟∗ ∈ 𝑅′ ∧ 𝑟∗𝑒𝑠 𝑐𝑢𝑏𝑟𝑖𝑚𝑖𝑒𝑛𝑡𝑜 𝑑𝑒 𝑟 el conjunto de reglas originales que son cubiertas por las reglas generadas. El cubrimiento es de acuerdo a lo definido en la sección 4.2.2. 4.3.1.2 Pasos del método

El método de generación de experimentos consta de los siguientes pasos:

1. Se define el conjunto 𝑉 de valores posibles que podrá tomar cada atributo.

2. Se establece la cantidad de atributos que compondrán los ejemplos del dominio, definiendo así la forma de 𝑥.



3. Se define la cantidad de clases que regirán al dominio y se construye el conjunto 𝐶.

4. Se define la cantidad de atributos sobre los que se impondrán condiciones para la generación de las reglas que indican la pertenencia a cada clase, respetando siempre que 𝑎𝑡𝑡𝑈𝑠𝑒𝑑𝐼𝑛𝑅𝑢𝑙𝑒 < 𝑎𝑡𝑡𝑟𝑖𝑏𝑢𝑡𝑒𝑠𝑁𝑢𝑚𝑏𝑒𝑟.

5. Para cada clase se construye su conjunto 𝐺𝑐𝑖 y para cada atributo

correspondiente se construye su conjunto 𝑊𝑎𝑔

𝑗

𝑐𝑖. Se construyen las reglas que

conformarán el conjunto 𝑅𝑐𝑖, así como el conjunto de ejemplos 𝐸𝑐𝑖

que da

soporte a estas reglas.

6. Se construye el conjunto 𝑅 de todas las reglas y el conjunto 𝐸 de todos los ejemplos.

7. Se aplica a 𝐸 agrupamiento por SOM e inducción de reglas por TDIDT y se obtiene el conjunto de reglas resultado 𝑅′.

8. Se determina el conjunto de reglas pertenecientes a 𝑅 que son cubiertas por reglas pertenecientes a 𝑅′ y se genera el conjunto 𝑅′′.

9. Se determina el porcentaje de reglas cubiertas de forma correcta: ℵ = 𝑅′′

𝑅 ×

100.

4.3.2 Ejemplo de generación de un caso de experimentación

Para una mejor comprensión del significado de algunos de los parámetros del problema, se propone un ejemplo de generación de un dominio, para dejar de manifiesto el papel que juega cada uno de estos en la ejecución del experimento. La siguiente tabla indica los valores asignados a algunos de los parámetros:

Parámetro Valor

attributesNumber 6 attPossibleValues 8 classPossibleValues 5 rulesPerClass 4 instancesByRule 10 attUsedInRule 2 classAttPossibleValuesPercentage 50



La primera característica constructiva es la cantidad de atributos de cada regla (attributesNumber), la cual es igual para los ejemplos. En este caso es 6, por lo que las reglas y los ejemplos serán de la forma:

A6A5A4A3A2A1

Figura ‎4.2: Atributos de un ejemplo del dominio

Cada uno de los atributos, puede tomar 8 valores posibles (attPossibleValues):

A6A5A4A3A2A1

87

65

43

21

87

65

43

21

87

65

43

21

87

65

43

21

87

65

43

21

87

65

43

21

Figura ‎4.3: Valores posibles que pueden tomar los atributos de un ejemplo

Hasta aquí cada uno de los ejemplos es libre de tomar en cada uno de sus

atributos, alguno de los valores posibles. Geométricamente, cada ejemplo puede ser visto como un punto en un

hiperespacio de 6 dimensiones, en el cual cada una de sus coordenadas puede tomar un valor que va del 1 al 8.

Con el objetivo de generar ejemplos que respondan a patrones comunes, se imponen limitaciones sobre el hiperespacio de modo tal de crear “nubes” que agrupen a los ejemplos de cada patrón.

La clase es la primera limitación a los ejemplos. De acuerdo a lo definido en el presente trabajo, ésta consiste en determinar al azar cuáles son los atributos sobre los que se impondrán condiciones y para cada uno de estos, determinar también al azar cuáles son los valores posibles que podrá tomar cada atributo.

Una representación gráfica de una clase se sintetiza en la figura 4.4:



A6A5A4A3A2A1

87

65

43

21

87

65

43

21

87

65

43

21

87

65

43

21

87

65

43

21

87

65

43

21

Figura ‎4.4: Definición gráfica de una clase que rige el dominio

Los atributos griseados son aquellos sobre los cuales la clase impone

condiciones. Estos son 2, tal como indica el parámetro attUsedInRule. Para la presente clase, cada uno de estos puede tomar determinados valores, los cuales son elegidos al azar entre los valores posibles que pueden tomar cada uno de los atributos. Tanto A2 como A4 pueden tomar 4 valores, número que corresponde al 50% de la cantidad total de valores posibles, así como lo indica el parámetro classAttPossibleValuesPercentage.

Una vez definida la clase, es necesario definir las reglas que indican la

pertenencia a ésta. Las reglas de una clase impondrán condiciones sobre los mismos atributos que lo hace la clase, pero se tratarán de condiciones de “es igual” a alguno de los valores posibles para dicho atributo, elegido al azar. Es así como un conjunto de posibles reglas de la clase anterior son:

* 1 * 5 * *

* 3 * 7 * *

* 4 * 7 * *

* 3 * 2 * *

Figura ‎4.5: Definición gráfica de reglas que indican la pertenencia a una clase



La forma de leer estas reglas es la siguiente: Considerando la primera de las reglas, ésta puede ser leída como “Si A2 = 1 y A4 = 5, entonces el ejemplo pertenece a la clase”.

Para cada una de las clases, se generan rulesPerClass reglas. Los atributos marcados con un asterisco, son libres de tomar cualquiera de los (8 en este caso) valores posibles. El último paso restante para la generación del dominio es generar los ejemplos que darán soporte a cada regla. Estos provienen simplemente de tomar valores al azar -entre los valores posibles- para cada uno de los atributos marcados con un asterisco, y dejar siempre en el valor consignado aquellos atributos que en la figura 4.5 aparecen griseados. Para cada regla, se generan instancesByRule ejemplos. Cabe la posibilidad que un ejemplo responda a más de una regla. Si se supone que se tienen las siguientes 2 reglas, las cuales pertenecen a 2 clases distintas:

* 3 * 7 * *

* * 1 * * 5

Y el siguiente ejemplo:

4 3 1 7 2 5

Es simple apreciar que ambas reglas cubren el ejemplo. Esta situación puede ser deseable o no. Mediante el parámetro allowMultipleCoverage se indica al banco de pruebas si se desea trabajar de esta manera o no. En los experimentos realizados para esta tesis, se determinó que cada ejemplo podía responder a una única regla.

4.4 Descripción del Banco de Pruebas

El banco de pruebas es la herramienta utilizada para llevar adelante la experimentación. Es posible configurar el banco de pruebas mediante el ajuste de sus parámetros, para realizar distintos experimentos.

La fijación de los valores de los parámetros del banco de pruebas es la que permite convertir la experiencia en un ambiente controlado de experimentación.

4.4.1 Funcionalidades

El Banco de Pruebas provee las siguientes funcionalidades:



4.4.1.1 Definición de dominios

De acuerdo a los valores que toman los parámetros identificados en la sección 4.1, el banco de pruebas es capaz de construir la definición de un dominio. Esta definición responde a la modelización que se ha realizado estableciendo los valores de los parámetros y generando al azar la información faltante.

Es así como el banco de pruebas provee la funcionalidad de definir dominios en condiciones de laboratorio, en base a la modelización que se quiera imponer sobre estos. 4.4.1.2 Generación de ejemplos

Para los dominios definidos por el banco de pruebas, éste es capaz de generar un conjunto de ejemplos que dé soporte a cada uno de estos. 4.4.1.3 Agrupamiento por SOM

Una de las operaciones que permite efectuar el banco de pruebas es el agrupamiento y la formación de clusters mediante el algoritmo de redes neuronales SOM. 4.4.1.4 Inducción por TDIDT

Para un conjunto de ejemplos, el banco de pruebas permite la aplicación de algoritmos de inducción de reglas haciendo uso de los árboles de inducción TDIDT, con el objetivo de obtener reglas que lo caractericen. 4.4.1.5 Contrastación de reglas

El banco de pruebas permite establecer la cantidad de reglas de un conjunto A que son correctamente cubiertas por las reglas de un conjunto B, de acuerdo a las definiciones establecidas en la sección 4.2.

El método de contrastación de reglas que emplea el banco de pruebas, responde a los siguientes lineamientos:

Debe concordar con los criterios comúnmente utilizados en las prácticas de descubrimiento de conocimiento.

Debe ser útil para la evaluación sobre dominios generados, con las problemáticas que esto pueda llegar a provocar.

Debe ser simple de evaluar y claro de comprender.



4.4.2 Dinámica del Banco de Pruebas

La dinámica de trabajo del banco de pruebas consiste en realizar un experimento en 3 pasos. El mismo se describe a continuación:

Generación de ejemplos:

Generación de ejemplos que

dan soporte a cada una de las

reglas.

Generación del dominio:

Generación de clases.

Generación de reglas

que indican la

pertenencia a cada

clase.

Reglas de clasificación

Si ………………….

………………….

Entonces ………...

Si ………………….

………………….


Reglas descubiertas

Si ………………….

………………….


Si ………………….

………………….


INDUCCIÓN

Ejemplos del dominio

AGRUPAMIENTO

Ejemplos del dominio

Grupos (clases) formados a partir de los

ejemplos del dominio

Paso 1:

PREPARACIÓN DEL

EXPERIMENTO

Paso 2:

EJECUCIÓN DEL

EXPERIMENTO

Paso 3:

COMPARACIÓN DE

LOS CONJUNTOS DE

REGLAS

Figura ‎4.6: Experimento en 3 pasos

1. Preparación del Experimento. a. Generación del dominio basada en la generación de clases y reglas que

indican la pertenencia a cada una de éstas. b. Generación de ejemplos que den soporte a cada una de las reglas de

clasificación.

Como salida de este paso se obtiene un conjunto de reglas de clasificación y un conjunto de ejemplos del dominio que dan soporte a éstas.

2. Ejecución del Experimento. a. Aplicación del proceso de agrupamiento al conjunto de ejemplos del

dominio para obtener el conjunto de sus clusters (grupos).



b. Aplicación a cada cluster del proceso de inducción para obtener reglas que caractericen la pertenencia a dicho cluster.

Como salida de este paso se obtiene el conjunto de reglas descubiertas.

3. Comparación entre el conjunto de reglas de clasificación del paso 1 y las reglas descubiertas en el paso 2. El porcentaje de reglas descubiertas de forma correcta, define el éxito del experimento.


Experimentación Ariel Kogan 39

5 Experimentación

En este capítulo se exponen los resultados obtenidos de los experimentos realizados. Se han definido los parámetros a variar (sección 5.1), delimitado el universo de estudio (sección 5.2), determinado un dominio patrón (sección 5.3) y establecido el formato de los resultados a obtener (sección 5.4). Se ha definido una estrategia de aspectación de valores de variables (sección 5.5) en base a requerimientos sobre ésta (sección 5.5.1), habiéndose adoptado una solución en particular (sección 5.5.2). Para esta solución, se han determinado los pares de variables a estudiar (sección 5.5.3) y se ha confeccionado un diccionario de variables dependientes e independientes según el enfoque adoptado (5.5.4) para una comprensión más clara.

Finalmente se han analizado e interpretado los experimentos (sección 5.6) y se han sistematizado las proposiciones experimentales formuladas (sección 5.7), tanto para el enfoque orientado al dominio (sección 5.7.1) como para el enfoque orientado a los ejemplos (sección 5.7.2).

5.1 Definición de Variables

De acuerdo a la demarcación del alcance del presente trabajo, se han establecido cuáles de los parámetros identificados del problema se estudiarán como variables del experimento y cuáles se fijarán en un valor invariante a lo largo de la ejecución de todos los experimentos.

A continuación se indica el carácter de variable o no de cada uno de los

parámetros:

Nemotécnico Descripción del Parámetro Variable

attributesNumber Cantidad de atributos de cada ejemplo. Sí

attPossibleValues Cantidad de posibles valores que puede tomar cada atributo.

Sí

classPossibleValues Cantidad de clases que rigen los ejemplos.

Sí

rulesPerClass Cantidad de reglas que indican la pertenencia a cada clase.

Sí

attUsedInRule Cantidad de atributos sobre los cuales las reglas imponen condiciones.

Sí

instancesByRule Cantidad de ejemplos de cada regla. Sí


40 Ariel Kogan Experimentación

classAttPossibleValuesPercentage Porcentaje de la cantidad de valores posibles que puede tomar cada atributo, mediante el cual -para los atributos sobre los que se imponen condiciones- se generará un subconjunto de los valores posibles para cada atributo, de forma tal de establecer un subespacio correspondiente a una clase.

Sí

mix Indicación de si los ejemplos se encuentran distribuidos aleatoriamente antes de ser procesadas por la combinación de SOM y TDIDT o no.

No

allowMultipleCoverage Indicación de si se permite una concepción no estricta del cubrimiento de una regla o no.

No

allowedCoverageDesviation Porcentaje de desviación en la cantidad de instancias cubiertas, para considerar que la regla ha sido cubierta.

No

somTrainingIterationsMultiplier Cantidad de veces que se somete a la SOM el conjunto de datos, para entrenarla.

No

somMapWidth Ancho del mapa SOM, cantidad de neuronas en horizontal

No

somMapHeight Alto del mapa SOM, cantidad de neuronas en vertical

No

Tabla ‎5.1: Definición de variabilidad o no de cada uno de los parámetros

5.2 Delimitación del Universo de Estudio

Para las variables de estudio, se ha definido un rango de valores posibles. Esta delimitación consiste en la demarcación del universo de estudio, el espacio dentro del cual se variarán sus valores en busca del estudio de su conducta. En la tabla 5.2 se detallan las variables, sus valores mínimos, máximos, los correspondientes a un escenario medio y 5 valores discretos distribuidos en el rango determinado:



Variable (nemotécnico) Mín Máx Med

attributesNumber 3 10 6 2 4 6 8 10 attPossibleValues 1 100 20 20 40 60 80 100 classPossibleValues 1 10 5 1 3 5 7 10 rulesPerClass 1 15 5 1 4 8 12 15 instancesByRule 1 20 10 1 5 10 15 20 attUsedInRule (%) 1 100 50 20 40 60 80 100 classAttPossibleValuesPercentage 1 100 20 20 40 60 80 100

Tabla ‎5.2: Rango de variación de las variables

La selección de los rangos de variación de cada una de las variables responde a

los siguientes criterios:

Criterios computacionales: Valores elevados de algunas variables (ej: attributesNumber) tienen un efecto notorio en la velocidad con la que se ejecutan los experimentos y a partir de determinados niveles, los tiempos de ejecución se tornan prohibitivos al trabajar con una plataforma de cómputo pequeña.

Nociones empíricas sobre los escenarios comunes de descubrimiento de conocimiento: De acuerdo a la experiencia de algunos de los integrantes del grupo de investigación en el que se enmarca este trabajo, en aplicaciones reales de descubrimiento de conocimiento, ciertas variables suelen tomar determinados rangos (ej: classPossibleValues, rulesPerClass).

Saturación del dominio: El dominio de posibles ejemplos es finito y condicionado al valor que toman ciertos parámetros. Es así como para evitar la saturación del dominio y la imposibilidad de ejecutar ciertos experimentos, se limitó la cantidad de ejemplos con la cual se trabajó (ej: instancesByRule, rulesPerClass, classPossibleValues).

Porcentajes: Algunas variables están expresadas en porcentaje, por lo que su rango natural de variación es de 0 a 100, aunque se considerará de 1 a 100 ya que el valor 0 no tiene sentido práctico de aplicación de los conceptos correspondientes.

La selección de los 5 valores discretos que se proponen para el rango de

variación de cada variable, responde únicamente a procurar una distribución uniforme



en dicho rango y serán los utilizados para cuando la variable sea el parámetro de serie en un experimento.

La selección de los valores medios da lugar al denominado “dominio patrón”, el

cual es descripto a continuación.

5.3 Dominio Patrón

Debido a la gran complejidad de estudiar el efecto de la variación simultánea de todas las variables, se decidió definir un dominio patrón para ser utilizado como punto de partida del estudio de variaciones de 1 ó 2 variables a la vez.

Los criterios por los cuales fueron establecidos los valores de los parámetros para el dominio patrón son:

Similitud con dominios reales de descubrimiento de conocimiento: De acuerdo a la experiencia de algunos de los integrantes del grupo de investigación en el que se enmarca este trabajo, es posible encontrar en la práctica habitual de proyectos de descubrimiento de conocimiento, dominios similares al dominio patrón definido.

Dominio sin saturar: Se ha buscado que el dominio patrón seleccionado sea un dominio en el que los ejemplos no saturen el espacio disponible, ya que experimentalmente se ha observado que esta situación genera una limitación muy importante para las prácticas de descubrimiento de conocimiento con el método propuesto.

Bajo esfuerzo de cómputo: Debido a que el dominio patrón es empleado como punto de partida en todos los experimentos, se busca que cumpla con las condiciones antes mencionadas, pero que a la vez genere un esfuerzo de cómputo lo más bajo posible.

5.4 Formato de los Resultados

El objetivo de los experimentos llevados adelante en el presente trabajo, es determinar cuántas de las reglas pertenecientes al conjunto original han sido cubiertas de forma correcta por las reglas descubiertas mediante la aplicación del método propuesto. Debido a la dificultad de representar la información obtenida de una experimentación en más de 2 dimensiones, así como la complejidad de analizar un fenómeno de múltiples parámetros que varían a la vez, es que se ha decidido definir para cada experimento un parámetro que varíe en el espectro de todos sus valores posibles y otro en una serie de valores predefinidos, manteniéndose todos los demás constantes.



Para una explicación más clara, se toma como ejemplo una de las gráficas que más adelante será analizada en profundidad. El objetivo en la presente instancia es comprender la gráfica como método de presentación de los resultados.

Figura ‎5.1: Ejemplo de una de las gráficas como resultado de un experimento. Estudio de dominios variando la cantidad de reglas que indican la pertenencia a cada clase, para distinta cantidad de

atributos que tienen las reglas.

De acuerdo a la delimitación del universo de estudio, los rangos de variación y valores discretos seleccionados para las variables involucradas en la gráfica son:

Variable (nemotécnico) Mín Máx Med

attributesNumber 3 10 6 2 4 6 8 10 rulesPerClass 1 15 5 1 4 8 12 15

Tabla ‎5.3: Rango de variación de las variables involucradas en la figura 5.1

El parámetro en el eje x de la gráfica es rulesPerClass. Éste es hecho variar en

todo su rango, el cual se puede apreciar que va de 1 a 15. El parámetro denominado “de serie” es attributesNumber. Éste no se hace

variar en todo su rango, sino que se seleccionan algunos valores discretos como punto



de partida para la definición de dominios para la experimentación. Sin embargo, no se establecen restricciones en caso que el experimentador considere que puede ser de utilidad tomar otros valores (siempre dentro del rango establecido) para presentar de mejor manera un resultado. Los valores discretos indicados son simplemente propuestos.

En el eje y, siempre se lee el porcentaje de reglas originales cubiertas de forma correcta por las reglas descubiertas, de acuerdo a los criterios de cobertura expuestos anteriormente.

5.5 Estrategia de Rastrillaje

Habiéndose definido el universo de estudio, es necesario confeccionar un plan de experimentación que permita rastrillar este universo de acuerdo a algún criterio.

5.5.1 Requerimientos

Con el objetivo de barrer el universo de estudio en busca de características que permitan conocer el comportamiento de la efectividad de la aplicación de mapas SOM y árboles TDIDT para la educción de conocimiento, se ha definido una estrategia de rastrillaje cuyos requerimientos de diseño son:

Abarcar la mayor cantidad de escenarios que puedan resultar de interés para su análisis, dentro del universo de estudio establecido.

Determinar la granularidad del barrido, de forma tal de no elegir escenarios muy amplios que contengan y oculten a otros dentro de sí, pero tampoco recaer en muchos escenarios que no poseen una diferencia marcada entre sí.

Mantener los niveles de procesamiento necesarios para el estudio de los escenarios en un valor que no supere los 7 días de procesamiento continuo para generar los datos necesarios para el análisis.

5.5.2 Solución Adoptada

La solución adoptada para dar respuesta a los mencionados requerimientos consiste en: Para cada experiencia, seleccionar un par de variables independientes. Hacer variar la primera de éstas sobre dominios en los que la segunda variable independiente toma ciertos valores discretos.

Este esquema de experimentación controlada, permite diseñar experimentos para los cuales, mediante la selección de pares de parámetros a variar, es posible establecer qué características del dominio inciden sobre la calidad de la educción.



5.5.3 Selección de los pares de variables independientes a ser estudiados

Para la selección de cuáles pares de variables independientes son de interés

para el presente estudio, se ha establecido una diferenciación en el origen de pertenencia de cada una de las variables.

Variables que responden al dominio

Variables que responden a los ejemplos

classPossibleValues attUsedInRule rulesPerClass classAttPossibleValuesPercentage attPossibleValues instancesByRule attributesNumber

Tabla ‎5.4: Origen de pertenencia de las variables

Esta diferenciación apunta a discriminar qué variables modelan características

intrínsecas del dominio y características propias de los ejemplos de un dominio. Es así como los pares de variables a estudiar son las combinaciones entre las

variables pertenecientes a cada uno de los enfoques:

Variables que responden al dominio Número de Experimento

graph_id

Parámetro variable Parámetro de serie

classPossibleValues attributesNumber 1 13 classPossibleValues attPossibleValues 2 14 classPossibleValues rulesPerClass 3 15 rulesPerClass attributesNumber 4 25 rulesPerClass classPossibleValues 5 27 rulesPerClass attPossibleValues No incluido attPossibleValues attributesNumber 6 31 attPossibleValues rulesPerClass 7 33 attPossibleValues classPossibleValues No incluido attributesNumber attPossibleValues 8 37 attributesNumber classPossibleValues 9 38 attributesNumber rulesPerClass 10 39

Variables que responden a los ejemplos

Parámetro variable Parámetro de serie

attUsedInRule instancesByRule 11 5 attUsedInRule classAttPossible-

ValuesPercentage 12 6



classAttPossible-ValuesPercentage

instancesByRule 13 11


attUsedInRule 14 12

instancesByRule attUsedInRule 15 23 instancesByRule classAttPossible-

ValuesPercentage 16 24

Tabla ‎5.5: Combinación de variables de los experimentos a realizar

De los citados experimentos, los resultados de algunos no son incluidos en el

presenten trabajo, ya que se considera no hacen un aporte claro al análisis. Se indica el identificador de cada gráfica con el objetivo de permitir facilitar la

ubicación de sus versiones en mayor resolución, las cuales están disponibles en el CD que acompaña a esta tesis.

5.5.4 Diccionario de Parámetros Según Enfoque

Con el objetivo de facilitar el análisis de los resultados considerando el enfoque que se le da en cada experimento a las variables involucradas, se presenta a continuación un diccionario de parámetros según el enfoque.

Variable (nemotécnico)

Descripción según el enfoque orientado al

dominio

Descripción según el enfoque orientado a los ejemplos

attributesNumber Cantidad de atributos de

cada ejemplo.

attPossibleValues Cantidad de posibles

valores que puede tomar cada atributo.

classPossibleValues Cantidad de clases que

rigen los ejemplos.

rulesPerClass Cantidad de reglas que

indican la pertenencia a cada clase.

attUsedInRule Especificidad del cubrimiento

de cada regla sobre los ejemplos asociados



instancesByRule Cantidad de ejemplos que dan soporte a cada regla


Concentración de las reglas que indican la pertenencia a cada clase

Tabla ‎5.6: Diccionario de parámetros según el enfoque

5.6 Análisis de los Experimentos

5.6.1 Variación del número de clases que rigen el dominio para distinta cantidad de atributos que tienen los ejemplos

Este experimento tiene como objetivo estudiar la efectividad de la educción por

clustering e inducción de reglas, para dominios regidos por una cantidad distinta de clases. A la vez, se pretende estudiar si el número de atributos que tienen los ejemplos, incide en la calidad de la educción para dominios regidos por una cantidad distinta de clases. 5.6.1.1 Descripción del experimento

Este experimento consiste en tomar un dominio patrón, generar 4 variantes de éste, cada cual con un valor distinto del número de atributos que tienen los ejemplos, y someter estos escenarios a la variación del número de clases que rigen el dominio, con el objetivo de analizar el comportamiento de la cantidad de reglas educidas de forma correcta. Resumiendo:

graph_id : 13 Parámetro a variar : Número de clases que rigen el dominio Parámetro de serie : Número de atributos que tienen los ejemplos

Los parámetros que se mantienen invariantes son:

Parámetro Valor

attPossibleValues 20 rulesPerClass 5 instancesByRule 10 attUsedInRule 3 classAttPossibleValuesPercentage 20



5.6.1.2 Resultados obtenidos

Los resultados obtenidos se resumen en la siguiente gráfica:

Gráfica ‎5.1: Estudio de dominios variando la cantidad de clases que los rigen, para distinta cantidad de atributos que tienen los ejemplos

5.6.1.3 Análisis de los Resultados Obtenidos

Observando la gráfica 5.1, es posible identificar un comportamiento común a

todas las curvas, el cual se sintetiza en la siguiente proposición experimental: Proposición Experimental 1:

A mayor cantidad de clases que rigen el dominio, menor es la efectividad del método propuesto.

Considerando las diferencias que surgen al evaluar dominios cuyos ejemplos están conformados por una cantidad distinta de atributos, es posible formular la siguiente proposición experimental:



Proposición Experimental 2:

La efectividad del método propuesto es mayor mientras menor es la cantidad de atributos que tienen los ejemplos del dominio, al ser evaluado para distinta cantidad de clases que lo rigen.

5.6.2 Variación del número de clases que rigen el dominio para

distinta cantidad de valores que puede tomar cada atributo

Este experimento tiene como objetivo estudiar la efectividad de la educción por clustering e inducción de reglas, para dominios regidos por una cantidad distinta de clases. A la vez, se pretende estudiar si el número de posibles valores que puede tomar cada atributo, incide en la calidad de la educción para dominios regidos por una cantidad distinta de clases. 5.6.2.1 Descripción del experimento

Este experimento consiste en tomar un dominio patrón, generar 4 variantes de éste, cada cual con un valor distinto del número de posibles valores que puede tomar cada atributo, y someter estos escenarios a la variación del número de clases que rigen el dominio, con el objetivo de analizar el comportamiento de la cantidad de reglas educidas de forma correcta. Resumiendo:

graph_id : 14 Parámetro a variar : Número de clases que rigen el dominio Parámetro de serie : Número de posibles valores que puede tomar cada atributo


Parámetro Valor

attributesNumber 6 rulesPerClass 5 instancesByRule 10 attUsedInRule 3 classAttPossibleValuesPercentage 20





Gráfica ‎5.2: Estudio de dominios variando la cantidad de clases que los rigen, para distinta cantidad de valores posibles que pueden tomar cada atributo




A mayor número de clases que rigen el dominio, menor es la efectividad del método propuesto.

Considerando las diferencias que surgen al evaluar dominios cuyos ejemplos

están compuestos por atributos con distinta cantidad de posibles valores a tomar, cabe formular la siguiente proposición experimental: Proposición Experimental 2:

La efectividad del método es mayor para mayor cantidad de posibles valores que puede tomar cada atributo que compone las reglas, al ser éste evaluado para distinta cantidad de clases que lo rigen.



5.6.3 Variación del número de clases que rigen el dominio para distinta cantidad de reglas que indican la pertenencia a cada clase


clustering e inducción de reglas, para dominios regidos por una cantidad distinta de clases. A la vez, se pretende estudiar si el número de reglas que indican la pertenencia a cada clase, incide en la calidad de la educción para dominios regidos por distinta cantidad de clases. 5.6.3.1 Descripción del experimento

Este experimento consiste en tomar un dominio patrón, generar 5 variantes de éste, cada cual con un valor distinto del número de reglas que indican la pertenencia a cada clase, y someter estos escenarios a la variación del número de clases que rigen el dominio, con el objetivo de analizar el comportamiento de la cantidad de reglas educidas de forma correcta. Resumiendo:

graph_id : 15 Parámetro a variar : Número de clases que rigen el dominio Parámetro de serie : Número de reglas que indican la pertenencia a cada clase


Parámetro Valor

attributesNumber 6 attPossibleValues 20 instancesByRule 10 attUsedInRule 3 classAttPossibleValuesPercentage 20





Gráfica ‎5.3: Estudio de dominios variando la cantidad de clases que los rigen, para distinta cantidad de reglas que indican la pertenencia a cada clase


Observando la gráfica 5.3, es posible identificar un comportamiento común a todas las curvas, el cual se sintetiza en la siguiente proposición experimental: Proposición experimental 1:

A mayor cantidad de clases que rigen el dominio, menor es la efectividad del método propuesto.

Considerando las diferencias que surgen al evaluar dominios en los cuales la

pertenencia a las clases que los rigen están indicadas por una cantidad distinta de reglas, cable formular la siguiente proposición experimental:

Proposición experimental 2:

A menor cantidad de reglas que indican la pertenencia a cada clase, mayor es la efectividad del método propuesto al ser evaluado en dominios con distinta cantidad de clases que los rigen.



5.6.4 Variación del número de reglas que indican la pertenencia a cada clase para distinta cantidad de atributos que tienen los ejemplos


clustering e inducción de reglas, para dominios en los que la pertenencia a cada clase está dada por una cantidad distinta de reglas. A la vez, se pretende estudiar si el número de atributos que tienen los ejemplos, incide en la calidad de la educción para dominios en los que varía la cantidad de reglas que indican la pertenencia a cada clase. 5.6.4.1 Descripción del experimento

Este experimento consiste en tomar un dominio patrón, generar 4 variantes de éste, cada cual con un valor distinto del número de atributos que tienen los ejemplos, y someter estos escenarios a la variación del número de reglas que indican la pertenencia a cada clase, con el objetivo de analizar el comportamiento de la cantidad de reglas educidas de forma correcta. Resumiendo:

graph_id : 25 Parámetro a variar : Número de reglas que indican la pertenencia a cada clase Parámetro de serie : Número de atributos que tienen los ejemplos


Parámetro Valor

attPossibleValues 20 classPossibleValues 5 instancesByRule 10 attUsedInRule 3 classAttPossibleValuesPercentage 20





Gráfica ‎5.4: Estudio de dominios variando la cantidad de reglas que indican la pertenencia a cada clase, para distinta cantidad de atributos que conforman los ejemplos




La efectividad del método decrece a medida que aumenta la cantidad de reglas que indican la pertenencia a cada clase, con un comportamiento aparentemente asintótico hacia un mínimo cuando la cantidad de reglas que indican la pertenencia a cada clase es alta.

Al comparar dominios para los cuales la cantidad de atributos que componen los

ejemplos es distinta, es posible formular la siguiente proposición experimental: Proposición Experimental 2:

Mientras menor es la cantidad de atributos que componen los ejemplos, mayor es la efectividad del método al ser evaluado para dominios con distinta cantidad de reglas que indican la pertenencia a cada clase.



5.6.5 Variación del número de reglas que indican la pertenencia a cada clase para distinta cantidad de clases que rigen el dominio


clustering e inducción de reglas, para dominios en los que la pertenencia a cada clase está dada por una cantidad distinta de reglas. A la vez, se pretende estudiar si el número de clases que rigen el dominio, incide en la calidad de la educción para dominios en los que varía la cantidad de reglas que indican la pertenencia a cada clase. 5.6.5.1 Descripción del experimento

Este experimento consiste en tomar un dominio patrón, generar 4 variantes de éste, cada cual con un valor distinto de la cantidad de clases que rigen el dominio, y someter estos escenarios a la variación del número de reglas que indican la pertenencia a cada clase, con el objetivo de analizar el comportamiento de la cantidad de reglas educidas de forma correcta. Resumiendo:

graph_id : 27 Parámetro a variar : Número de reglas que indican la pertenencia a cada clase Parámetro de serie : Número de clases que rigen el dominio


Parámetro Valor

attributesNumber 6 attPossibleValues 20 instancesByRule 10 attUsedInRule 3 classAttPossibleValuesPercentage 20





Gráfica ‎5.5: Estudio de dominios variando la cantidad de reglas que indican la pertenencia a cada clase, para distinta cantidad de clases que rigen los dominios




La efectividad del método decrece a medida que aumenta la cantidad de reglas que indican la pertenencia a cada clase hasta una determinada cantidad de reglas. Tras este valor, la efectividad parecería mantenerse casi sin variación dentro de un rango de valores de efectividad mínimos.

Al comparar dominios para los cuales la cantidad de clases que rigen el dominio

es distinta, es posible formular la siguiente proposición experimental: Proposición Experimental 2:

Mientras menor es la cantidad de clases que rigen el dominio, mayor es la efectividad del método al evaluar dominios con distinto número de reglas que indican la pertenencia a cada clase.



5.6.6 Variación del número de posibles valores que puede tomar cada atributo para distinta cantidad de atributos que conforman los ejemplos


clustering e inducción de reglas, para dominios en los que el número de valores posibles que puede tomar cada atributo es distinto. A la vez, se pretende estudiar si el número de atributos que conforman los ejemplos, incide en la calidad de la educción para dominios en los que varía la cantidad de posibles valores que puede tomar cada atributo. 5.6.6.1 Descripción del experimento

Este experimento consiste en tomar un dominio patrón, generar 4 variantes de éste, cada cual con un valor distinto del número de atributos que tienen los ejemplos, y someter estos escenarios a la variación del número de posibles valores que puede tomar cada atributo, con el objetivo de analizar el comportamiento de la cantidad de reglas educidas de forma correcta. Resumiendo:

graph_id : 31 Parámetro a variar : Número de posibles valores que puede tomar cada atributo Parámetro de serie : Número de atributos que conforman los ejemplos


Parámetro Valor

classPossibleValues 5 rulesPerClass 5 instancesByRule 10 attUsedInRule 50 classAttPossibleValuesPercentage 20





Gráfica ‎5.6: Estudio de dominios variando la cantidad de valores posibles que puede tomar cada uno de los atributos que tienen las reglas, para distinta cantidad de atributos que tienen las reglas




A mayor cantidad de valores posibles que puede tomar cada atributo, mayor es la efectividad del método propuesto.

Al comparar entre sí dominios con distinta cantidad de atributos que conforman los ejemplos, es posible formular la siguiente proposición experimental: Proposición Experimental 2:

A menor cantidad de atributos que tienen los ejemplos, mayor es la efectividad del método propuesto al ser evaluada para dominios en los que difiere la cantidad de valores posibles que puede tomar cada atributo.



5.6.7 Variación del número de posibles valores que puede tomar cada atributo para distinta cantidad de reglas que indican la pertenencia a cada clase


clustering e inducción de reglas, para dominios en los que el número de valores posibles que puede tomar cada atributo es distinto. A la vez, se pretende estudiar si el número de reglas que indican la pertenencia a cada clase, incide en la calidad de la educción para dominios en los que varía la cantidad de posibles valores que puede tomar cada atributo. 5.6.7.1 Descripción del experimento

Este experimento consiste en tomar un dominio patrón, generar 4 variantes de éste, cada cual con un valor distinto del número de reglas que indican la pertenencia a cada clase, y someter estos escenarios a la variación del número de posibles valores que puede tomar cada atributo, con el objetivo de analizar el comportamiento de la cantidad de reglas educidas de forma correcta. Resumiendo:

graph_id : 33 Parámetro a variar : Número de posibles valores que puede tomar cada atributo Parámetro de serie : Número de reglas que indican la pertenencia a cada clase


Parámetro Valor

attributesNumber 6 classPossibleValues 5 instancesByRule 10 attUsedInRule 3 classAttPossibleValuesPercentage 20





Gráfica ‎5.7: Estudio de dominios variando la cantidad de valores posibles que puede tomar cada uno de los atributos que conforman las reglas, para distinta cantidad de reglas que indican la pertenencia

a cada clase




A mayor cantidad de posibles valores que puede tomar cada uno de los atributos que componen las reglas, mayor es la efectividad del método propuesto.

Al comparar dominios para los cuales la cantidad de reglas que indican la

pertenencia a cada clase es distinta, es posible formular la siguiente proposición experimental:


A menor cantidad de reglas que indican la pertenencia a cada clase, mayor es la efectividad del método propuesto.



5.6.8 Variación del número de atributos que conforman los ejemplos para distinta cantidad de posibles valores que puede tomar cada uno


clustering e inducción de reglas, para dominios en los que el número de atributos que conforman los ejemplos es distinto. A la vez, se pretende estudiar si el número de posibles valores que puede tomar cada atributo, incide en la calidad de la educción para dominios en los que difiere el número de atributos que conforman los ejemplos. 5.6.8.1 Descripción del experimento

Este experimento consiste en tomar un dominio patrón, generar 5 variantes de éste, cada cual con un valor distinto del número de posibles valores que puede tomar cada atributo, y someter estos escenarios a la variación del número de atributos que conforman los ejemplos, con el objetivo de analizar el comportamiento de la cantidad de reglas educidas de forma correcta. Resumiendo:

graph_id : 37 Parámetro a variar : Número de atributos que conforman los ejemplos Parámetro de serie : Número de posibles valores que puede tomar cada atributo


Parámetro Valor

classPossibleValues 5 rulesPerClass 5 instancesByRule 10 attUsedInRule 3 classAttPossibleValuesPercentage 20





Gráfica ‎5.8: Estudio de dominios variando la cantidad de atributos que conforman los ejemplos, para distinta cantidad de valores posibles que pueden tomar cada uno de estos atributos




Mientras mayor es el número de atributos que tienen las reglas que indican la pertenencia a cada clase, menor es la efectividad del método.

Al comparar dominios para los cuales la cantidad de posibles valores que puede

tomar cada atributo es distinta, es posible formular las siguientes proposiciones experimentales: Proposición Experimental 2:

Mientras mayor es la cantidad de posibles valores que puede tomar cada atributo, mayor es la efectividad que presenta el método propuesto.




A partir de determinada cantidad de posibles valores que puede tomar cada atributo, si se sigue aumentando esta cantidad, no se observan mejoras significativas en la efectividad del método propuesto.

5.6.9 Variación del número de atributos que conforman los

ejemplos para distinta cantidad de clases que rigen el dominio


clustering e inducción de reglas, para dominios en los que el número de atributos que conforman los ejemplos es distinto. A la vez, se pretende estudiar si el número de clases que rigen el dominio, incide en la calidad de la educción para dominios en los que difiere la cantidad de atributos que conforman los ejemplos. 5.6.9.1 Descripción del experimento

Este experimento consiste en tomar un dominio patrón, generar 5 variantes de éste, cada cual con un valor distinto del número de clases que rigen el dominio, y someter estos escenarios a la variación del número de atributos que conforman los ejemplos, con el objetivo de analizar el comportamiento de la cantidad de reglas educidas de forma correcta. Resumiendo:

graph_id : 38 Parámetro a variar : Número de atributos que conforman los ejemplos Parámetro de serie : Número de clases que rigen el dominio


Parámetro Valor

attPossibleValues 20 rulesPerClass 5 instancesByRule 10 attUsedInRule 3 classAttPossibleValuesPercentage 20





Gráfica ‎5.9: Estudio de dominios variando la cantidad de atributos que tienen las reglas, para distinta cantidad clases que rigen los dominios




Mientras mayor es la cantidad de atributos que tienen las reglas, menor es la efectividad del método propuesto.

Al comparar dominios para los cuales la cantidad de clases que rigen el dominio es distinta, es posible formular la siguiente proposición experimental: Proposición Experimental 2:

Mientras menor es la cantidad de clases que rigen el dominio, mayor es la efectividad del método propuesto.




A partir de determinada cantidad de clases que rigen el dominio, el aumento de este parámetro no genera un decremento mayor en la efectividad del método.

5.6.10 Variación del número de atributos que conforman los ejemplos para distinta cantidad de reglas que indican la pertenencia a cada clase


clustering e inducción de reglas, para dominios en los que el número de atributos que conforman los ejemplos es distinto. A la vez, se pretende estudiar si el número de reglas que indican la pertenencia a cada clase, incide en la calidad de la educción para dominios en los que difiere el número de atributos que conforman los ejemplos. 5.6.10.1 Descripción del experimento

Este experimento consiste en tomar un dominio patrón, generar 5 variantes de éste, cada cual con un valor distinto de la cantidad de reglas que indican la pertenencia a cada clase, y someter estos escenarios a la variación del número de atributos que conforman los ejemplos, con el objetivo de analizar el comportamiento de la cantidad de reglas educidas de forma correcta. Resumiendo:

graph_id : 39 Parámetro a variar : Número de atributos que conforman los ejemplos Parámetro de serie : Número de reglas que indican la pertenencia a cada clase


Parámetro Valor

attPossibleValues 20 classPossibleValues 5 instancesByRule 10 attUsedInRule 3 classAttPossibleValuesPercentage 20





Gráfica ‎5.10: Estudio de dominios variando la cantidad de atributos que tienen las reglas, para distinta cantidad de reglas que indican la pertenencia a cada clase




A medida que aumenta la cantidad de atributos que tienen las reglas, menor es la efectividad del método propuesto.

Al comparar entre sí dominios con distinta cantidad de reglas que indican la

pertenencia a cada clase, es posible formular la siguiente proposición experimental: Proposición Experimental 2:

A mayor cantidad de reglas que indican la pertenencia a cada clase, menor es la efectividad del método propuesto al ser evaluado para dominios con distinta cantidad de atributos que tienen las reglas.



5.6.11 Estudio de dominios variando la especificidad del cubrimiento de cada regla sobre sus ejemplos asociados, para distinta cantidad de estos


clustering e inducción de reglas, para dominios en los que difiere la especificidad del cubrimiento de cada regla sobre sus ejemplos asociados. A la vez, se pretende estudiar si el número de ejemplos de cada regla, incide en la calidad de la educción para dominios con distinta especificidad del cubrimiento de cada regla sobre sus ejemplos asociados. 5.6.11.1 Descripción del experimento

Este experimento consiste en tomar un dominio patrón, generar 4 variantes de éste, cada cual con un valor distinto del número de ejemplos de cada regla, y someter estos escenarios a la variación de la especificidad del cubrimiento de cada regla sobre sus ejemplos asociados, con el objetivo de analizar el comportamiento de la cantidad de reglas educidas de forma correcta. Resumiendo: graph_id : 5 Parámetro a variar : Especificidad del cubrimiento de cada regla sobre sus

ejemplos asociados Parámetro de serie : Cantidad de ejemplos por regla


Parámetro Valor

attributesNumber 6 attPossibleValues 20 classPossibleValues 5 rulesPerClass 5 classAttPossibleValuesPercentage 20





Gráfica ‎5.11: Estudio de dominios variando la especificidad del cubrimiento de cada regla sobre sus ejemplos asociados, para distinta cantidad de estos




Mientras más específico es el cubrimiento de cada regla sobre sus ejemplos asociados, mayor es la efectividad del método propuesto.

Al comparar dominios para los cuales la cantidad de ejemplos de cada regla es

distinta, es posible formular la siguiente proposición experimental: Proposición Experimental 2:

A mayor cantidad de ejemplos por regla, mayor es la efectividad del método propuesto.



5.6.12 Estudio de dominios variando la especificidad del cubrimiento de cada regla sobre sus ejemplos asociados, para distinta concentración de las reglas que indican la pertenencia a cada clase


clustering e inducción de reglas, para dominios en los que difiere la especificidad del cubrimiento de cada regla sobre sus ejemplos asociados. A la vez, se pretende estudiar si la concentración de las reglas que indican la pertenencia a cada clase, incide en la calidad de la educción para dominios en los que difiere la especificidad del cubrimiento de cada regla sobre sus ejemplos asociados. 5.6.12.1 Descripción del experimento

Este experimento consiste en tomar un dominio patrón, generar 5 variantes de éste, cada cual con una concentración diferente de las reglas que indican la pertenencia a cada clase, y someter estos escenarios a la variación de la especificidad del cubrimiento de cada regla sobre sus ejemplos asociados, con el objetivo de analizar el comportamiento de la cantidad de reglas educidas de forma correcta. Resumiendo: graph_id : 6 Parámetro a variar : Especificidad del cubrimiento de cada regla sobre sus

ejemplos asociados Parámetro de serie : Concentración de las reglas que indican la pertenencia a cada

clase


Parámetro Valor

attributesNumber 6 attPossibleValues 20 classPossibleValues 5 rulesPerClass 5 instancesByRule 10





Gráfica ‎5.12: Estudio de dominios variando la especificidad del cubrimiento de cada regla sobre sus ejemplos asociados, para distinta concentración de reglas que indican la pertenencia a cada clase


Con la observación de la gráfica 5.12, se aprecia un comportamiento común a

todas las curvas, el cual es descripto por la siguiente proposición experimental: Proposición Experimental 1:


Analizando dominios en los que difiere la concentración de las reglas que

indican la pertenencia a cada clase, surge la siguiente proposición experimental: Proposición Experimental 2:

La concentración de las reglas que indican la pertenencia a cada clase, parecería no modificar la efectividad del método propuesto al ser evaluado para dominios en los que difiere la especificidad del cubrimiento de cada regla sobre sus ejemplos asociados.



5.6.13 Estudio de dominios variando la concentración de las reglas que indican la pertenencia a cada clase, para distinta cantidad de ejemplos que dan soporte a cada regla


clustering e inducción de reglas, para dominios en los que difiere la concentración de las reglas que indican la pertenencia a cada clase. A la vez, se pretende estudiar si la cantidad de ejemplos que dan soporte a cada regla, incide en la calidad de la educción para dominios en los que varía la concentración de las reglas que indican la pertenencia a cada clase. 5.6.13.1 Descripción del experimento

Este experimento consiste en tomar un dominio patrón, generar 4 variantes de éste, cada cual con un valor distinto del número de ejemplos que dan soporte a cada una de las reglas, y someter estos escenarios a la variación de la concentración de las reglas que indican la pertenencia a cada clase, con el objetivo de analizar el comportamiento de la cantidad de reglas educidas de forma correcta. Resumiendo: graph_id : 11 Parámetro a variar : Concentración de las reglas que indican la pertenencia a cada

clase Parámetro de serie : Cantidad de ejemplos que dan soporte a cada regla


Parámetro Valor

attributesNumber 6 attPossibleValues 20 classPossibleValues 5 rulesPerClass 5 attUsedInRule 3





Gráfica ‎5.13: Estudio de dominios variando la concentración de las reglas que indican la pertenencia a cada clase, para distinta cantidad de ejemplos que dan soporte a cada regla




Mientras menor es la concentración de las reglas que indican la pertenencia a cada clase, mayor es la efectividad del método propuesto.

Al comparar dominios para los cuales la cantidad de ejemplos que dan soporte

a cada una de las reglas es distinta, es posible formular la siguiente proposición experimental: Proposición Experimental 2:

A mayor cantidad de ejemplos que dan soporte a cada regla, mayor es la efectividad del método propuesto.



5.6.14 Estudio de dominios variando la concentración de las reglas que indican la pertenencia a cada clase, para distinta especificidad del cubrimiento de cada regla sobre sus ejemplos asociados


clustering e inducción de reglas, para dominios en los que difiere la concentración de las reglas que indican la pertenencia a cada clase. A la vez, se pretende estudiar si la especificidad del cubrimiento de cada regla sobre sus ejemplos asociados, incide en la calidad de la educción para dominios en los que varía la concentración de las reglas que indican la pertenencia a cada clase. 5.6.14.1 Descripción del experimento

Este experimento consiste en tomar un dominio patrón, generar 3 variantes de éste, cada cual con un especificidad distinta del cubrimiento de cada regla sobre sus ejemplos asociados, y someter estos escenarios a la variación de la concentración de las reglas que indican la pertenencia a cada clase, con el objetivo de analizar el comportamiento de la cantidad de reglas educidas de forma correcta. Resumiendo:

graph_id : 12 Parámetro a variar : Concentración de las reglas que indican la pertenencia a cada

clase Parámetro de serie : Especificidad del cubrimiento de cada regla sobre sus

ejemplos asociados


Parámetro Valor

attributesNumber 6 attPossibleValues 20 classPossibleValues 5 rulesPerClass 5 instancesByRule 10





Gráfica ‎5.14: Estudio de dominios variando la concentración de las reglas que indican la pertenencia a cada clase, para distinta especificidad del cubrimiento de cada regla sobre sus ejemplos asociados




Mientras menor es la concentración de las reglas que indican la pertenencia a cada clase, mayor es la efectividad del método propuesto.

Se observa además que, si bien las curvas poseen un comportamiento común,

el cual ha sido descripto por la proposición experimental anterior, éstas presentan diferencias significativas, lo cual da lugar a la formulación de las siguientes proposiciones experimentales: Proposición Experimental 2:





Mientras más específico es el cubrimiento de cada regla sobre sus ejemplos asociados, más pronunciado es el crecimiento de la efectividad del método propuesto con el decremento de la concentración de las reglas que indican la pertenencia a cada clase.

5.6.15 Estudio de dominios variando el número de ejemplos que dan

soporte a cada regla, para distinta especificidad del cubrimiento de cada regla sobre sus ejemplos asociados


clustering e inducción de reglas, para dominios en los que difiere el número de ejemplos que dan soporte a cada una de las reglas que indican la pertenencia a las clases que los rigen. A la vez, se pretende estudiar si la especificidad del cubrimiento de cada regla sobre sus ejemplos asociados, incide en la calidad de la educción para dominios en los que varía el número de ejemplos que dan soporte a cada una de las reglas. 5.6.15.1 Descripción del experimento

Este experimento consiste en tomar un dominio patrón, generar 3 variantes de éste, cada cual con distinta especificidad del cubrimiento de cada regla sobre sus ejemplos asociados, y someter estos escenarios a la variación del número de ejemplos que dan soporte a cada una de las reglas que indican la pertenencia a las clases que rigen el dominio, con el objetivo de analizar el comportamiento de la cantidad de reglas educidas de forma correcta. Resumiendo: graph_id : 23 Parámetro a variar : Cantidad de ejemplos que dan soporte a cada regla Parámetro de serie : Especificidad del cubrimiento de cada regla sobre sus

ejemplos asociados


Parámetro Valor

attributesNumber 6 attPossibleValues 20 classPossibleValues 5 rulesPerClass 5 classAttPossibleValuesPercentage 20





Gráfica ‎5.15: Estudio de dominios variando el número de ejemplos que dan soporte a cada regla, para distinta especificidad del cubrimiento de cada regla sobre sus ejemplos asociados




A mayor cantidad de ejemplos que dan soporte a cada regla, mayor es la efectividad del método propuesto.

Al comparar dominios cuyas reglas cubren sus ejemplos asociados con distinta especificidad, es posible formular las siguientes proposiciones experimentales:






Mientras más específico es el cubrimiento de cada regla sobre sus ejemplos asociados, más pronunciado es el crecimiento de la efectividad del método propuesto con el incremento de la cantidad de ejemplos que dan soporte a cada regla.

5.6.16 Estudio de dominios variando el número de ejemplos que dan

soporte a cada regla, para distinta concentración de las reglas que indican la pertenencia a cada clase


clustering e inducción de reglas, para dominios en los que varía el número de ejemplos que dan soporte a cada una de las reglas que indican la pertenencia a las clases que los rigen. A la vez, se pretende estudiar si la concentración de las reglas que indican la pertenencia a cada clase, incide en la calidad de la educción para dominios en los que varía el número de ejemplos que dan soporte a cada una de las reglas que indican la pertenencia a las clases que los rigen. 5.6.16.1 Descripción del experimento

Este experimento consiste en tomar un dominio patrón, generar 5 variantes de éste, cada cual con una concentración distinta de las reglas que indican la pertenencia a cada clase, y someter estos escenarios a la variación del número de ejemplos que dan soporte a cada una de las reglas que indican la pertenencia a las clases que rigen el dominio, con el objetivo de analizar el comportamiento de la cantidad de reglas educidas de forma correcta. Resumiendo: graph_id : 24 Parámetro a variar : Cantidad de ejemplos que dan soporte a cada regla Parámetro de serie : Concentración de las reglas que indican la pertenencia a cada

clase




Parámetro Valor

attributesNumber 6 attPossibleValues 20 classPossibleValues 5 rulesPerClass 5 attUsedInRule 3



Gráfica ‎5.16: Estudio de dominios variando el número de ejemplos que dan soporte a cada regla, para distinta concentración de las reglas que indican la pertenencia a cada clase


Observando la gráfica 5.16, es posible identificar un comportamiento común a todas las curvas, el cual se sintetiza en la siguiente proposición experimental: Proposición Experimental 1:

A mayor cantidad de ejemplos por regla, mayor es la efectividad del método propuesto.



Al comparar dominios con distinta concentración de las reglas que indican la pertenencia a cada clase, es posible formular la siguiente proposición experimental: Proposición Experimental 2:

La concentración de las reglas que indican la pertenencia a cada clase, parecería no modificar la efectividad del método propuesto al ser evaluado para dominios en los que difiere la cantidad de ejemplos que dan soporte a cada regla.

5.7 Unificación de los resultados experimentales

Los resultados obtenidos han sido agrupados en dos enfoques, los cuales responden a la diferenciación del origen de pertenencia de cada variable, planteada en la sección 5.5.3

5.7.1 Enfoque orientado al dominio

Se transcriben a continuación, en tamaño reducido, las gráficas correspondientes a los experimentos realizados para el enfoque orientado al dominio, a efecto de facilitar la lectura de los resultados experimentales unificados.

Gráfica 5.1: Estudio de dominios variando la cantidad de clases que los rigen, para distinta cantidad de atributos que tienen los ejemplos

Gráfica 5.2: Estudio de dominios variando la cantidad de clases que los rigen, para distinta

cantidad de valores posibles que pueden tomar cada atributo



Gráfica 5.3: Estudio de dominios variando la cantidad de clases que los rigen, para distinta

cantidad de reglas que indican la pertenencia a cada clase

Gráfica 5.4: Estudio de dominios variando la cantidad de reglas que indican la pertenencia a

cada clase, para distinta cantidad de atributos que conforman los ejemplos

Gráfica 5.5: Estudio de dominios variando la cantidad de reglas que indican la pertenencia a cada clase, para distinta cantidad de clases que

rigen los dominios

Gráfica 5.6: Estudio de dominios variando la cantidad de valores posibles que puede tomar cada uno de los atributos que tienen las reglas,

para distinta cantidad de atributos que tienen las reglas

Gráfica 5.7: Estudio de dominios variando la cantidad de valores posibles que puede tomar cada uno de los atributos que conforman las

reglas, para distinta cantidad de reglas que indican la pertenencia a cada clase

Gráfica 5.8: Estudio de dominios variando la cantidad de atributos que conforman los ejemplos,

para distinta cantidad de valores posibles que pueden tomar cada uno de estos atributos



Gráfica 5.9: Estudio de dominios variando la cantidad de atributos que tienen las reglas, para distinta cantidad clases que rigen los dominios

Gráfica 5.10: Estudio de dominios variando la cantidad de atributos que tienen las reglas, para

distinta cantidad de reglas que indican la pertenencia a cada clase

1. A mayor cantidad de clases que rigen el dominio, menor es la efectividad del

método propuesto (gráficas 5.1, 5.2, 5.3, 5.5, 5.9).

2. Mientras mayor es el número de atributos que tienen las reglas que indican la pertenencia a cada clase, menor es la efectividad del método propuesto (gráficas 5.1, 5.4, 5.6, 5.8, 5.9, 5.10).

3. A mayor cantidad de valores posibles que puede tomar cada atributo, mayor es la

efectividad del método propuesto (gráficas 5.2, 5.6, 5.7, 5.8).

4. A mayor cantidad de reglas que indican la pertenencia a cada clase, menor es la efectividad del método propuesto (gráficas 5.3, 5.4, 5.5, 5.10).

5. A mayor cantidad de reglas que indican la pertenencia a cada clase, menor es la

efectividad del método propuesto, con un comportamiento aparentemente asintótico hacia un mínimo cuando la cantidad de reglas que indican la pertenencia a cada clase es alta (gráficas 5.4, 5.5).

6. A partir de determinada cantidad de posibles valores que puede tomar cada

atributo, si se sigue aumentando esta cantidad, no se observan mejoras significativas en la efectividad del método propuesto (gráfica 5.8).

7. A partir de determinada cantidad de clases que rigen el dominio, el aumento de

este parámetro no genera un decremento mayor en la efectividad del método propuesto (gráfica 5.9).



5.7.2 Enfoque orientado a los ejemplos

Se transcriben a continuación, en tamaño reducido, las gráficas correspondientes a los experimentos realizados para el enfoque orientado a los ejemplos, a efecto de facilitar la lectura de los resultados experimentales unificados.

Gráfica 5.11: Estudio de dominios variando la

especificidad del cubrimiento de cada regla sobre sus ejemplos asociados, para distinta cantidad de

estos

Gráfica 5.12: Estudio de dominios variando la especificidad del cubrimiento de cada regla sobre

sus ejemplos asociados, para distinta concentración de reglas que indican la pertenencia

a cada clase

Gráfica 5.13: Estudio de dominios variando la

concentración de las reglas que indican la pertenencia a cada clase, para distinta cantidad de

ejemplos que dan soporte a cada regla

Gráfica 5.14: Estudio de dominios variando la concentración de las reglas que indican la

pertenencia a cada clase, para distinta especificidad del cubrimiento de cada regla sobre

sus ejemplos asociados



Gráfica 5.15: Estudio de dominios variando el

número de ejemplos que dan soporte a cada regla, para distinta especificidad del cubrimiento de cada

regla sobre sus ejemplos asociados

Gráfica 5.16: Estudio de dominios variando el número de ejemplos que dan soporte a cada regla,

para distinta concentración de las reglas que indican la pertenencia a cada clase

1. Mientras más específico es el cubrimiento de cada regla sobre sus ejemplos

asociados, mayor es la efectividad del método propuesto (gráficas 5.11, 5.12, 5.14, 5.15).

2. Mientras menor es la concentración de las reglas que indican la pertenencia a cada clase, mayor es la efectividad del método propuesto (gráficas 5.13, 5.14).

3. A mayor cantidad de ejemplos que dan soporte a cada regla, mayor es la

efectividad del método propuesto (gráficas 5.11, 5.13, 5.15, 5.16).

4. La concentración de las reglas que indican la pertenencia a cada clase, parecería no modificar la efectividad del método propuesto al ser evaluada en dominios en los que difiere la especificidad del cubrimiento de cada regla sobre sus ejemplos asociados (gráfica 5.12).


asociados, más pronunciado es el crecimiento de la efectividad del método propuesto con el decremento de la concentración de las reglas que indican la pertenencia a cada clase (gráfica 5.14).


asociados, más pronunciado es el crecimiento de la efectividad del método propuesto con el incremento de la cantidad de ejemplos que dan soporte a cada regla (gráfica 5.15).

7. La concentración de las reglas que indican la pertenencia a cada clase, parecería no

modificar la efectividad del método propuesto al ser evaluada para dominios en los que difiere la cantidad de ejemplos que dan soporte a cada regla (gráfica 5.16).


84 Ariel Kogan Conclusiones

6 Conclusiones

En este capítulo se resumen los aportes formulados en la tesis (sección 6.1) y se presentan futuras líneas de trabajo (sección 6.2) proponiendo minería de datos para el análisis de los resultados (sección 6.2.1), incluir la variación de los parámetros de la red SOM en futuros estudios (sección 6.2.2) y líneas complementarias (sección 6.2.3).

6.1 Aportes

En esta tesis se presentó un estudio del comportamiento de la efectividad de la utilización de agrupamiento por SOM e inducción por TDIDT como método de descubrimiento de conocimiento.

En el capítulo 4 se demuestra por construcción y en el capítulo 5 por experimentación que es posible realizar el mencionado estudio, habiéndose obtenido proposiciones experimentales del comportamiento observado.

Entre los recursos de los cuales se dispuso para la resolución del problema, se encuentran:

Conocimiento empírico por parte de los integrantes del Laboratorio de Sistemas Inteligentes en el que se enmarca esta tesis, sobre la aplicación del método propuesto como mecanismo de descubrimiento de conocimiento.

Librerías de código abierto proporcionadas por la Universidad de Waikato que puede ser utilizadas como partes constitutivas de un sistema de experimentación.

Son aportaciones de la tesis:

El diseño de un esquema que permite la generación de dominios al azar, controlando los parámetros que los rigen. Esto permite trabajar con dominios cuyas características son definidas por el experimentador a través de la generación de nuevos dominios en base a éstas. La generación de los dominios en base al azar, permite establecer una cota inferior del comportamiento de la efectividad del método propuesto como herramienta de descubrimiento de conocimiento.

La definición de un criterio de determinación de la efectividad del método basado en el concepto de cubrimiento de conjuntos de reglas, el cual es coincidente con las prácticas de descubrimiento de conocimiento, adaptado a las características particulares que surgen de trabajar con dominios generados al azar y con SOM y TDIDT como algoritmos inteligentes para el descubrimiento de conocimiento.


Conclusiones Ariel Kogan 85

El establecimiento de un plan de experimentación que puede utilizarse como protocolo para continuar este trabajo. Éste involucró la delimitación del universo de estudio y la proposición de una estrategia clara y ordenada para generar los resultados necesarios para la evaluación de los parámetros a estudiar.

La consideración a lo largo de todo el diseño de la solución propuesta de los tiempos que conlleva la ejecución de cada componente del proceso de experimentación. Se han definido rangos a tomar por las variables de forma tal de acotar los tiempos de cómputo, y –con el mismo fin- se han organizado y limitado las experiencias a realizar.

6.2 Futuras líneas de trabajo

Se han identificado como futuras líneas de trabajo:

6.2.1 Análisis de los resultados obtenidos mediante la aplicación de minería de datos

En esta tesis se ha realizado un análisis de los resultados experimentales

obtenidos, estudiando en cada experiencia un único par de variables. Las proposiciones experimentales formuladas describen la relación entre el par de variables estudiadas en cada experiencia y la medida adoptada para indicar la efectividad del método.

Una propuesta alternativa consiste en la aplicación de métodos automáticos de

descubrimiento de conocimiento con el objetivo de obtener patrones. Se propone como primera aproximación a este estudio:

1. Definido un universo de estudio, obtener por experimentación un conjunto de

datos que permita conocer la efectividad del método para cada uno de los dominios a analizar. Se recomienda para este paso, generar experiencias distribuidas de forma equitativa para cada uno de los parámetros. Esto se puede lograr fácilmente definiendo una misma cantidad de valores a tomar por cada parámetro -dentro de su rango de variación- y generando las experiencias por combinación de estos. Es decir, que si se tienen 𝑝 parámetros, tomar la misma cantidad 𝑣 de valores (mientras más alto 𝑣, se presume que más rico va a ser el conjunto de datos con el cual se va a trabajar) para cada uno y combinarlos, obteniendo 𝑣𝑝combinaciones distintas.


86 Ariel Kogan Conclusiones

Si se toma una decisión distinta, el conjunto de registros a ser presentado al algoritmo de descubrimiento de conocimiento, tendrá más ocurrencias de un parámetro que de otro, lo cual incidirá en su comportamiento y generará una educción de conocimiento en base a un conjunto de datos generado de forma tendenciosa.

2. Aplicar una técnica de discretización al atributo clase (efectividad del método para el dominio estudiado), de forma tal de contar con una clase de tipo nominal. Cada posible valor de la clase, pasará a representar un rango en el cual se encuentra la efectividad del método (ej.: valor 1, de 0% a 10%; valor 2: de 10% a 20%).

3. Aplicar métodos automáticos de descubrimiento de conocimiento (ej.: inferencias de reglas por TDIDT) con el fin de obtener reglas que indiquen las condiciones que se cumplen para, mediante la aplicación de SOM y TDIDT a un dominio, se obtenga un determinado rango de efectividad del método. Las reglas a ser obtenidas mediante esta técnica no están limitadas en la

cantidad de condiciones que se impongan sobre los atributos, por lo que es posible que marquen la interrelación entre varios atributos para indicar el grado de efectividad obtenido mediante la aplicación del método propuesto.

6.2.2 Inclusión de los parámetros de la red SOM como variables del experimento

En la presente tesis han sido definidos valores de configuración de la red

neuronal SOM como parámetros del banco de pruebas. Sin embargo, debido a la delimitación del alcance del presente estudio, estos han permanecido invariantes.

Una futura línea de trabajo que se ha identificado, consiste en la inclusión como

variables de experimentación a los parámetros que determinan características constructivas de la red neuronal SOM. De esta manera, sería posible analizar la incidencia de estos parámetros en la efectividad de la aplicación del método propuesto.

Algunos parámetros a ser considerados como variables, son:

Dimensión del mapa SOM.

Cantidad de veces que se somete a la SOM el conjunto de datos, para entrenarla.


Conclusiones Ariel Kogan 87

6.2.3 Otras líneas de trabajo

El estudio completo de todas las combinaciones de variación de pares de parámetros, incluyendo la contrastación entre parámetros asociados al dominio con aquellos que responden a los ejemplos.

La realización de un estudio de similares características, considerando un rango de variación más amplio para los valores que puede tomar cada uno de los parámetros estudiados.

Sistematizar la complejidad de un dominio dado en función de los parámetros a partir de los cuales es generado. Estudiar la complejidad que un dominio presenta para la aplicación de un mecanismo de descubrimiento de conocimiento.

El estudio del comportamiento de la efectividad del método propuesto, introduciendo “ruido” en los ejemplos generados.

La utilización de atributos de tipo numérico, de forma tal que el algoritmo de inducción pueda generar condiciones del tipo “menor a” o “mayor a”, no únicamente “es igual a”.


88 Ariel Kogan Referencias

7 Referencias Alander J., Frisk M., 1991. Process error detection using self-organizing feature maps.

Artificial Neural Networks, volume II, pp 1229-1232. Amsterdam, Netherlands.

Alhoniemi E., 1995. Monitoring of complex processes using the self-organizing map.

Master’s thesis, Helsinki University of Technology. Beveridge M., 1996. Self Organizing Maps.

http://www.dcs.napier.ac.uk/hci/martin/msc/node6.html Blurock, Eduard S. (1996). The ID3 Algorithm. Research Institute for Symbolic

Computation, Austria. Britos, P., Grosser, H., Sierra, H. y García Martínez, R. 2006. Unusual Changes in

Consumption Detection in Mobile Phone Users. Research in Computing Science Journal, 21: 195-204.

Britos, P., Hossian, A., García-Martinez, R. y Sierra, E. 2005. Minería de Datos Basada

en Sistemas Inteligentes. Editorial Nueva Librería. 1124 páginas. ISBN 987-1104-30-8.

Chen, M., Han, J., Yu, P. (1996). Data mining: An overview from database perspective.

IEEE Transactions on Knowledge and Data Eng. Chen, S., Alahakoon, D., Indrawan, M. 2005. Background Knowledge Driven Ontology

Discovery. Proceedings IEEE International Conference on e-Technology, e-Commerce and e-Service Pág. 202-207.

Cogliati, M., Britos, P. García-Martínez, R. 2006. Patterns in Temporal Series of

Meteorological Variables Using SOM & TDIDT. Lecture Notes in Artificial Intelligence (por aparecer). Springer Verlag.

Cumming S., 1993. Neural Networks for monitoring of engine condition data. Neural

Computing & Applications, pp. 96-102. Essenreiter R., Treitel S., 1999. Identification and classification of multiple reflections

with self-organizing maps. Geophysical Institute, University of Karlsruhe, Germany.

Evangelos, S., Han, J. (1996). Proceedings of the Second International Conference on

Knowledge Discovery and Data Mining. Portland, EE.UU.

http://www.dcs.napier.ac.uk/hci/martin/msc/node6.html


Referencias Ariel Kogan 89

Felgaer, P., Britos, P. y García-Martínez, R. 2006. Prediction in Health Domain Using Bayesian Network Optimization Based on Induction Learning Techniques. International Journal of Modern Physics C, 17(3): 447-455. ISSN 0129-1831.

Ferrero, G., Britos, P., García-Martínez, R., 2006. Detection of Breast Lesions in Medical

Digital Imaging Using Neural Networks. In IFIP International Federation for Information Processing, Volume 218, Professional Practice in Artificial Intelligence, eds. J. Debenham, (Boston: Springer), pp. 1-10.

Gallion, R., Clair, D., Sabharwal, C., Bond, W.E. (1993). Dynamic ID3: A Symbolic

Learning Algorithm for Many-Valued Attribute Domains. Engineering Education Center, University of Missouri-Rolla, St. Luis, EE.UU.

Grosser, H., Britos, P. y García-Martínez, R. (2005). Detecting Fraud in Mobile

Telephony Using Neural Networks. Lecture Notes in Artificial Intelligence 3533:613-615

Grosser, H., Britos, P. y García-Martínez, R. 2005. Detecting Fraud in Mobile Telephony

Using Neural Networks. Lecture Notes in Artificial Intelligence, 3533: 613-615. Springer-Verlag.

Grossman, R., Kasif, S., Moore, R., Rocke, D. and Ullman, J. 1999. Data Mining

Research: Opportunities and Challenges, A Report of three NSF Workshops on Mining Large, Massive, and Distributed Data, January 1999, Chicago.

Gupta, S., Goyal, R., Shubham, K., Dey, L., Malik, A., Chaudhury, S., Bhattacharya S.

2006. Knowledge Discovery from Semi-Structured Data for Conceptual Organization. Proceedings 2006 IEEE/WIC/ACM International Conference on Web Intelligence and Intelligent Agent Technology. Pág. 291-294.

Hall, M. y Holmes, G. 2003. Benchmarking Attribute Selection Techniques for Discrete

Class Data Mining, IEEE Transactions on Knowledge and Data Engineering, vol. 15, no. 6, pp. 1437-1447.

Hilera J. R., Martínez V. 2000, Redes Neuronales Artificiales: Fundamentos, modelos y

aplicaciones, RA-MA Editorial, Madrid. Hollmen J, 1996. Process Modeling using the Self-Organizing Map, Helsinki University

of Technology Department of Computer Science. Holsheimer, M., Siebes, A. (1991). Data Mining: The Search for Knowledge in

Databases. Report CS-R9406, ISSN 0169-118X, Amersterdam, The Netherlands.

Hunt, E.B., Marin, J., Stone, P.J. (1966). Experiments in Induction. New York, Academic

Press, EE.UU.


90 Ariel Kogan Referencias

Ian H. Witten and Eibe Frank (2005) "Data Mining: Practical machine learning tools and techniques", 2nd Edition, Morgan Kaufmann, San Francisco, 2005.

Joachims, T., Freitag, D., Mitchell, T. (1995). Web Watcher: A Tour Guide for the World

Wide Web. School of Computer Science, Carnegie Mellon University, EE.UU.

Kaski, S. 1997. Data exploration using self-organizing maps. Acta Polytechnica

Scandinavica, Mathematics, Computing and Management in Engineering Series No. 82, 57 pp. Published by the Finnish Academy of Technology. ISSN 1238-9803.

Kohonen, T. (1982) Self-organized formation of topologically correct feature maps.

Biological Cybernetics, 43:59-69. Kohonen, T. (1990) The Self-Organizing Map. Proceedings of the IEEE, 78:1464-1480. Kohonen, T. (1995) Self-Organizing Maps. Springer, Berlin. Kohonen, T., Oja, E., Simula, O., Visa, A., and Kangas, J. (1996). Engineering applications

of the self-organizing map. Proceedings of the IEEE, 84:1358-1384. Mannila, H. (1997). Methods and problems in data mining. In Proc. of International

Conference on Database Theory, Delphi, Greece. Michalski, R. 1983. A Theory and Methodology of Inductive Learning, Artificial

Intelligence, 20:111-161. Michalski, R. Bratko, I. Kubat, M (eds.) 1998. Machine Learning and Data Mining,

Methods and Applications, John Wiley & Sons Ltd, West Sussex, England Mitchell, T. (2000). Decision Trees. Cornell University, EE.UU. Pandey, S., B. Mishra, R. 2005. Knowledge Discovery and Ontology-based services on

the Grid (a survey report). Proceedings Sixth International Conference on Parallel and Distributed Computing Applications and Technologies. Pág. 1033-1038

Perez-Rey, D., Maojo, V., Garcia-Remesal, M., Alonso-Calvo R. 2004. Biomedical

Ontologies in Post-Genomic Information Systems. Proceedings Fourth IEEE Symposium on Bioinformatics and Bioengineering. Pág. 207.

Piatetski-Shapiro, G., Frawley, W.J., Matheus, C.J. 1991. Knowledge discovery in

databases: an overview. AAAI-MIT Press, Menlo Park, California. Quinlan, J. R. 1986. Induction of Decision Trees, Machine Learning,1:81-106


Referencias Ariel Kogan 91

Quinlan, J.R. (1993a). The effect of noise on concept learning. En R.S. Michalski, J.G. Carbonell, & T.M. Mitchells (Eds.) Machine learning, the artificial intelligence approach. Morgan Kaufmann, Vol. I, Capítulo 6, páginas 149-167. San Mateo, CA: Morgan Kaufmann, EE.UU.

Quinlan, J.R. (1993b). Learning efficient Classification Procedures and Their Application

to Chess Games. En R.S. Michalski, J.G. Carbonell, & T.M. Mitchells (Eds.) Machine learning, the artificial intelligence approach. Morgan Kaufmann, Vol. II, Capítulo 15, páginas 463-482, EE.UU.

Quinlan, J.R. (1993c). Programs for machine learning. Morgan Kaufmann publishers,

San Mateo, California, EE.UU. Quinlan, J.R. (1995). MDL and categorical theories. Basser department of computer

science, University of science, Australia. Quinlan, J.R., Cameron-Jones, R.M. (1995). Oversearching and layered search in

empirical learning. Basser department of computer science, University of science, Australia.

Rancán, C., Pesado, P. y García-Martínez, R. 2007. Toward Integration of

Knowledge Based Systems and Knowledge Discovery Systems. Journal of Computer Science & Technology, 7(1): 91-97.

Ritter H., Martinetz T., Schulten K., 1992. Neural Computation and Self-Organizing

Maps. Addison-Wesley Publishing Company. Salgueiro, F., Cataldi, Z., Britos, P., Sierra, E. y García Martínez, R. Selecting Pedagogical

Protocols using SOM. Research in Computing Science Journal, 21: 205-214. 2006.

Servente, M. y García Martínez, R. 2002. Algoritmos TDIDT Aplicados a la Minería

Inteligente. Revista del Instituto Tecnológico de Buenos Aires, 26: 39-57. ISSN 0326-1840.

Song, G., Qian, Y., Liu, Y., Zhang, K. 2006. Oasis: A Mapping and Integration Framework

for Biomedical Ontologies. Proceedings 19th IEEE Symposium on Computer-Based Medical Systems. Pág. 611-616

Vapola M., Simula O., Kohonen T., 1994. Representation and identification of fault

conditions of an anaesthesia system by means of the Self-Organizing Map. Int. Conference on Artificial Neural Networks, volume I, pp. 350-353, London, UK.

Vesanto J., Alhoniemi E., 2000, Clustering of the Self-Organizing Map. IEEE transactions

on neural networks, Vol 11, No. 3.


92 Metodología

A Metodología

En este capítulo se describe la metodología empleada para la construcción del banco de pruebas.

Se enumeran los requerimientos (sección A.1), Se hace el análisis del sistema (sección A.2) mediante diagramas de clase (sección A.2.1), determinación de casos de uso (sección A.2.2), y diagramas de transición de estados (sección A.2.3).

Se realiza el diseño de la aplicación (sección A.3) para sus componentes de ejecución de experiencias (sección A.3.1), graficación de resultados (sección A.3.2) y unificación de los resultados obtenidos para su análisis en conjunto (sección A.3.3).

Se aborda la codificación de la solución (sección A.4) y su implementación (sección A.5) describiendo sus procesos y pantallas (sección A.5.1).

Finalmente, se cubre la etapa de pruebas (sección A.6) estableciendo un plan de pruebas (sección A.6.1), documentando el diseño de cada prueba (sección A.6.2), especificando los casos de prueba (sección A.6.3), los procedimientos (sección A.6.4), se confecciona un informe de los casos de prueba ejecutados (sección A.6.5), así como un informe de la prueba (sección A.6.6). Se determina la gestión de configuración (sección A.7) en cuanto a su identificación (sección A.7.1), control (sección A.7.2) y generación de informes de estado (sección A.7.3).

A.1 Requerimientos

El banco de pruebas debe permitir definir experimentos, ejecutarlos y almacenar los datos del experimento, junto a los resultados obtenidos, en algún medio de persistencia.

Otro requerimiento consiste en facilitar el análisis de los resultados obtenidos,

permitiendo generar gráficas de manera automática. En el caso que las experiencias sean ejecutadas en distintas máquinas con el

objetivo de obtener mayor poder de cómputo, el sistema debe proveer un mecanismo de unificación de los resultados obtenidos para su análisis en conjunto.

A.2 Análisis

A.2.1 Diagrama de Clases

A continuación se presenta el diagrama de clases fundamentales del proyecto acompañado de una descripción de cada una de éstas:


Metodología 93

-id

-scenario

-variableParameter

#from

#to

#iterationsPerValue

-description

-experienceIteration

#connection

Experience

-id

-attributesNumber

-attPosibleValues

-classPosibleValues

-rulesPerClass

-attUsedInRule

-instancesByRule

-classAttPossibleValuesPercentage

-mix

-allowMultipleCoverage

-allowedCoverageDesviation

-somTrainingIterationsMultiplier

-somMapWidth

-somMapHeight

-connection

Scenario

-id

-experience

#x

-rulesCorrectlyCoveredJ48

-rulesCorrectlyCoveredId3

-commonAttributesScoreJ48

-commonAttributesScoreId3

-generator

-som

-j48

-id3

-connection

ExperienceIteration

-attributesNumber

-attPosibleValues

-classPosibleValues

-rulesPerClass

-attUsedInRule

-instancesByRule

-classAttPossibleValuesPercentage

-mix

-allowMultipleCoverage

-ruleSet

-dataset

SimpleRules

-m_root

-m_unpruned

-m_CF

-m_minNumObj

-m_useLaplace

-m_reducedErrorPruning

-m_numFolds

-m_binarySplits

-m_subtreeRaising

-m_noCleanup

-m_Seed

J48

-m_Successors

-m_Attribute

-m_ClassValue

-m_Distribution

-m_ClassAttribute

Id3

#mapWidth

#mapHeight

#mapTopology

#neighbourhoodFunction

#learningFunction

#neighbourhoodSize

#learningRate

#trainingIterations

#supervised

Som

1

*

1

*

1

1

1

1

1

1

1

1

Figura ‎A.1: Diagrama de clases fundamentales del banco de pruebas

Scenario: Clase que caracteriza a un dominio, un escenario de experimentación. Sus

atributos corresponden a los parámetros que rigen el banco de pruebas. Experience: Clase que caracteriza a una experiencia. Cada experiencia consiste en la variación del parámetro variableParameter desde su valor from a su valor to, calculando el resultado para cada valor iterationsPerValue veces. ExperienceIteration: Clase que realiza cada una de las iteraciones de experimentación. Posee una referencia a su Experience, la cual tiene una referencia a Scenario, camino por el cual


94 Metodología

obtiene la información necesaria para la iteración de experimentación. A su vez, almacena en el atributo x, el valor de variableParameter que corresponde a la iteración. Como otros atributos tiene al generador del dominio, al mapa SOM, a los árboles TDIDT y a los resultados obtenidos de haber ejecutado la iteración. SimpleRules: Clase generadora de dominios, de acuerdo al método descripto en la sección 4.3. Som: Clase que implementa la red neuronal SOM como algoritmo de agrupamiento. J48: Clase que implementa el algoritmo J48 (C4.5) como árbol de inducción de reglas TDIDT. Id3: Clase que implementa el algoritmo ID3 como árbol de inducción de reglas TDIDT.

A.2.2 Casos de Uso

En la siguiente figura se presentan los casos de uso del sistema desde un enfoque de alta abstracción. Estos corresponden a las acciones que el experimentador (actor) realiza sobre el sistema.

Experimentador

Correr experiencias

Unificar datos de

distintas DBs

Graficar

experiencias

Figura ‎A.2: Diagrama de casos de uso de alto nivel de abstracción


Metodología 95

A.2.2.1 Ejecución de experiencias

Para la mejor comprensión del proceso de ejecución de experiencias, es necesario hacer un análisis más detallado del caso de uso de alto nivel.

ExperienceRunner

Cargar o crear

Scenario

Crear Experience

Correr Experience

Correr cada

ExperienceIteration

Figura ‎A.3: Diagrama de casos de uso de ejecución de experiencias

Antes de ejecutar una experiencia, es necesario obtener la instancia necesaria del escenario, o bien crearla en caso que no exista. Tras esto, sí se puede crear la experiencia y comenzar a correrla, lo cual dará inicio a la ejecución de cada una de las iteraciones.

Cada iteración de una experiencia está compuesta por una serie de acciones:


96 Metodología

Generar el dominio

Correr la SOM

Correr TDIDT

ExperienceIteration

Determinar reglas

cubiertas de forma correcta

Figura ‎A.4: Diagrama de casos de uso de iteraciones

De esta manera, para ejecutar una iteración es necesario generar el dominio, aplicar sobre éste SOM como algoritmo de agrupamiento, educir reglas mediante TDIDT y determinar el porcentaje de reglas cubiertas de forma correcta.

A.2.3 Diagrama de transición de estados A.2.3.1 Ejecución de experiencias

Con el objetivo de una mejor comprensión del proceso de ejecución de una experiencia -el cual engloba cada una de sus iteraciones-, se presenta a continuación un diagrama de transición de estados, el cual detalla los diferentes estados en que se encontrará la ejecución de la experiencia para ser completada:


Metodología 97

Correr ExperienceIteration

Persistir ExperienceIteration

x = desde

iteración = 1

iteración = iteración + 1

X <= hasta

X = hasta

x = x + 1

Iteración <= iteraciones

Iteración = iteraciones

Figura ‎A.5: Diagrama de transición de estados de ejecución de experiencias

Se procesa cada uno de los valores del parámetro a variar, tantas veces como

se han indicado las iteraciones cuyos resultados más tarde serán promediados.

A.3 Diseño

El diseño de la solución se dividió en las partes identificadas en el análisis. Es así como a continuación se describirán las soluciones de diseño adoptadas por la ejecución de las experiencias, la graficación de los resultados obtenidos, y la unificación de los resultados obtenidos para su análisis en conjunto.


98 Metodología

A.3.1 Ejecución de experiencias

Para llevar adelante la ejecución de las experiencias, se ha diseñado un conjunto de 8 clases, las cuales serán descriptas a continuación: A.3.1.1 Scenario

Se trata de una clase de entidad que contiene información sobre los que han sido definidos como parámetros del banco de pruebas. Mediante esta clase, es posible definir las características de los dominios y las condiciones bajo las cuales se va a llevar la experimentación, lo cual termina conformando un escenario de experimentación. A.3.1.2 Experience

Esta clase toma un escenario y define un plan de experimentación basado en hacer variar un determinado parámetro en un rango de valores, calculando el resultado obtenido para cada uno de los valores una cierta cantidad de veces. Estas son las denominadas iteraciones y tienen como objetivo reducir el error proveniente de la incidencia de la función azar como herramienta de determinación del dominio. A.3.1.3 ExperienceIteration

Cada instancia de esta clase responde a una instancia de Experience, ya que las instancias de esta clase son las iteraciones realizadas para cumplir con la experiencia definida en la clase Experience.

Cada atributo de esta clase, tiene además una instancia de las clases que permiten generar el dominio, aplicar SOM, aplicar TDIDT con el objetivo de evaluar el porcentaje de reglas cubiertas de forma correcta tras la aplicación de SOM y TDIDT como mecanismo de descubrimiento de conocimiento. A.3.1.4 SimpleRules

Esta clase es un generador que implementa la interfaz ClassificationGenerator del conjunto de clases provistas por la Universidad de Waikato. Haciendo uso de este generador, es posible crear dominios de acuerdo al método descripto en la sección 4.3. A.3.1.5 Som

Clase escrita por Jason Brownlee que implementa en Java las funciones del paquete de software SOM_PAK, como aportación al conjunto de clases de la Universidad de Waikato.


Metodología 99

A.3.1.6 J48

Clase perteneciente al conjunto de clases de la Universidad de Waikato, que implementa el algoritmo J48 (C4.5) como árbol de inducción de reglas TDIDT. A.3.1.7 Id3

Clase perteneciente al conjunto de clases de la Universidad de Waikato, que implementa el algoritmo ID3 como árbol de inducción de reglas TDIDT. A.3.1.8 ExperienceRunner

Clase que permite definir una serie de experiencias a ser realizadas sobre el banco de pruebas, corriendo en modo batch.

Esta clase no aparece en el diagrama de clases, debido a que es una clase de control cuyo objetivo es diseñar las experiencias a realizar y ejecutarlas.

A.3.2 Graficación de resultados

Para presentar mediante gráficas los resultados obtenidos, se ha desarrollado la clase GraphDrawer, la cual permite generar las gráficas predefinidas en la base de datos.

A.3.3 Unificación de los resultados obtenidos para su análisis en conjunto

Con el objetivo de unificar en una única base de datos los resultados

almacenados en distintas bases de datos, se ha desarrollado la clase DbMerger que permite migrar todos los datos de las experiencias indicadas de una base de datos origen a una base de datos destino, generando un conjunto de datos consolidado.

A.4 Codificación

La codificación del banco de pruebas ha sido realizada en lenguaje Java, utilizando como soporte de persistencia a PostgreSQL como base de datos.


100 Metodología

Tanto el código fuente de todas las clases como los scripts de generación de la base de datos, se encuentran en el CD que acompaña a esta tesis.

A.5 Implementación

A.5.1 Procesos y Pantallas

El banco de pruebas que se construyó no cuenta con procesos online, sino que está compuesto de los siguientes procesos batch:

Ejecución de experiencias.

Graficación de resultados.

Unificación de los resultados obtenidos para su análisis en conjunto.

Debido a la especificidad de las instrucciones para cada proceso batch y a la complejidad de representar estas instrucciones en un archivo de entrada a los procesos, sumado a la simplicidad con la que se puede definir en código Java dichas instrucciones, es que los procesos batch no tienen archivos de entrada, sino que sus especificaciones se encuentran hardcoded en las rutinas que inician los procesamientos.

A continuación se presentan cuadros que sintetizan cada uno de los procesos,

sus funciones principales, la información que debe ser especificada en el código que inicia el proceso y el resultado que se obtiene tras su ejecución. A.5.1.1 Ejecución de experiencias.

Ambiente UNIX / Windows / MAC Línea de comando en lenguaje interpretado multiplataforma.

Modo de Ejecución

java -Xmx512m -cp classpath \

ar.com.arikogan.bdp.ExperienceRunner

Configuración de proceso

Base de datos con la cual trabajar

Definición de escenarios

Definición de experiencias

Salida Se persisten en la base de datos los registros correspondientes a los escenarios, las experiencias y sus iteraciones involucradas en la ejecución del proceso. En el standard output se obtiene el log del proceso de ejecución de las experiencias.

classpath = .:[path del jar del banco de pruebas]:[path del jar

de PostgreSQL]


Metodología 101

A.5.1.2 Graficación de resultados.


Modo de Ejecución java -Xmx512m -cp classpath \

ar.com.arikogan.bdp.GraphDrawer


ID de los gráficos a generar

Salida Archivos PNG con las gráficas en color y blanco y negro. En el standard output se obtiene el log del proceso.


de PostgreSQL]:[path del jar de JFreeChart]

A.5.1.3 Unificación de los resultados obtenidos para su análisis en conjunto.


Modo de Ejecución

java -Xmx512m -cp classpath \

ar.com.arikogan.bdp.DbMerger


Base de datos origen

Base de datos destino

Experiencias a migrar

Salida Las experiencias indicadas contenidas en la base de datos origen, son migradas a la base de datos destino. En el standard output se obtiene el log del proceso.


de PostgreSQL]


102 Metodología

A.6 Pruebas

A.6.1 Plan de pruebas

Objetivo de la prueba Detectar errores de programación y funcionamiento en el sistema banco de pruebas

Objetos a probar 1. Ejecución de experiencias 2. Graficación de resultados 3. Unificación de los resultados obtenidos para su

análisis en conjunto

Características a probar

Funcionamiento de cada una de los procesos para un conjunto de tareas definido a tal fin. La prueba se realizará tanto en plataforma Windows como Linux.

Características a no probar

No se probará la velocidad o performance de la herramienta.

Cantidad de casos de prueba

10

A.6.2 Documento de diseño de la prueba

Procedimiento de pruebas

Las pruebas serán llevadas a cabo de acuerdo a lo descripto en la sección A.6.4 (Especificación del procedimiento de prueba) registrándose las anomalías observadas.

Métodos de prueba a utilizar

Se utilizará el método de caja negra, adivinación de errores, para poder así determinar las posibles fallas del sistema.

Criterios para la aprobación de las pruebas

Los criterios para la aprobación de las pruebas se realizarán de acuerdo a la siguiente tabla: Excelente: Cuando el resultado obtenido luego de realizada la prueba es idéntico al resultado citado en la sección A.6.3 - Especificación de los casos de prueba. Muy bueno: Cuando el resultado obtenido luego de realizada la prueba es parecido al resultado citado en la sección A.6.3 - Especificación de los casos de prueba. Bueno: Cuando el resultado obtenido luego de realizada la prueba no fue el resultado citado en la sección A.6.3 - Especificación de los casos de prueba, pero no ha provocado anomalías en el funcionamiento de la herramienta. Regular: Cuando el resultado obtenido luego de realizada la prueba no fue el resultado citado en la sección A.6.3 -


Metodología 103

Especificación de los casos de prueba, pero ha provocado anomalías en el funcionamiento del programa. Malo: Cuando el resultado obtenido luego de realizada la prueba no fue el resultado citado en la sección A.6.3 - Especificación de los casos de prueba, pero ha provocado anomalías en el funcionamiento del programa tales como la salida del sistema o “colgarse”.

A.6.3 Especificación de los casos de prueba

Ítem Objetivo Acción Entrada Resultado esperado

1 Correr una experiencia para la cual no existe un escenario

Ejecutar ExperienceRunner

Indicar para la experiencia un escenario que no existe

El escenario debe ser creado en la base de datos y la experiencia debe referenciar a éste

2 Correr una experiencia para la cual sí existe un escenario


Indicar para la experiencia un escenario que sí existe

No debe crearse ningún escenario en la base de datos y la experiencia debe referenciar al preexistente con las características dadas

3 Correr una experiencia donde el parámetro a variar toma 3 valores y se ejecuta 1 iteración por valor


Indicar para la experiencia que el parámetro a variar toma 3 valores y se ejecuta 1 iteración por valor.

Se deben haber creado 3 iteraciones para la experiencia, cada una con un valor distinto de x, pero correspondientes a los valores a tomar por el parámetro que varía.

4 Correr una experiencia donde el parámetro a variar toma 3 valores y se ejecutan 10 iteraciones por valor


Indicar para la experiencia que el parámetro a variar toma 3 valores y se ejecutan 10 iteraciones por valor.

Se deben haber creado 30 iteraciones para la experiencia, 10 para cada uno de los valores a tomar por el parámetro que varía.


104 Metodología

5 Correr una experiencia en la cual la cantidad de atributos sobre los que se imponen condiciones es igual a la cantidad de atributos de los ejemplos.


Indicar iguales la cantidad de atributos sobre los que se imponen condiciones y la cantidad de atributos de los ejemplos.

Se debe arrojar una excepción y no generar ninguna iteración para la experiencia.

6 Migrar experiencias de una base de datos a otra, referenciando las experiencias en origen escenarios presentes en destino.

Ejecutar DbMerger

Indicar experiencias a migrar que referencien escenarios preexistentes en destino

Las experiencias migradas deben referenciar a los escenarios preexistentes en destino y no deben crearse nuevos escenarios.

7 Migrar experiencias de una base de datos a otra, referenciando las experiencias en origen escenarios no existentes en destino.

Ejecutar DbMerger

Indicar experiencias a migrar que referencien escenarios no existentes en destino

Los escenarios deben ser migrados a la base de datos destino (creados en ésta), así como las experiencias, las cuales deben pasar a referenciar los escenarios recién creados.

8 Migrar experiencias inexistentes en la base de datos origen.

Ejecutar DbMerger

Indicar experiencias a migrar no existentes en la base de datos origen.

Se debe arrojar una excepción y detener el proceso.

9 Generar gráficas definidas en la base de datos.

Ejecutar GraphDrawer

Indicar gráficas a generar existentes en la base de datos.

Se deben generar los archivos de imagen PNG para las gráficas a color y blanco y negro.

10 Generar gráficas no definidas en la base de datos.

Ejecutar GraphDrawer

Indicar gráficas a generar inexistentes en la base de datos.



Metodología 105

A.6.4 Especificación del procedimiento de prueba

Ítem Acción Entrada Resultado esperado

1 Ejecutar ExperienceRunner















6 Ejecutar DbMerger Indicar experiencias a migrar que referencien escenarios preexistentes en destino


7 Ejecutar DbMerger Indicar experiencias a migrar que referencien escenarios no existentes en destino


8 Ejecutar DbMerger Indicar experiencias a migrar no existentes en la base de datos origen.



106 Metodología

9 Ejecutar GraphDrawer






A.6.5 Informe de los casos de prueba ejecutados

Ítem Acción Entrada Resultado esperado Resultado obtenido




Excelente




Excelente




Excelente




Excelente




Excelente


Metodología 107

6 Ejecutar DbMerger

Indicar experiencias a migrar que referencien escenarios preexistentes en destino


Excelente

7 Ejecutar DbMerger

Indicar experiencias a migrar que referencien escenarios no existentes en destino


Excelente

8 Ejecutar DbMerger

Indicar experiencias a migrar no existentes en la base de datos origen.


Excelente




Excelente




Excelente

A.6.6 Informe de la prueba

El banco de pruebas funcionó de acuerdo a lo esperado al ser sometido a las pruebas descriptas en las secciones anteriores.

A.7 Gestión de configuración

A.7.1 Identificación de la configuración

Nombre de la aplicación

Banco de pruebas de la combinación de agrupamiento por SOM e inducción por TDIDT como mecanismo de descubrimiento de conocimiento.


108 Metodología

Objetivo de la aplicación

Proveer una plataforma que permita realizar experimentos sobre el comportamiento de agrupamiento por SOM e inducción por TDIDT como mecanismo de descubrimiento de conocimiento.

Ciclo de vida del software

Modelo en cascada.

Fases del ciclo de vida

1. Requerimientos (sección A.1) 2. Análisis (sección A.2)

a. Diagrama de clases (sección A.2.1) b. Casos de uso (sección A.2.2) c. Diagrama de transición de estados (sección A.2.3)

3. Diseño (sección A.3) a. Ejecución de experiencias (sección A.3.1) b. Graficación de resultados (sección A.3.2) c. Unificación de los resultados obtenidos (sección A.3.3)

4. Codificación (sección A.4) 5. Implementación (sección A.5)

a. Procesos y pantallas (sección A.5.1) 6. Pruebas (sección A.6)

a. Plan de pruebas (sección A.6.1) b. Documento de diseño de la prueba (sección A.6.2) c. Especificación de los casos de prueba (sección A.6.3) d. Especificación del procedimiento de prueba (sección

A.6.4) e. Informe de los casos de prueba ejecutados (sección

A.6.5) f. Informe de la prueba (sección A.6.6)

7. Gestión de configuración (sección A.7) a. Identificación de la configuración (sección A.7.1) b. Control de configuración (sección A.7.2) c. Generación de informes de estado (sección A.7.3)

Líneas base establecidas

Para el desarrollo del presente trabajo se han acotado las líneas base como los elementos de configuración definidos. En este caso el criterio es que, dado que es una sola persona -el tesista- quien realiza la documentación del proyecto y la programación, se ha definido una sola línea base para todo el proceso de desarrollo, programación e implementación cuyas fases y elementos de configuración se detallaron en la sección anterior.

A.7.2 Control de configuración

Utilizando como fuente de información, control y seguimiento una base de datos de cambios, se implementa el siguiente mecanismo para el control de los mismos:


Metodología 109

Generación de una solicitud de cambio Ante el requerimiento de un cambio funcional o un reporte de error, se completa la correspondiente solicitud.

Ingreso de la solicitud a la base de datos de cambios Una vez recibida la solicitud de cambio, se la ingresa en la base de datos de cambios.

Análisis de la solicitud de cambio Cada solicitud de cambio debe ser analizada y se debe decidir si se rechaza o se acepta el cambio. La decisión tomada queda registrada en la base de datos de cambios.

Evaluación de la solicitud de cambio Si se decide la aceptación de la solicitud de cambio, se debe realizar la evaluación técnica de la misma, emitiendo un informe en donde se exprese el esfuerzo requerido para satisfacer el pedido, las repercusiones que dicho cambio genera en otros elementos y el costo estimado. La evaluación realizada, queda registrada en la base de datos de cambios.

Generación de la orden de cambio El informe generado durante la evaluación de la solicitud de cambio, se somete a análisis asignándole la prioridad y los recursos necesarios. Se emite una orden de cambio.

Realización del cambio Se realiza el cambio, se registra y se realiza el control de la modificación.

Prueba e implementación del cambio Se certifica que el cambio funciona correctamente y se procede a su implementación, a través de la modificación de manuales y documentos que deban reflejar el cambio.

A.7.3 Generación de informes de estado A.7.3.1 Solicitud de cambios

Sistema: BDP Fecha dd/mm/aaaa

Pedido por:

Resultado de la evaluación: Aceptado Rechazado

Cambio solicitado:


110 Metodología

Solución propuesta:

Elementos del producto software afectados por el cambio:

Documentación anexa presentada:

Solución propuesta por el área de desarrollo:

Tiempo estimado en horas (análisis, programación y pruebas, e implementación):

Cronograma de desarrollo e implementación:

Plan de pruebas:

A.7.3.2 Orden de cambios

Sistema: BDP Fecha: dd/mm/aaaa

Pedido por: Nº solicitud:

Cambio a realizar:

Elementos del producto software afectados por el cambio:

Tiempo estimado en horas (análisis, programación y pruebas, e implementación):

Comentarios del cambio:

Fecha de entrega: dd/mm/aaaa


Metodología 111

A.7.3.3 Registro de cambios


Pedido por: Nº solicitud

Fecha de solicitud dd/mm/aaaa

Descripción breve del problema:

Fecha de evaluación: dd/mm/aaaa

Resultado de la evaluación Aceptado Rechazado

Comentarios:

Prioridad asignada: ALTA | MEDIA | BAJA

Estado actual del pedido:

Fecha de terminación: dd/mm/aaaa

A.7.3.4 Registro de instalaciones


Nº solicitud

Descripción breve del problema:

Fecha de evaluación: dd/mm/aaaa

Versión instalada:

A.7.3.5 Informe de estado de cambios


Fecha desde: dd/mm/aaaa Fecha hasta: dd/mm/aaaa

dd/mm/aaaa

dd/mm/aaaa


112 Metodología

dd/mm/aaaa

dd/mm/aaaa

A.7.3.6 Informe de instalación


Fecha desde: dd/mm/aaaa Fecha hasta: dd/mm/aaaa

dd/mm/aaaa

dd/mm/aaaa

dd/mm/aaaa

dd/mm/aaaa


Manual de Usuario 113

B Manual de Usuario

En este anexo se transcribe el manual de usuario del banco de pruebas. Se introduce el banco de pruebas (sección B.1) describiendo sus componentes

(sección B.1.1), la plataforma y el lenguaje para los cuales está desarrollado (sección B.1.2), las librerías utilizadas (sección B.1.3) y se presenta el producto (sección B.1.4).

Se enumeran los requerimientos previos para poner en funcionamiento el producto (sección B.2), se detalla el procedimiento para configurar el entorno de trabajo (sección B.3) mediante el establecimiento del classpath apropiado (sección B.3.1) y la creación del esquema necesario para la base de datos (sección B.3.2).

Finalmente, se describe la forma de utilizar el banco de pruebas (sección B.4), tanto para los procedimientos comunes a todas las operaciones (sección B.4.1), como para la ejecución de experiencias (sección B.4.2), unificación de datos (sección B.4.3) y graficación de resultados (sección B.4.4).

B.1 Introducción

El banco de pruebas desarrollado para esta tesis, es una herramienta que permite realizar experimentos para estudiar la efectividad del agrupamiento por SOM e inducción por TDIDT como mecanismo de descubrimiento de conocimiento.

Con el objetivo de ponerlo operativo, es necesario satisfacer ciertos

requerimientos, configurar el entorno en el que se va a trabajar, y finalmente verificar su correcto funcionamiento.

B.1.1 Descripción de los componentes El sistema como un todo está integrado por los siguientes componentes:

1. Conjunto de clases que proveen los algoritmos con los cuales se va a

experimentar.

2. Clases que permiten definir y ejecutar la experimentación a realizar, así como generar gráficas para su análisis.

3. Base de datos utilizada como soporte de persistencia de las experiencias realizadas y los resultados obtenidos.

B.1.2 Plataforma y lenguaje

El sistema ha sido desarrollado en lenguaje Java y hace uso de PostgreSQL como motor de base de datos, el cual corre en los principales sistemas operativos. Es así como el sistema es por completo multiplataforma.


114 Manual de Usuario

B.1.3 Librerías utilizadas

Para conformar el conjunto de clases que proveen los algoritmos con los cuales se va a experimentar, se hizo uso de un conjunto de clases provistas por la Universidad de Waikato, así como de un paquete de clases desarrolladas por Jason Brownlee1 que implementan en Java la funcionalidad del paquete de software SOM_PAK2, como aportación al primer conjunto de clases. B.1.3.1 Weka

Weka [Ian & Frank, 2005] es una colección de algoritmos de aprendizaje automático para tareas de minería de datos. Los algoritmos pueden ser aplicados directamente sobre conjuntos de datos o bien ser llamados desde código Java propio, el cual es el uso que se ha hecho en este sistema.

Weka cuenta con una serie de herramientas para el pre-procesamiento de datos, clasificación, regresión, agrupamiento, reglas de asociación y visualización. Asimismo, permite utilizar de forma simple nuevos esquemas desarrollados.

Es así como se ha desarrollado sobre la base de Weka, una serie de herramientas para realizar las labores de experimentación de esta tesis.

De la misma manera, gracias a las herramientas provistas por Weka y la plataforma de experimentación provista por el banco de pruebas, es posible realizar labores de experimentación sobre otros algoritmos de forma muy simple. Weka es software libre publicado bajo Licencia Pública General GNU. B.1.3.2 Weka Classification Algorithms (WCA)

Este proyecto provee la implementación en Java de una serie de algoritmos de inteligencia artificial, como complemento a Weka.

Entre estos, se encuentra el algoritmo SOM tal cual como es presentado en el paquete SOM_PAK preparado por la Universidad de Tecnología de Helsinki.

Weka Classification Algorithms es software libre publicado bajo Licencia Pública General GNU.

B.1.4 Presentación del producto

La presentación del producto consiste en:

1 http://wekaclassalgos.sourceforge.net/

2 http://www.cis.hut.fi/research/som_pak/



Un único archivo jar que recopila las librerías utilizadas de Weka, WCA, y las incorporaciones realizadas.

Un conjunto de archivo de extensión java que contienen las clases que permiten definir y ejecutar la experimentación a realizar, así como generar gráficas para su análisis.

Archivos de extensión sql que contienen los scripts SQL para la creación y mantención del esquema de base de datos utilizado como soporte de la información de experimentación y sus resultados.

B.2 Requerimientos

Para comenzar a utilizar el banco de pruebas, existe una serie de requerimientos de software, los cuales serán descriptos a continuación, junto a breves indicaciones sobre su instalación.

Si bien este documento procura servir de guía para el experimentador que desea comenzar a utilizar el banco de pruebas, no puede abarcar la cantidad de variantes que pueden surgir al incorporar los requerimientos necesarios, así como detallar con profundidad los pasos para su instalación. Es por eso que se recomienda recurrir al manual de usuario de cada producto en particular.

B.2.1 Máquina virtual Java

Para ejecutar código Java, es necesario tener instalada la máquina virtual Java. La versión en español, junto a documentación en el mismo idioma, se puede encontrar en http://www.java.com/es/download/

B.2.2 PostgreSQL

PostgreSQL es el motor de base de datos elegido para el almacenamiento de los datos de los experimentos y sus resultados.

Además del servidor de base de datos, hay disponibles clientes de administración y drivers JDBC. La instalación de estos componentes se detalla a continuación. B.2.2.1 Servidor de base de datos

El instalador del servidor de base de datos para distintas plataformas puede ser descargado de http://www.postgresql.org/download/.

http://www.java.com/es/download/

http://www.postgresql.org/download/



Una vez instalado el servidor de base de datos, es conveniente crear un rol con el cual se va a trabajar. La documentación sobre esta operación se puede encontrar en http://www.postgresql.org/docs/8.2/interactive/sql-createrole.html. B.2.2.2 Herramienta de administración pgAdmin

pgAdmin es una herramienta standalone para distintas plataformas que permite la administración de un servidor PostgreSQL y sus bases de datos. La misma puede ser descargada de http://www.pgadmin.org/download/. B.2.2.3 Driver JDBC

Con el objetivo de conectarse a una base de datos PostgreSQL desde código Java, es necesario utilizar el driver JDBC apropiado.

El correspondiente a PostgreSQL puede ser descargado de http://jdbc.postgresql.org/download.html.

B.2.3 JFreeChart

El componente del sistema que permite graficar los resultados obtenidos en la experimentación, hace uso de una biblioteca de graficación para Java llamada JFreeChart. La misma puede ser descargada de http://www.jfree.org/jfreechart/download.html.

B.3 Configuración del entorno

B.3.1 Classpath

El classpath es el camino por el cual el entorno de ejecución Java busca las clases y otros archivos de recursos necesario para la ejecución de cierto código. Para la correcta ejecución de los distintos componentes del banco de pruebas, estos deben tener en su classpath las librerías a las cuales hace llamados. Es por eso que el correcto establecimiento del classpath es fundamental para ejecución de las operaciones. Instrucciones para establecer el classpath tanto en ambientes Unix como Windows, se pueden encontrar en:

http://www.postgresql.org/docs/8.2/interactive/sql-createrole.html

http://www.pgadmin.org/download/

http://jdbc.postgresql.org/download.html

http://www.jfree.org/jfreechart/download.html



Windows http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/classpath.html Linux y Solaris

http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/classpath.html

Como ejemplo para establecer el classpath suponiendo:

Un ambiente de trabajo Windows

Estar ubicado en el path origen de las clases a ejecutar.

El directorio que almacena todos los jars necesarios es <jar_dir>

Que la versión utilizada del driver JDBC de PostgreSQL es la 8.1-407

Que la versión utilizada de JFreeChart es la 1.0.1

Que los saltos de línea son únicamente para exhibir de forma clara la sentencia en este documento, pero que en realidad va todo en una misma línea y no hay espacios entre los componentes del classpath (aquellos paths separados por coma). Se transcriben a continuación las sentencias para la ejecución de cada uno de

los componentes del banco de pruebas en la máquina virtual Java, indicando el classpath para cada caso: Ejecución de experiencias: java -cp .;"<jar_dir>\weka-bdp-1.0.jar";

"<jar_dir>\postgresql-8.1-407.jdbc3.jar"


Unificación de datos: java -cp .;"<jar_dir>\weka-bdp-1.0.jar";



Graficación de resultados: java –cp .;

"<jar_dir>\weka-bdp-1.0.jar";

"<jar_dir>\postgresql-8.1-407.jdbc3.jar";

"<jar_dir>\jfreechart-1.0.1.jar"


http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/classpath.html

http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/classpath.html



En el caso de un ambiente Unix, las sentencias son similares, aunque se

reemplazan los “;” por “:” y se eliminan las comillas.

B.3.2 Creación del esquema de base de datos

Tras la creación de la base de datos con la cual se va a trabajar, es necesario crear secuencias y tablas que conforman el esquema de base de datos necesario para trabajar.

Para crear este esquema, simplemente es necesario ejecutar las sentencias SQL contenidas en el archivo bdp-create.sql que contiene el CD que acompaña a esta tesis.

Asimismo, si se ha cometido algún error y se quiere comenzar a trabajar de nuevo sobre una base de datos, el script bdp-drop.sql permite eliminar todos los objetos creados por el script de creación.

B.4 Utilización del banco de pruebas

Una vez cumplidos los pre-requisitos y configurado el entorno, están dadas la condiciones para hacer uso de la herramienta de experimentación.

Debido a que cada operación es realizada por la ejecución de una clase Java, a continuación se mostrará mediante ejemplos, cómo escribir código Java que permita llevar adelante cada una de las operaciones. La profundización y el mejoramiento de las estrategias, recae en el experimentador ya que es éste quien conoce el trabajo que está llevando adelante y los resultados que desea obtener.

B.4.1 Procedimientos comunes a todas las operaciones

Existen una cantidad de pasos comunes a todas las operaciones, los cuales son descriptos a continuación. B.4.1.1 Comunicación con la base de datos

Todas las clases se comunican con la base de datos, por lo que es necesario configurar el host, nombre de la base de datos, usuario y contraseña. Esto se realiza mediante la edición de los siguientes atributos de clase: private static final String DB_CONN_STR = "jdbc:postgresql://<host>:<port>/<db>";

private static final String DB_USER_NAME = "<user>";

private static final String DB_PASSWORD = "<password>"; Donde:



<host> Es la dirección del servidor de base de datos <port> Es el puerto en el cual escucha el servidor de base de datos <db> Es el nombre de la base de datos a utilizar <user> Es el usuario con el cual se autentifica contra el servidor de DB <password> Es la contraseña del usuario de DB B.4.1.2 Compilación de la clase a ser ejecutada

Una vez modificado el código de cada una de clases, es necesario compilarlas antes de poder ejecutarlas.

El compilador para el lenguaje Java es javac. Su referencia para Windows y Unix se puede encontrar en:

Windows http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html Linux y Solaris http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/javac.html

Suponiendo:

Un ambiente de trabajo Windows

Estar ubicado en el path origen de las clases a ejecutar.

El directorio que almacena todos los jars necesarios es <jar_dir>

Que la versión utilizada del driver JDBC de PostgreSQL es la 8.1-407

Que la versión utilizada de JFreeChart es la 1.0.1

Que los saltos de línea son únicamente para exhibir de forma clara la sentencia en este documento, pero que en realidad va todo en una misma línea y no hay espacios entre los componentes del classpath (aquellos paths separados por coma). Se transcriben a continuación las sentencias para la compilación de cada una de

las clases: Ejecución de experiencias: javac -cp .;"<jar_dir>\weka-bdp-1.0.jar";



http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html

http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/javac.html



Unificación de datos: javac -cp .;"<jar_dir>\weka-bdp-1.0.jar";



Graficación de resultados: javac –cp .;

"<jar_dir>\weka-bdp-1.0.jar";

"<jar_dir>\postgresql-8.1-407.jdbc3.jar";

"<jar_dir>\jfreechart-1.0.1.jar"


Como se puede observar, el comando que se ejecuta es javac, el compilador de Java.

Estas operaciones, en caso de ser exitosas, generarán un archivo de extensión class para cada una de las clases. B.4.1.3 Ejecución de la clase

Una vez que la clase a ejecutar, haya sido compilada con éxito, se puede invocar a la máquina virtual para su ejecución.

Las sentencias de ejecución son las transcriptas en la sección B.3.1. Debido a que algunas rutinas pueden demorar horas o días en ejecutarse, en la

presente sección se mencionan algunas técnicas para tomar ciertos resguardos y procurar no interrumpir su ejecución, al mismo tiempo de no saturar por completo el procesador de la máquina.

Estas técnicas están focalizadas principalmente en sistemas Unix. B.4.1.3.1 Especificación de la memoria máxima a utilizar por la JVM

Es posible indicarle al comando Java la máxima cantidad de memoria a alocar. La ejecución de alguna de las rutinas del banco de prueba pueden llegar a

requerir una gran cantidad de memoria, por lo cual es conveniente establecer en un nivel elevado la cantidad de memoria máxima a alocar por la máquina virtual Java.

Esta operación se puede realizar mediante la opción –Xmx del comando Java: java -Xmx512m –cp <classpath> <clase_a_ejecutar>



Es así como la clase <clase_a_ejecutar> será ejecutada con classpath <classpath> alocándose un máximo de memoria de 512 MB por parte de la máquina virtual Java. B.4.1.3.2 Redirección del stdout a un archivo

Las rutinas loggean su proceso en el stdout. Si se va a correr un proceso y se desea guardar en un archivo los mensajes que arroja al stdout, éste puede ser redirigido a un archivo.

En una consola, esta operación se puede realizar con el operador >: <comando> > <archivo_de_loggeo>

Es así como todo lo que el comando <comando> arroja al stdout y stderr, irá a

parar al archivo <archivo_de_loggeo> B.4.1.3.3 Resguardo contra señales SIGHUP

En el caso que la rutina sea invocada desde una consola remota (ej.: SSH), existe la posibilidad que ésta se desconecte y con la muerte de su proceso, mueran todos sus hijos.

Con el fin de evitar esta situación y permitir que el comando siga corriendo a pesar que la consola que lo invocó se desconecte, se puede hacer uso del comando nohup con el objetivo de resguardar al comando invocado de las señales SIGHUP.

La sentencia para hacer el llamado en una consola, es la siguiente: nohup <comando>

De esta manera, el comando <comando> no responderá a las señales SIGHUP. B.4.1.3.4 Ejecución en background

Con el objetivo de poder seguir utilizando la consola desde la cual se invoca a la ejecución de una rutina que puede demorar horas o días, el proceso puede ser ejecutado en background.

Esta operación se puede realizar con el operador &: <comando> & El comando será ejecutado en background y el sistema informará el identificador de proceso de éste: [1] 16036



B.4.1.3.5 Modificación de la prioridad del proceso

Entre los procesos a utilizar, el de ejecución de experiencias hace un uso muy alto del procesador (por sobre el 90%).

Debido a que procesos como estos pueden correr por horas o días, puede ser deseable modificar la prioridad del proceso en el scheduler. Esta operación se puede realizar con el comando renice. $ <comando> &

[1] <pid>

$ renice <prioridad> <pid>

Se invoca al comando <comando> y se lo manda a background. El sistema informa el identificador de proceso <pid> que le fue asignado. Con el uso del comando renice, se modifica la prioridad del proceso <pid> y se establece en <prioridad>. B.4.1.3.6 Un ejemplo unificador

Si se supone que se quiere ejecutar ExperienceRunner permitiendo que la máquina virtual Java aloque un máximo de 512 MB de memoria, loggeando su stdout y stderr en un archivo, ejecutarlo en background, hacer que no responda las señales SIGHUP y establecer en el mínimo su prioridad, es necesario ejecutar las siguientes sentencias: $ nohup java -Xmx512m -cp <classpath> <clase_a_ejecutar> > <archivo_de_loggeo> &

[1] <pid>

$ renice 20 <pid>

B.4.2 Ejecución de experiencias

Para la ejecución de experiencias, se puede tomar como clase base a ExperienceRunner.

Fundamentalmente, la tarea de realizar experimentos consiste en:

1. Definir un escenario sobre el cual se va a experimentar. 2. Definir un parámetro a variar y su rango de variación. 3. Determinar cuántas iteraciones se calcularán por cada variante. 4. Dar inicio a la ejecución del experimento.

Si bien, para ganar versatilidad, la definición de las tareas de experimentación

pasa directamente por la codificación en Java de las rutinas, a continuación se demostrará con un breve ejemplo que es relativamente simple confeccionar un experimento y ejecutarlo.



Lo primero a realizar es definir un escenario sobre el cual se llevará adelante la experimentación. La definición de éste consiste en determinar el valor de los parámetros que lo rigen. Para trabajar con mayor claridad, primero se definirán variables que almacenen los valores para cada uno de los parámetros de un escenario. En código Java es: int attributesNumber = 6;

int attPossibleValues = 20;

int classPossibleValues = 5;

int rulesPerClass = 5;

int attUsedInRule = 3;

int instancesByRule = 10;

int classAttPossibleValuesPercentage = 20;

boolean mix = true;

boolean allowMultipleCoverage = false;

double allowedCoverageDesviation = 20;

int somTrainingIterationsMultiplier = 100;

int somMapWidth = 4;

int somMapHeight = 4;

Como se va a interactuar con la base de datos, es necesario abrir una conexión a ésta: Connection con = openConnection();

A continuación, se creará una nueva instancia de la clase Scenario, pasando como parámetros al constructor, las variables que hemos definido: Scenario scenario = new Scenario(attributesNumber,

attPossibleValues,

classPossibleValues,

rulesPerClass,

attUsedInRule,

instancesByRule,

classAttPossibleValuesPercentage,

mix,

allowMultipleCoverage,

allowedCoverageDesviation,

somTrainingIterationsMultiplier,

somMapWidth,

somMapHeight,

con);

Ya se tiene una instancia de Scenario. Esta instancia existe únicamente en memoria, por lo cual se puede verificar si hay en la base de datos una instancia que corresponda a ésta, y así ligarlas. En caso que no exista, se puede persistir la instancia que por ahora está en memoria, haciendo un llamado a su método save. if (!scenario.load())

scenario.save();



En este momento, se tiene una instancia de Scenario viva en memoria, que además está almacenada en la base de datos. Con un escenario ya creado, la experiencia consiste en variar un parámetro en determinado rango y registrar el porcentaje de la cantidad de reglas cubiertas de forma correcta que se obtiene cada vez. Experience experience = new Experience(scenario,

VariableParameter.ATTRIBUTES_NUMBER,

3,

10,

50,

con);

experience.setDescription("Variación de attributesNumber de 3 a 10");

Lo que se ha hecho fue crear una instancia de Experience para la cual el escenario es la instancia de scenario creada anteriormente, el parámetro a variar es la cantidad de atributos, el rango de variación de 3 a 10, y se realizarán 50 iteraciones para cada una de las variantes. Además, se ha agregado una descripción a la experiencia, la cual va a ser almacenada en la base de datos al momento de persistir la experiencia. Para hacer esto, simplemente hay que llamar a su método save: experience.save();

Tras esto, lo único que resta es iniciar la ejecución de la experiencia. Esto se realiza con el método run, el cual es bloqueante, es decir que no retornará el control hasta que haya finalizado la ejecución de toda la experiencia: experience.run();

En resumen, el código que se tuvo que escribir para realizar este experimento es: public void runSampleExperience() throws SQLException, Exception

{

int attributesNumber = 6;

int attPossibleValues = 20;

int classPossibleValues = 5;

int rulesPerClass = 5;

int attUsedInRule = 3;

int instancesByRule = 10;

int classAttPossibleValuesPercentage = 20;

boolean mix = true;

boolean allowMultipleCoverage = false;

double allowedCoverageDesviation = 20;

int somTrainingIterationsMultiplier = 100;

int somMapWidth = 4;

int somMapHeight = 4;

Connection con = openConnection();

Scenario scenario = new Scenario(attributesNumber,

attPossibleValues,

classPossibleValues,

rulesPerClass,



attUsedInRule,

instancesByRule,

classAttPossibleValuesPercentage,

mix,

allowMultipleCoverage,

allowedCoverageDesviation,

somTrainingIterationsMultiplier,

somMapWidth,

somMapHeight,

con);

if (!scenario.load())

scenario.save();

Experience experience = new Experience(scenario,

VariableParameter.ATTRIBUTES_NUMBER,

3,

10,

50,

con);

experience.setDescription("Variación de attributesNumber de 3 a

10");

experience.save();

experience.run();

}

B.4.3 Unificación de datos

Para la unificación de datos entre distintas bases de datos, se utiliza la clase DbMerger (se encuentra en el CD), la cual migra experiencias de una base de datos origen a una base de datos destino. A la clase hay que indicarle únicamente:

1. Los datos de la base de datos origen. 2. Los datos de la base de datos destino. 3. Los identificadores de las experiencias a migrar.

Los escenarios que utiliza cada una de las experiencias a migrar, son creados en

la base de datos destino en caso que no existan, o bien se asocian las experiencias migradas a escenario existentes.

La forma de consignar los datos de conexión a las bases de datos, es similar a la

descripta en la sección B.4.1.1, aunque en este caso se cuenta con un par de conexiones (se omiten identificadores del atributo para mayor claridad): DB_SOURCE_CONN_STR = "jdbc:postgresql://localhost:5432/origen";

DB_SOURCE_USER_NAME = "ak";

DB_SOURCE_PASSWORD = "";

DB_DESTINATION_CONN_STR = "jdbc:postgresql://localhost:5432/destino";

DB_DESTINATION_USER_NAME = "ak";

DB_DESTINATION_PASSWORD = "";



Tras esto, el único código a escribir es el del método determineExperiencesToMigrate(), en el cual se ingresan en una lista los identificadores de las experiencias a migrar.

Un método puede ser indicarlas una a una: experiencesToMigrate.add(1);

experiencesToMigrate.add(2);

También es posible determinar rangos o secuencias: for (int i=1; i<=5; i++)

experiencesToMigrate.add(i);

U obtenerlos mediante una consulta SQL sobre la base de datos origen: /* Esta rutina apunta a facilitar la determinación de las experiencias

* a migrar mediante la realización de una consulta sobre la db origen

*/

try {

PreparedStatement cs = srcConn.prepareStatement("select

experience_id from experience order by experience_id");

ResultSet rs = cs.executeQuery();

while (rs.next()) {

experiencesToMigrate.add(rs.getInt("experience_id"));

}

cs.close();

} catch (SQLException e) {

System.out.println("No se pudo obtener el listado de

experiencias a migrar realizando una consulta a la db origen");

e.printStackTrace();

}

Tras esto, simplemente es necesario ejecutar el método main de la clase para que la migración se realice.

B.4.4 Graficación B.4.4.1 Descripción de las tablas de organización

La rutina de graficación hace uso de 2 tablas para definir las gráficas a realizar. Éstas deben ser pobladas para que la clase GraphDrawer tome de ésta los datos necesarios para generar las gráficas. A continuación se describen.

Una tabla es graph, en la se indica cuál es el parámetro que se variará en el

eje x y cuál es aquel que tomará distintos valores discretos en cada una de las series graficadas. Además, se puede incluir una descripción para cada una de las gráficas.

Un ejemplo de algunas filas de esta tabla es:



graph_id variable_parameter series_parameter description

13 CLASS_POSSIBLE_VALUES ATTRIBUTES_NUMBER Dominio patrón variando classPossibleValues para distintos attributesNumber

14 CLASS_POSSIBLE_VALUES ATT_POSSIBLE_VALUES Dominio patrón variando classPossibleValues para distintos attPossibleValues

15 CLASS_POSSIBLE_VALUES RULES_PER_CLASS Dominio patrón variando classPossibleValues para distintos rulesPerClass

La tabla graph es la tabla maestro, existiendo una tabla detalle graph_experience, la cual indica cada una de las experiencias a incluir en la gráfica, siendo cada una, una serie. Todas las experiencias a integrar una gráfica deben tener al mismo parámetro de variación, ya que son los valores de éste los que tomará el eje x de la gráfica. En caso de incluir experiencias cuyos parámetros de variación no sean el indicado para la gráfica, la rutina de graficación arrojará una excepción. Un ejemplo de los registros de graph_experience para las gráficas anteriores es:

graph_experience_id graph_id experience_id place

60 13 148 1

61 13 149 2

62 13 150 3

63 13 151 4

65 14 153 1

66 14 154 2

67 14 155 3

68 14 156 4

69 15 157 1

70 15 158 2

71 15 159 3

72 15 160 4

73 15 161 5

B.4.4.2 Generación de las gráficas

Una vez pobladas las tablas que almacenan los datos sobre las gráficas a generar, el único paso necesario es determinar en el método main de GraphDrawer el identificador de las gráficas a generar.

Es posible declarar gráfica por gráfica:



graphsToPlot.add(24);

O bien un rango o secuencia de gráficas, haciendo uso de un ciclo for: for (int i=1; i<=42; i++)

graphsToPlot.add(i);

Tras esto, lo único que resta es ejecutar el método main de la clase.

Integración de Algoritmos de Inducción y...

Documents

Transcript of Integración de Algoritmos de Inducción y...