Un Modelo de Reglas de Asociacion...

UUNN MMOODDEELLOO DDEE RREEGGLLAASS DDEE AASSOOCCIIAACCIIÓÓNN

EESSPPAACCIIOO--TTEEMMPPOORRAALLEESS

Tesis de Grado

Ingeniería en Informática

Departamento de Computación

Mariano S. Kohan S.

78687

[email protected]

Director: Dr. Juan M. Ale

Abril, 2008

Un Modelo de Reglas de Asociación Espacio-Temporales Autor: Mariano Kohan Universidad de Buenos Aires – Facultad de Ingeniería Padrón: 78687

ii

Resumen El descubrimiento de reglas de asociación es una tarea del área de la minería de datos que permite obtener patrones que muestran conjuntos de elementos que co-ocurren de manera frecuente en un conjunto de transacciones. Con el avance en las tecnologías para la recolección y almacenamiento de datos han aparecido diversos tipos de trabajos sobre el descubrimiento de reglas de asociación espaciales y reglas de asociación temporales. Respecto al descubrimiento de reglas de asociación espacio-temporales, se pueden encontrar dos enfoques de trabajo planteados. En los trabajos del primero, se proponen aplicar algoritmos para el descubrimiento de reglas de asociación convencionales sobre las fuentes de datos espacio-temporales previamente procesadas para el uso con estos algoritmos. En los del otro enfoque, se plantean diferentes modelos, aplicables cada uno de los mismos sobre diversas estructuras de datasets espacio-temporales. En este trabajo se propone un modelo de reglas de asociación espacio-temporales, aplicable sobre bases de datos cuyas transacciones contienen componentes espaciales y temporales. El mismo resulta de la integración de conceptos planteados en modelos desarrollados previamente para el descubrimiento de reglas de asociación espaciales y reglas de asociación temporales, de manera separada. Los modelos desarrollados se han seleccionado para poder expresar cada tipo de conocimiento utilizando una semántica particular. Junto con este modelo, se presenta un algoritmo para el descubrimiento de dichas reglas de asociación espacio-temporales, basado en el cumplimiento por parte del modelo de la Propiedad de Monotonía de Apriori. Además, adicional con este algoritmo, se señalan las características mas importantes y necesarias para esta tarea. También, se muestra la implementación desarrollada a partir del algoritmo presentado. En base al algoritmo presentado y su implementación, se han realizado diversos tipos de pruebas. Los resultados obtenidos en las mismas muestran ejemplos de aplicación del modelo propuesto, así como el comportamiento del mismo en las pruebas de performance.


iii

Abstract The discovery of association rules is a data mining task that allows to obtain patterns that show elements sets that co-occur together in a frequent way inside a set of transactions. With the advance in data sensing and storage technologies have appeared diverse types of works about the discovery of spatial association rules and temporal association rules. With respect to the discovery of spatio-temporal association rules, we can observe two work approaches. In the works of the first one, they apply the algorithms for the discovery of conventional association rules over spatio-temporal data sources previously processed for the use with these algorithms. In the works of the other approach, they show different models, each one applicable on diverse structures of spatio-temporal datasets. This work proposes a model of spatio-temporal association rules, applicable over databases whose transactions contain spatial and temporal components. The same one results of the integration of concepts proposed on models developed previously for the discovery of spatial association rules and temporal association rules, in a separate way. The developed models were selected to express each type of knowledge using a particular semantic. Along with this model, we present an algorithm for the discovery of these spatio-temporal association rules, based on compliance of the Apriori Monotony Property by the model. Furthermore, along with this algorithm we indicate the most important and necessary characteristics for this task. Also, it shows the implementation developed from the presented algorithm. In base to the presented algorithm and their implementation we have made diverse sort of tests. The results obtained on the same ones show application examples of the proposed model, and their behavior in the performance tests.


iv

Contenido

1. Introducción...................................................................................................................... 1 1.1. Contribución de la tesis .............................................................................................. 2

1.2. Objetivo de la tesis ..................................................................................................... 2

1.3. Organización de la tesis.............................................................................................. 2

2. Panorama de trabajo ....................................................................................................... 4 2.1. Reglas de Asociación ................................................................................................. 4

2.2. Extendiendo el dominio de las reglas de asociación .................................................. 7 2.2.1. Reglas de Asociación Espaciales ............................................................................. 7 2.2.2. Reglas de Asociación Temporales ........................................................................... 9 2.2.3. Reglas de Asociación Inter-transacciones.............................................................. 11

2.3. Trabajos relacionados............................................................................................... 12 2.3.1. Primeros trabajos.................................................................................................... 12 2.3.2. Otros enfoques de reglas de asociación espacio-temporales.................................. 13 2.3.3. Comparación con el trabajo propuesto en esta tesis............................................... 15

3. Modelo ............................................................................................................................. 17 3.1. Estructura de datos ................................................................................................... 17

3.2. Itemset y conceptos relacionados............................................................................. 18 3.2.1. Predicados Espaciales ............................................................................................ 21

3.3. Reglas de asociación espacio-temporales ................................................................ 23 3.4. Propiedad de Monotonía del modelo ....................................................................... 25

3.4.1. Variantes de la propiedad....................................................................................... 26

4. Algoritmos....................................................................................................................... 30 4.1. Descubrimiento de las reglas de asociación espacio-temporales ............................. 30

4.1.1. Descubrimiento de los itemsets espacio-temporales frecuentes ............................ 30 4.1.1.1. Conceptos del algoritmo STApriori ............................................................................ 31

Descubrimiento de items frecuentes .................................................................................... 31 Generación de itemsets candidatos...................................................................................... 31 Verificación en transacciones y contabilización de itemsets ............................................... 33 Verificación de itemsets frecuentes según parámetros de umbrales.................................... 35

4.1.1.2. Pseudocódigo algoritmo STApriori............................................................................. 36 4.1.1.3. Prueba de correctitud................................................................................................... 39 4.1.1.4. Análisis de complejidad .............................................................................................. 42

4.1.2. Generación de reglas de asociación espacio-temporales........................................ 46

4.2. Extensión para atributos continuos .......................................................................... 47 4.3. Conversión entre estructuras de dataset ................................................................... 49

5. Implementación .............................................................................................................. 51 5.1. Solución implementada ............................................................................................ 51

5.2. Obtención de reglas de asociación espacio-temporales ........................................... 52 5.2.1. Parámetros de uso................................................................................................... 52 5.2.2. Clases asociadas ..................................................................................................... 52

5.3. Filtros ....................................................................................................................... 53 5.3.1. Filtros de discretización ......................................................................................... 54


v

5.3.1.1. Filtro de discretización desarrollado ........................................................................... 54 Parámetros de uso ............................................................................................................... 54

5.3.1.2. Filtro de discretización existente en Weka.................................................................. 55 5.3.2. Filtro para atributos de posiciones geográficas ...................................................... 55

5.3.2.1. Parámetros de uso........................................................................................................ 56 5.3.3. Filtro para conversión entre estructuras de datasets............................................... 56

5.3.3.1. Parámetros de uso........................................................................................................ 57

6. Experimentación............................................................................................................. 58 6.1. Ejemplos de aplicación............................................................................................. 58

6.1.1. Transporte de gas ................................................................................................... 58 6.1.1.1. Caso de Ejemplo.......................................................................................................... 59

Parámetros de uso ............................................................................................................... 60 Resultados obtenidos ........................................................................................................... 60

6.1.1.2. Caso de ejemplo alternativo ........................................................................................ 71 Parámetros de uso ............................................................................................................... 71 Resultados obtenidos ........................................................................................................... 73

6.1.2. Otras aplicaciones .................................................................................................. 83

6.2. Pruebas de performance ........................................................................................... 85 6.2.1. Tipos de Pruebas .................................................................................................... 85

6.2.1.1. Variables involucradas en el tamaño del dataset ......................................................... 85 6.2.1.2. Variables involucradas en los parámetros umbrales ................................................... 86

6.2.2. Pruebas realizadas .................................................................................................. 86 6.2.2.1. Tiempo en función de la cantidad de timestamps ....................................................... 86 6.2.2.2. Tiempo en función de la cantidad de sensores ............................................................ 90 6.2.2.3. Cantidad de itemsets en función del umbral de soporte .............................................. 94 6.2.2.4. Cantidad de itemsets en función del umbral de soporte temporal............................... 97

7. Conclusiones ................................................................................................................... 99 7.1. Trabajo futuro......................................................................................................... 100

Bibliografía ........................................................................................................................... 101

Apéndice A. Documentación de desarrollo.................................................................. 104 A.1. Requisitos del software .......................................................................................... 104

A.1.1. Casos de Uso ....................................................................................................... 104

A.2. Diseños de clases.................................................................................................... 107 A.2.1. Algoritmos para el descubrimiento de reglas de asociación espacio-temporales 108

A.2.1.1. Componente Espacial ............................................................................................... 112 A.2.1.2. Componente Temporal ............................................................................................. 114

A.2.2. Algoritmos de preprocesamiento......................................................................... 115 A.2.3. Paquetes involucrados ......................................................................................... 116

Apéndice B. Manual del Usuario.................................................................................. 118 B.1. Instalación .............................................................................................................. 118 B.2. Uso ......................................................................................................................... 118

B.2.1. Filtros para el preprocesamiento de los datos...................................................... 119 B.2.1.1. Conversión de las componentes de las posiciones geográficas ................................ 120 B.2.1.2. Discretización de los atributos continuos mediante clustering ................................. 122 B.2.1.3. Discretización de los atributos continuos propuesta por Weka ................................ 125 B.2.1.4. Conversión entre estructuras de datasets .................................................................. 126

B.2.2. Descubrimiento de las reglas de asociación espacio-temporales ........................ 128 B.2.3. Manejo de datos................................................................................................... 131


vi

B.2.3.1. Obtención de datos desde un archivo ....................................................................... 132 B.2.3.2. Obtención de datos desde una base de datos ............................................................ 132

B.3. Actualizaciones de Weka ....................................................................................... 133

Apéndice C. Código Fuente........................................................................................... 136 C.1. Paquete weka.associations.spatiotemporal............................................................. 136

C.2. Paquete weka.associations.spatiotemporal.predicates............................................ 192

C.3. Paquete weka.associations.spatiotemporal.temporal ............................................. 217 C.4. Paquete weka.filters.unsupervised.attribute ........................................................... 220

Apéndice D. Material Digital ........................................................................................ 242 D.1. Dataset de ejemplo ................................................................................................. 242


vii

Lista de figuras

Figura 3.1. Estructura de datos a manejar ................................................................................ 18 Figura 3.2. Verificación de un itemset en una transacción del modelo ................................... 20 Figura 3.3. Relación espacial de distancia simple - dist(X1,X2,d) ........................................... 22 Figura 3.4. Relación espacial de distancia y orientación - dist-or(X1,X2,d,α) ......................... 22 Figura 3.5. Relación espacial de distancia en dos dimensiones - distXY(X1,X2,d1,d2) ........... 22 Figura 3.6. Representación del problema de hallar un PredSY’ equivalente dado PredSY ...... 27 Figura 4.1. Estructura de datos a manejar utilizando atributos continuos................................ 48 Figura 6.1. Gráfico de resultados de la prueba de performance 1 sobre tiempo en función de la cantidad de timestamps ............................................................................................................ 89 Figura 6.2. Gráfico de resultados de la prueba de performance 2 sobre tiempo en función de la cantidad de timestamps ............................................................................................................ 89 Figura 6.3. Gráfico de resultados de la prueba de performance 3 sobre tiempo en función de la cantidad de timestamps ............................................................................................................ 89 Figura 6.4. Gráfico de resultados de la prueba de performance 1 sobre tiempo en función de la cantidad de sensores geográficos ............................................................................................. 92 Figura 6.5. Gráfico de resultados de la prueba de performance 2 sobre tiempo en función de la cantidad de sensores geográficos ............................................................................................. 93 Figura 6.6. Gráfico de resultados de prueba de performance sobre cantidad de itemsets frecuentes en función del umbral de soporte............................................................................ 96 Figura 6.7. Tiempo de descubrimiento de itemsets frecuentes en función del umbral de soporte, para resultados obtenidos en prueba de performance sobre cantidad de itemsets en función del umbral de soporte.................................................................................................. 96 Figura 6.8. Tiempo de ejecución en función de la cantidad de itemsets descubiertos, para resultados de prueba de performance sobre cantidad de itemsets en función del umbral de soporte ...................................................................................................................................... 96 Figura 6.9. Gráfico de resultados de prueba de performance sobre cantidad de itemsets frecuentes en función del umbral de soporte temporal ............................................................ 98 Figura 6.10. Cantidad de reglas obtenidas en función de la cantidad de itemsets frecuentes descubiertos, para prueba de performance sobre cantidad de itemsets frecuentes en función del umbral de soporte temporal...................................................................................................... 98 Figura A.1. Diagrama de casos de uso del software desarrollado.......................................... 104 Figura A.2. Diagrama de clases principales para el descubrimiento de las reglas de asociación espacio-temporales ................................................................................................................. 109 Figura A.3. Ejemplo de representación de un itemset espacio-temporal ............................... 110 Figura A.4 Diagrama de clases espaciales correspondientes al manejo de predicados ......... 113 Figura A.5 Diagrama de clases espaciales correspondientes al manejo de puntos ................ 114 Figura A.6. Diagrama UML de la clase TemporalHistogram................................................ 115 Figura A.7. Diagrama de clases correspondiente a los filtros................................................ 116 Figura A.8. Diagrama de paquetes para las clases desarrolladas ........................................... 117 Figura B.1. Pantalla correspondiente al Explorer de Weka ................................................... 119 Figura B.2. Pantalla mostrando un dataset cargado con las condiciones para aplicar el filtro de conversión de las componentes de las posiciones geográficas .............................................. 120 Figura B.3. Pantalla mostrando la ubicación del filtro DegressToDecimalFormat ............... 121 Figura B.4. Pantalla obtenida luego de aplicar el filtro de conversión de las componentes de las posiciones geográficas ...................................................................................................... 122


viii

Figura B.5. Pantalla mostrando un dataset cargado con las condiciones para aplicar el filtro de discretización de atributos mediante clustering ..................................................................... 123 Figura B.6. Pantalla de carga de los parámetros del filtro ClusterDiscretize......................... 124 Figura B.7. Pantalla obtenida luego de aplicar el filtro de discretización de atributos mediante clustering ................................................................................................................................ 125 Figura B.8. Pantalla obtenida luego de aplicar el filtro de discretización existente en Weka126 Figura B.9. Pantalla mostrando un dataset cargado con las condiciones para aplicar el filtro de conversión entre estructuras de datasets................................................................................. 127 Figura B.10. Pantalla obtenida luego de aplicar el filtro de conversión entre estructuras de datasets ................................................................................................................................... 128 Figura B.11. Pantalla mostrando la ubicación del algoritmo SpatioTemporalApriori........... 129 Figura B.12. Pantalla de carga de los parámetros del algoritmo SpatioTemporalApriori ..... 130 Figura B.13. Pantalla con el reporte de resultados obtenido mediante el algoritmo para el descubrimiento de las reglas de asociación espacio-temporales ............................................ 131 Figura B.14. Pantalla para obtención de datos en Weka mediante una base de datos ........... 133


ix

Lista de tablas

Tabla 5.1. Parámetros de uso del algoritmo para el descubrimiento de las reglas de asociación espacio-temporales ................................................................................................................... 53 Tabla 5.2. Parámetros de uso del filtro de discretización de atributos en base a un algoritmo de clustering .................................................................................................................................. 54 Tabla 5.3. Parámetros de uso para filtro de conversión de atributos de componentes de posiciones geográficas.............................................................................................................. 55 Tabla 5.4. Parámetros de uso para filtro de conversión entre estructuras de datasets ............. 57 Tabla 6.1. Conjuntos de discretización de los atributos del caso de ejemplo del dataset de transporte de gas....................................................................................................................... 59 Tabla 6.2. Parámetros de uso para el algoritmo implementado por SpatioTemporalApriori, en el caso de ejemplo del dataset de transporte de gas (sección 6.1.1.1)...................................... 60 Tabla 6.3. Intervalos de discretización de los atributos del caso de ejemplo alternativo del dataset de transporte de gas ...................................................................................................... 72 Tabla 6.4. Parámetros de uso para el algoritmo implementado por SpatioTemporalApriori, en el caso ejemplo alternativo del dataset de transporte de gas (sección 6.1.1.2) ........................ 73 Tabla 6.5. Parámetros utilizados en las pruebas de performance sobre tiempo en función de la cantidad de timestamps ............................................................................................................ 87 Tabla 6.6. Valores seleccionados para los datasets de las pruebas de performance sobre tiempo en función de la cantidad de timestamps...................................................................... 88 Tabla 6.7. Resultados de las pruebas de performance sobre tiempo en función de la cantidad de timestamps........................................................................................................................... 88 Tabla 6.8. Estaciones de medición seleccionadas para los datasets de las pruebas de performance sobre tiempo en función de la cantidad de sensores ........................................... 91 Tabla 6.9. Cantidad de intervalos de discretización seleccionados para los datasets de las pruebas de performance sobre tiempo en función de la cantidad de sensores ......................... 91 Tabla 6.10. Parámetros utilizados en las pruebas de performance sobre tiempo en función de la cantidad de sensores ............................................................................................................. 91 Tabla 6.11. Resultados obtenidos en las pruebas de performance sobre tiempo en función de la cantidad de sensores ............................................................................................................. 92 Tabla 6.12. Parámetros utilizados en la prueba de performance sobre cantidad de itemsets frecuentes en función del umbral de soporte............................................................................ 93 Tabla 6.13. Conjuntos de discretización de los atributos de la prueba de performance sobre cantidad de itemsets frecuentes en función del umbral de soporte .......................................... 94 Tabla 6.14. Resultados obtenidos en la prueba de performance sobre cantidad de itemsets frecuentes descubiertos en función del umbral de soporte....................................................... 95 Tabla 6.15. Parámetros utilizados en la prueba de performance sobre cantidad de itemsets frecuentes descubiertos en función del umbral de soporte temporal ....................................... 97 Tabla 6.16. Resultados obtenidos de la prueba de performance sobre cantidad de itemsets frecuentes descubiertos en función del umbral de soporte temporal ....................................... 97


1

1. Introducción

El proceso de descubrimiento de conocimiento en bases de datos abarca la extracción de información o conocimiento implícito, previamente desconocido y potencialmente útil desde bases de datos de gran volumen ([11]). Su aparición se debió principalmente a los avances en tecnologías para la recolección y almacenamiento de datos, frente a la necesidad de analizar esos grandes volúmenes de datos almacenados. Dentro de este proceso, se encuentra la aplicación de una o más tareas del área de la minería de datos. La misma contiene un conjunto de técnicas que permiten extraer los patrones de conocimiento novedosos desde bases de datos de gran volumen. Entre las tareas posibles de la minería de datos se destaca la de descubrimiento de reglas de asociación ([2]). La misma permite obtener patrones que muestran conjuntos de elementos que co-ocurren de manera frecuente en un conjunto de transacciones. Existen varios algoritmos desarrollados para el descubrimiento de las reglas de asociación, entre los cuales se pueden destacar [3] y [16]. La mayoría de estos algoritmos fueron desarrollados para trabajar con datos provenientes principalmente de bases de datos conformadas por transacciones conteniendo elementos cuyos tipos de datos eran simples: booleanos, categorías de valores o numéricos. Con el tiempo las tecnologías para recolección y almacenamiento de datos se han mejorado, permitiendo recolectar datos de diversas fuentes y de diferente naturaleza. Esto dio lugar a la aparición de áreas dentro de la minería de datos dedicadas a obtener patrones de conocimiento espacial ([1], [10]), temporal y espacio-temporal ([31]). De esta manera, para la tarea de reglas de asociación han aparecido también modelos para el descubrimiento de reglas de asociación espaciales y reglas de asociación temporales. Los modelos de reglas de asociación espaciales desarrollados, por ejemplo en [18], [33], [24] y [19], se han aplicado en general para el descubrimiento de reglas de asociación a partir de Sistemas de Información Geográfica (GIS). Los mismos son sistemas que permiten obtener, almacenar y administrar datos referenciados espacialmente a la tierra, junto con sus atributos asociados ([43]). La idea en estos trabajos es plantear un determinado tipo de transacción entre las capas -o los objetos espaciales de las mismas- del GIS y sobre las bases de datos armadas en base a estas transacciones aplicar técnicas similares a las convencionales para el descubrimiento de reglas de asociación. En cuanto a las reglas de asociación temporales, los modelos desarrollados se aplican sobre bases de datos conteniendo componentes temporales, pudiendo nombrar como ejemplos los modelos de [30], [29], [5] y [42]. En los mismos, mediante algoritmos propios de cada modelo, aplicados de manera completa o junto con los algoritmos convencionales para la obtención de las reglas, se obtienen reglas de asociación que muestran una componente temporal en base a parámetros definidos por el usuario o según las características de los datos en análisis. Por otro lado, existe el modelo de reglas de asociación inter-transacciones ([22], [23]), el cual permite obtener reglas de asociación en donde los elementos de las mismas se relacionan con los elementos de otras transacciones. La relación entre los elementos de distintas transacciones se realiza según determinados atributos denominados dimensionales, los cuales pueden incluir atributos del tipo espacial o temporal. Entre los algoritmos para la obtención de este tipo de reglas ([22], [23], [38]) se pueden nombrar un algoritmo básico en donde se extiende el algoritmo Apriori ([3]) para el procesamiento de las transacciones propias del modelo; y otro donde previo a la ejecución de un algoritmo para la obtención de los itemsets


2

convencionales, se aplican transformaciones a la base de datos y propiedades planteadas para descubrir los itemsets del modelo.

1.1. Contribución de la tesis

La contribución de esta tesis es el desarrollo de un modelo de reglas de asociación espacio-temporales. El mismo se aplica sobre bases de datos conteniendo componentes espaciales y temporales y permite obtener patrones de reglas de asociación que relacionan a los elementos de las transacciones, indicando además las características espaciales y temporales que ocurren entre los elementos de esa relación. Si bien se pueden encontrar otros modelos desarrollados (por ejemplo [25], [41]), los mismos tienen una aplicación muy específica o presentan un enfoque diferente al presente. En este trabajo, el modelo propuesto presenta las siguientes características: • El enfoque utilizado resulta de la integración de conceptos planteados en modelos

desarrollados previamente para la obtención de reglas de asociación espaciales y reglas de asociación temporales, de manera separada. También se integraron conceptos del modelo de reglas de asociación inter-transacciones, respecto al uso atributos espaciales y/o temporales

• Debido a lo anterior las reglas obtenidas presentan una semántica para expresar cada tipo de conocimiento, espacial y temporal, de una manera conveniente para el mismo.

• Se plantea un algoritmo particular para la obtención de las reglas que presentan la semántica dada.

• El modelo, por medio del algoritmo, permite descubrir todas las reglas posibles de los datos de entrada, en base a las características espaciales y temporales de estos datos, y sin imponer restricciones respecto a la complejidad computacional del algoritmo.

1.2. Objetivo de la tesis

El objetivo de esta tesis se encuentra compuesto por los siguientes puntos: • desarrollo de un modelo de reglas de asociación espacio-temporales. El mismo es

aplicable sobre bases de datos que presentan componentes espaciales y temporales en su estructura. Además, presenta las características enumeradas para el mismo en la contribución de esta tesis

• planteo de un algoritmo para la obtención de las reglas de asociación propuestas por el modelo. Análisis de algoritmos adicionales necesarios en el proceso de obtención del modelo

• implementación del algoritmo para obtener el modelo propuesto en base a conjuntos de datos existentes. Desarrollo de algoritmos adicionales.

• realización de pruebas sobre el algoritmo, utilizando la implementación desarrollada, que permitan analizar la performance y escalabilidad del algoritmo propuesto así como conseguir un panorama de los resultados posibles de obtener con el mismo

1.3. Organización de la tesis


3

El resto del trabajo se encuentra organizado de la siguiente manera: el capítulo 2 describe el panorama de trabajos relacionados con esta tesis, incluyendo los que aportan conceptos de base para el trabajo actual y los que proponen otros enfoques de trabajo. En el capítulo 3 se presenta el modelo de reglas de asociación espacio-temporales desarrollado, y en el 4 se exponen los algoritmos que permiten obtener las reglas de asociación del modelo. En el capítulo 5 se explican los detalles de la solución implementada en base a los algoritmos y modelo planteados. El capítulo 6 muestra los resultados de la experimentación realizada con la misma, analizando los resultados obtenidos en la aplicación sobre datasets reales, así como el comportamiento en las pruebas de performance. Finalmente, el capítulo 7 plantea las conclusiones obtenidas y el trabajo futuro. El trabajo cuenta con 4 apéndices. En el apéndice A se presenta la documentación correspondiente a la aplicación desarrollada, y en el B el manual del usuario de la misma. El código fuente de esta aplicación se muestra en el apéndice C. Por último, el apéndice D explica el contenido del material digital que acompaña a este trabajo.


4

2. Panorama de trabajo

El panorama de trabajo de esta tesis se puede dividir en los trabajos relacionados con el tema propuesto en la misma y los trabajos de base, que definen los conceptos que son utilizados o extendidos por los trabajos anteriores. Entre estos últimos se pueden incluir los que tratan el tema de descubrimiento de reglas de asociación, y las extensiones de los mismos a otros dominios: descubrimiento de reglas de asociación espaciales, descubrimiento de reglas de asociación temporales y descubrimiento de reglas de asociación inter-transacciones. En este capítulo se presentan los trabajos investigados de cada tipo, para permitir tener una base respecto a los conceptos manejados en esta tesis. Se finaliza el mismo con una comparación del presente trabajo con los trabajos relacionados sobre el tema.

2.1. Reglas de Asociación

La tarea de reglas de asociación ([2]) permite obtener patrones que tienen la representación de reglas y muestran conjuntos de elementos que co-ocurren de manera frecuente en un conjunto de transacciones. El modelo correspondiente a las mismas ([2], [3]) define un conjunto de items I={ i1, i2, i3, …

ik, … in }, conformado por atributos binarios, y un conjunto D, que representa la base de datos de transacciones sobre las cuales se descubrirán las reglas. Cada transacción Tr en D es un subconjunto de I, conteniendo los items que componen a la transacción. Asociado a cada transacción suele haber un identificador de la misma, TID. Se define un itemset X como un subconjunto de I. Una transacción Tr contiene un itemset X –también se suele señalar que Tr verifica el itemset X- si TrX ⊆ . Si X es un itemset con k elementos, se lo denomina k-itemset. El soporte de un k-itemset X se define como la cantidad de transacciones en D que verifican a X respecto al total de transacciones de D:

, donde VD(X), representa el conjunto de transacciones en D que contienen al itemset X: Un k-itemset X se denomina frecuente si su soporte supera el umbral de soporte, identificado como minsupport. Una regla de asociación es una expresión de la forma YX → , donde X e Y son k-itemsets. Se define la confianza de la regla como la proporción de transacciones en D que verifican X y también verifican Y: De la misma manera, el soporte de la regla se encuentra dado por el soporte del itemset unión de la misma:

D

XVXSup

D

D

)()( =

{ }{ }TrXDiiiTrXVkTrTrTrD ⊆∈== /,...,,)(

21

)(

)()(

XSup

YXSupYXConf

∪=→

)()( YXSupYXSup DD ∪=→


5

Para identificar las reglas a ser mostradas al usuario, se definen dos umbrales: un umbral de soporte, minsupport y otro de confianza, minconf. De esta manera la tarea de reglas de asociación se encarga de descubrir todas las reglas existentes en D que superan los umbrales de soporte y confianza, minsupport y minconf, dados por el usuario. Para realizar el descubrimiento de las reglas la tarea divide al problema que resuelve en dos:

1. Descubrimiento de todos los itemsets frecuentes en D, es decir, aquellos que superan el umbral de soporte minsupport

2. En base a los itemsets frecuentes descubiertos en la etapa anterior, armas las reglas de asociación y presentar al usuario solamente aquellas que superan el umbral de confianza minconf

De esta manera, los algoritmos desarrollados se enfocan sobre cada uno de estos subproblemas, encontrándose mayor cantidad de trabajos que presentan algoritmos para el descubrimiento de los itemsets frecuentes. Para el descubrimiento de los itemsets frecuentes, el algoritmo más difundido se denomina Apriori ([3]). El mismo realiza el descubrimiento de los itemsets en D mediante kmax pasadas sobre la base de datos, siendo kmax el tamaño máximo de k-itemset descubierto por el algoritmo. Además para el armado de candidatos, aplica una propiedad de los itemsets, denominada Propiedad de Monotonía. La misma expresa: “Cualquier subconjunto de un itemset frecuente debe ser frecuente.”

La misma se puede expresar también como: Sea X un itemset no frecuente D, entonces no existe un itemset Y, que contenga a X, y sea

frecuente en D.

El siguiente es el pseudocódigo del algoritmo ([3]). L1 = {large 1-itemsets};

for (k=2; Lk-1 ≠ ∅ ; k++) do begin Ck = apriori-gen(Lk-1); //New candidates

forall transactions Tr ∈ D do begin CTr = subset(Ck, Tr); //Candidates contained in Tr

forall candidates c ∈ CTr do c.count ++; end

Lk = { c ∈ Ck / c.count ≥ minsupport } end

Answer = Uk

kL ;

El descubrimiento de los itemsets se realiza por etapas. Se observa que cada etapa del algoritmo se puede dividir en: • generación de itemsets candidatos: los itemsets candidatos son los posibles itemsets

frecuentes de la etapa actual. Este paso se encuentra abarcado en la función apriori-gen. El armado de los mismos se realiza en base a los itemsets frecuentes de la etapa anterior, en dos pasos

o paso de junta: se arma cada nuevo itemset candidato en base a pares de itemsets frecuentes de la pasada anterior que contienen todos sus elementos, salvo el último, iguales. El nuevo candidato contiene los items comunes de ambos elementos junto a los nuevos.

o paso de poda: aplica la Propiedad de Monotonía del modelo para eliminar del conjunto de itemsets candidatos aquellos que no serán frecuentes. Para esto


6

verifica para cada uno de los candidatos armados si todos sus subconjuntos pertenecen al conjunto de itemsets frecuentes de la pasada anterior.

• contabilización de candidatos: para cada transacción en D, primero se aplica la función subset, que determina los itemsets candidatos contenidos en la transacción actual. Para la implementación de esta función [3] propone el uso de una estructura de hash-tree. En el mismo los itemsets candidatos se mantienen en nodos hojas; y a los mismos se llega en base a aplicar funciones de hash sobre los items de la transacción, dentro de los diferentes nodos de nivel superior del árbol. Otra alternativa propuesta en el mismo trabajo es el uso de un bitmap. En el mismo cada bit se corresponde a un item posible, y se inicializa en base a los valores de cada nueva transacción. Luego, a partir de los itemsets devueltos por subset se incrementa el contador de transacciones de cada uno de los mismos.

• determinación de candidatos frecuentes: se realiza verificando los contadores de cada candidato contabilizado contra umbral de soporte dado por el usuario.

Además del algoritmo Apriori, existen otros algoritmos desarrollados para el descubrimiento de itemsets frecuentes. Dentro de [3], también se presenta el algoritmo AprioriTid. El mismo aplica los principios de Apriori, pero utiliza una estructura auxiliar para la contabilización de los candidatos, en vez de recorrer en cada iteración la base de datos de transacciones D. Cada registro de esta estructura se compone del identificador de la transacción TID, y los itemsets candidatos contenidos en la misma. Otro algoritmo destacado es FP-growth ([16]). El mismo realiza el descubrimiento de patrones frecuentes armando una estructura de árbol, denominada FP-Tree, en base al dataset de transacciones D. Luego, el algoritmo realiza el descubrimiento de los itemsets frecuentes sobre esta estructura armada. Para el armado de la reglas la idea de los algoritmos es ir recorriendo cada itemset X e ir observando los subconjuntos del mismo. Para cada subconjunto a, se arma la regla

)( aXa −→ para determinar si su confianza supera el umbral de confianza, minconf, para ser

presentada al usuario. En [3] se presenta Faster Algorithm para el descubrimiento de las reglas, que realiza una mejora de esta idea básica. El mismo aplica una propiedad de las reglas, que se deriva de la Propiedad de Monotonía del modelo: “si la regla bbX →− )(

supera el umbral del confianza, entonces todas las reglas de la forma bbX ˆ)ˆ( →− deben

superarlo, para cada subconjunto b̂ de b”. De esta manera, el algoritmo arma las reglas para cada itemset frecuente por etapas, de acuerdo al tamaño del consecuente de las mismas. En cada etapa, los consecuentes de las nuevas reglas se arman en base los consecuentes de las reglas de la etapa anterior, aplicando la función apriori-gen del algoritmo Apriori. Así, se evitan armar reglas que no superarán el umbral de confianza. El siguiente es el pseudocódigo correspondiente al algoritmo ([3]). //Faster Algorithm

forall large k-itemsets lk, k ≥ 2 do begin H1= { consequents of rules derived from lk

with one item in the consequent}; call ap-genrules(lk, H1); end procedure ap-genrules(lk: large k-itemset, Hm: set of m-item consequents)

if (k > m + 1) then begin Hm+1 = apriori-gen(Hm);

forall hm+1 ∈ Hm+1 do begin conf = support(lk)/support(lk – hm+1);


7

if (conf ≥ minconf) then

output the rule (lk – hm+1) → hm+1 with confidence = conf and support = support(lk);

else delete hm+1 from Hm+1; end call ap-genrules(lk, Hm+1); end

El modelo original de reglas de asociación se aplica sobre bases de datos donde los atributos son de tipo binario. De esta manera, cada transacción señala la existencia o no de uno o más items. Para el descubrimiento de reglas donde se señale junto con cada item la cantidad del mismo, se debe utilizar el modelo de reglas de asociación cuantitativas ([34]). El mismo es una extensión del modelo convencional de reglas de asociación –también denominado modelo binario- para su uso con bases de datos conteniendo atributos continuos, o atributos con valores numéricos discretos cuyo dominio de valores sea demasiado amplio como para tomar cada valor como un item separado.

2.2. Extendiendo el dominio de las reglas de asociación

Con el avance en las tecnologías para la recolección y almacenamiento de datos han aparecidos trabajos dentro del área de la minería de datos orientados al descubrimiento de patrones espaciales, temporales y espacio-temporales. En [1] se realiza una reseña de los métodos existentes para el descubrimiento de patrones a partir de bases de datos espaciales. Entre las tareas nombradas se pueden destacar generalización espacial, clustering espacial, reglas de asociación espaciales, agregación espacial y reconocimiento de patrones espaciales. En [10] se presenta un framework para el descubrimiento de patrones desde base de datos espaciales, teniendo en cuenta las características de estas fuentes de datos. Luego se aplica el mismo para las tareas de clustering espacial, caracterización espacial –reglas que definen las características de determinados objetos de la base de datos espacial-, detección de tendencias espaciales y clasificación espacial. Se muestran ejemplos de aplicación junto con la presentación de las tareas mencionadas. Por último, en [31] se muestra un listado de trabajos relacionados con la minería de datos espacial, minería de datos temporal y minería de datos espacio-temporal. El mismo se encuentra divido en categorías: frameworks, minería de reglas de asociación espaciales o temporales, descubrimiento de patrones temporales, minería de series de tiempo, descubrimiento de reglas causales y/o temporales, minería de datos espacial, clustering espacial y clustering espacio-temporal, minería de datos espacio-temporal, y libros y tesis -material de alcance mas amplio-. Relacionados con estos trabajos se pueden hallar otros que tratan sobre el descubrimiento de reglas de asociación a partir de bases de datos espaciales y bases de datos temporales. En las secciones siguientes se explican los mismos.

2.2.1. Reglas de Asociación Espaciales

Uno de los primeros trabajos que trata sobre el descubrimiento de reglas de asociación espaciales es el presentado en [18]. El mismo plantea un algoritmo para el descubrimiento de


8

reglas de asociación a partir de Sistemas de Información Geográfica (GIS). La estructura de los GIS se encuentra compuesta por un conjunto de objetos espaciales de diferentes clases, y una base de datos relacional describiendo las características no espaciales de estos objetos. Las reglas planteadas muestran asociaciones entre predicados espaciales. Cada uno de estos predicados espaciales puede expresar una relación espacial, planteada entre una clase de objeto de referencia de la tarea y alguna de las demás clases de objetos relevantes a la misma. También pueden aparecer predicados que expresen las características no-espaciales de los objetos de la clase de referencia de la tarea. Para el descubrimiento de las reglas, el algoritmo propone el armado de transacciones para cada uno de los objetos de la clase de referencia de la tarea. Las mismas contendrán características no espaciales de los mismos y las relaciones espaciales con cada uno de los objetos de las otras clases relevantes de la tarea. En base a este conjunto de transacciones se aplican algoritmos para el descubrimiento de reglas de asociación convencionales. Debido a que el cálculo de una relación espacial de cada objeto de la clase de referencia de la tarea con los demás objetos de las clases relevantes de la misma tiene un alto costo computacional, se plantea realizar primero el cálculo de relaciones espaciales aproximadas, las cuales representan un valor bajo de este costo computacional. Con estas transacciones iniciales –definidas en base a las relaciones espaciales aproximadas- se realiza la contabilización del soporte, y las clases que no superan el umbral de soporte son eliminadas de este conjunto de transacciones. Luego, las relaciones espaciales de las transacciones son calculadas a un nivel mas preciso, y con las transacciones resultantes se realiza el descubrimiento de las reglas de asociación mediante algoritmos convencionales, como se comento arriba. En [33] este trabajo es extendido para el descubrimiento de reglas donde los predicados no espaciales se corresponden con cualquier objeto espacial, correspondiente a la clase de referencia o a las clases relevantes de la tarea. Para esto, agrega el uso de predicados de definición que permiten identificar, dentro de la regla, a una clase de objeto o capa temática del GIS. El algoritmo se basa en el armado de tablas, denominadas link tables, que relacionan los objetos de la clase o capa de referencia de la tarea con los objetos de una de las capas relevantes de la misma. En el trabajo [24] se extiende [18] con el uso de técnicas basadas en la teoría de lógica computacional. Los elementos de las reglas de asociación descubiertas son representados mediante átomos de Datalog, los cuales permiten expresar el conocimiento espacial de una manera más elegante. También se aplican técnicas particulares para el manejo de los átomos de Datalog dentro del algoritmo. En el trabajo [19] se plantea un modelo de reglas que relaciona a las diferentes capas geográficas del GIS. El esquema planteado se puede dividir en tres etapas:

1. los valores de cada una de las capas geográficas del GIS son agregados en base a áreas definidas en un mapa de áreas

2. estos valores agregados son discretizados en diferentes grupos 3. en base a las capas con los valores agregados y discretizados se realiza el

descubrimiento de las reglas de asociación La mayoría del trabajo trata sobre la conversión de los diferentes tipos de objetos de un GIS (puntos, líneas y áreas) en áreas. Para la discretización, el trabajo utiliza el esquema provisto por el GIS usado durante su desarrollo. El algoritmo para el descubrimiento de las reglas de asociación planteadas fue Apriori ([3]). En el mismo cada una de las capas del GIS en combinación con valores agregados de las mismas se corresponden con los items –cada uno de los pares (capa del GIS, valor agregado para la misma)-, y cada una de las áreas del mapa de áreas se corresponden con las transacciones.


9

2.2.2. Reglas de Asociación Temporales

Unos de los primeros trabajos que trata sobre el descubrimiento de reglas de asociación temporales es [28]. El mismo plantea un modelo y algoritmo para el descubrimiento de reglas de asociación cíclicas. El esquema de base de datos manejado por el modelo se compone de un conjunto de transacciones, del modelo convencional, asociadas cada una a un atributo temporal, que representa el instante de tiempo en que la transacción fue registrada. El problema del descubrimiento de reglas de asociación cíclicas es definido en el trabajo como “…la búsqueda de relaciones cíclicas entre la presencia de items dentro de transacciones.” ([28]). Cada ciclo asociado a una regla se representa con el instante de tiempo de inicio del mismo, y el periodo de ocurrencia, donde se verifica la regla asociada. El trabajo plantea dos algoritmos para el descubrimiento de este tipo de reglas. El primero, denominado Sequential, se divide en dos etapas: • En la primera se realiza el descubrimiento de reglas de asociación en cada unidad de

tiempo, utilizando los algoritmos convencionales. • Luego, se aplican algoritmo de búsqueda de patrones para el descubrimiento de ciclos

entre las reglas encontradas. Por otro lado se encuentra el algoritmo Interleaved, que utiliza tres técnicas planteadas (cycle-pruning, cycle-skipping y cycle-elimination) para podar los itemsets candidatos y ciclos asociados con los mismos a ser generados. El algoritmo Interleaved también se divide en dos etapas: • En la primera se realiza el descubrimiento de los itemsets frecuentes cíclicos

aplicando las técnicas planteadas para determinar ciclos potenciales, realizar los cálculos de soporte y eliminar los ciclos no frecuentes.

• Luego, en base a los itemsets frecuentes cíclicos descubiertos se generan las reglas de asociación cíclicas.

En [30] se extiende el trabajo anterior para el descubrimiento de patrones temporales en reglas de asociación. El trabajo define una algebra de calendarios para expresar los patrones temporales a ser descubiertos en las reglas de asociación. Cada patrón temporal, denominado calendar -o calendario-, se define como una colección de intervalos. Este algebra también define determinadas operaciones aplicables sobre los calendarios dentro de los algoritmos planteados. El descubrimiento de las reglas de asociación planteadas se define como “…el

descubrimiento de relaciones entre la presencia de items en las transacciones que siguen los

patrones definidos en los calendarios.” ([30]). De manera similar, el trabajo plantea dos algoritmos para el descubrimiento de este tipo de reglas, con los mismos nombres y estructuras planteadas en el trabajo anterior. Para el caso del algoritmo Interleaved, las técnicas aplicadas se corresponden con las del trabajo anterior aunque aplicadas sobre patrones calendario en vez de ciclos temporales. El trabajo [29] plantea un modelo de reglas de asociación temporales donde el conocimiento temporal se representa mediante predicados temporales. Las bases de datos que maneja el modelo se componen de atributos temporales. Los mismos son atributos asociados a puntos o intervalos temporales, que señalan el instante o periodo de tiempo de validez del item. Las reglas de asociación del modelo incluyen un conjunto de predicados temporales definidos entre los items que la conforman. Para cada uno de estos predicados se calcula la confianza del mismo como la proporción de transacciones que verifican los itemsets de la regla y también el predicado temporal definido. Los predicados temporales se manejan en una taxonomía de relaciones temporales, la que permite describirlos en diferentes niveles. Para el descubrimiento de las reglas, el algoritmo propuesto se divide en 4 etapas:


10

1. descubrimiento de las reglas de asociación: se realiza aplicando un algoritmo convencional

2. en base a las reglas descubiertas se generan para cada una todos los pares de atributos temporales existentes en la misma

3. para cada uno de los pares armados se determina si se verifica en cada transacción, y se registra que tipo de relación temporal dentro de la taxonomía de relaciones es la que se verifica

4. se arman las reglas en base a la contabilización de relaciones temporales realizada. Las relaciones temporales pueden ser reemplazadas por relaciones mas generales dentro de la taxonomía, en caso de que alguna no verifique el umbral de confianza definido para los predicados temporales.

En [4] y [5] se propone un modelo de reglas de asociación temporales basado en el concepto de lifespan, el cual representa el tiempo de vida de un itemset en la base de datos. Las reglas propuestas muestran los intervalos de validez en que se verifican las mismas. A diferencia del trabajo [30], estos intervalos son dados por el lifespan de los itemsets que representan la regla, de esta manera los mismos dependen solamente del dataset de entrada y no de parámetros dados por el usuario. La estructura de base de datos manejada es similar a la de [28], donde cada transacción, del modelo convencional, se encuentra asociada a un timestamp, que representa el tiempo de validez de la misma. Junto con el concepto de lifespan, el cálculo de soporte es modificado para ser calculado respecto a la cantidad de transacciones que ocurren en la base de datos dentro del intervalo de tiempo dado por el lifespan. De esta manera se permite descubrir itemsets que han aparecido en los últimos periodos de tiempo del dataset, por ejemplo, los cuales ocurren con suficiente frecuencia en este periodo, pero si se utilizara el cálculo de soporte convencional no hubiesen sido descubiertos por no encontrarse registrados desde el inicio del dataset. Además, se define un soporte temporal como la amplitud del lifespan del itemset. Los itemsets frecuentes serán aquellos que superen un umbral de soporte y otro de soporte temporal. De esta manera se evitan descubrir como frecuentes itemsets que fueron registrados en períodos de tiempo muy pequeños –por ejemplo 2 días dentro de un dataset de 5 años de extensión-. En [5] el trabajo se extiende con el concepto de lifespan frecuente. El mismo plantea que pueden existir itemsets que tampoco son frecuentes en toda la amplitud dada por su lifespan, pero si pueden serlo en subintervalos contenidos en el mismo. El lifespan frecuente es un conjunto de intervalos contenidos dentro del lifespan donde el itemset es frecuente -supera ambos umbrales de soporte- y son maximales respecto al soporte temporal –son los intervalos de máxima extensión que cumplen esta condición-. En cuanto al algoritmo para el descubrimiento de los itemsets frecuentes el trabajo plantea la modificación de algoritmos convencionales aplicando los conceptos planteados por el modelo: Apriori, en [4], y DIC, en [5]. Además en este último se presenta un algoritmo, denominado a-posteriori, para descubrir los intervalos del lifespan frecuente para el caso de los itemsets que no son frecuentes dentro de todo su lifespan. El mismo trabaja con histogramas temporales que fueron armados durante la ejecución del algoritmo para el descubrimiento de los itemsets frecuentes. Los mismos contabilizan la cantidad de transacciones que verifican el itemset en cada intervalo de discretización ∆t, unidad definida como parámetro por el usuario. Considerando estos histogramas temporales como series de tiempo, el trabajo también propone un esquema de representación de las mismas que permite el ahorro de la memoria utilizada y su caracterización temporal, de forma de poder comparar el comportamiento con el de otros itemsets. Por último, el trabajo [42] propone el descubrimiento de reglas temporales compuestas por evolutions –o evoluciones-. Cada evolución representa una modificación, aumento o disminución de los valores de un atributo dado; puede ocurrir en diferentes etapas, cuya


11

cantidad determina la longitud de la evolución. Además, en este caso las reglas descubiertas muestran una relación simétrica. Para este trabajo, el esquema de base de datos manejado se compone de una secuencia de snapshots que muestran los valores que toman los atributos de los objetos cada cierta frecuencia. Para la selección de las reglas a ser mostradas el trabajo define conceptos de soporte, densidad –para medir la representatividad de la región dada por una evolución en la regla- y strength –para medir el interés de la regla armada-. Respecto el descubrimiento de las reglas, el algoritmo propuesto se divide en dos etapas:

1. búsqueda de los clusters correspondientes a las evoluciones, en base al umbral de densidad

2. en base a los clusters identificados, descubrir las reglas válidas

2.2.3. Reglas de Asociación Inter-transacciones

Otro modelo de reglas de asociación a ser considerado es el de reglas de asociación inter-transacciones ([22], [23]). El mismo propone un modelo en donde los items que componen los itemsets y reglas de asociación se relacionan con los items existentes en otras transacciones. El esquema de base de datos con el que trabaja el modelo se compone de transacciones conteniendo un conjunto de items y uno o más atributos denominados dimensionales. Mediante los valores de estos atributos dimensionales se relacionan los items existentes en distintas transacciones. Los mismos describen propiedades asociadas a los items y pueden ser, entre otros, de tipo espacial –componentes de la posición geográfica, ciudad, etc.- o temporal –instante de tiempo, día de la semana, etc.-, de esta manera este modelo permite obtener reglas de asociación tipo espacial o temporal. El modelo define el concepto de ventana de desplazamiento como un conjunto continuo de intervalos dentro del dominio de los atributos dimensionales. Las relaciones entre los items del modelo se realizan dentro de las dimensiones de esta ventana. De esta manera, se evitan consumir recursos en el cálculo de relaciones en las que el usuario puede no estar interesado por extenderse entre un número muy grande de transacciones. En base a esto se define un item extendido como un item acompañado de la posición dada en el dominio de los atributos dimensionales. Además, un itemset extendido es un itemset compuesto de items extendidos, donde las posiciones de los mismos son relativas a la ventana de desplazamiento. La posición de referencia dentro de un itemset extendido será la posición con menor valor en sus componentes, entre las posiciones de los items extendidos que lo componen. En el trabajo [38] se formaliza el concepto de megatransacción contenida dentro de una ventana de desplazamiento como aquella transacción conformada por los items extendidos de las transacciones ubicadas dentro de la extensión de la ventana de desplazamiento, para una posición dada en el dominio de los atributos dimensionales. Respecto a los algoritmos para el descubrimiento de los itemsets inter-transacciones frecuentes, en [22] y [23] se presenta el algoritmo E-Apriori como una extensión del algoritmo Apriori ([3]) aplicando los conceptos del modelo. La idea del mismo es utilizar el esquema del algoritmo Apriori para el descubrimiento de itemsets extendidos a partir de un conjunto de megatransacciones. Estas últimas se van recorriendo mediante el traslado de la ventana de desplazamiento sobre las transacciones del dataset. También se presenta el algoritmo EH-Apriori, el cual utiliza tablas de hash para restringir el armado de los 2-itemsets candidatos y su posterior contabilización. Estas tablas de hash son armadas durante la pasada de descubrimiento de los 1-itemsets frecuentes. Luego, en [38] se presenta el algoritmo FITI (“First Intra Then Inter”) como una manera mas eficiente para descubrir los itemsets inter-transacciones. El mismo se divide en tres etapas:


12

1. descubrimiento de itemsets intra-transacciones frecuentes. Para este caso se aplican algoritmos convencionales para el descubrimiento de itemsets frecuentes. Los itemsets descubiertos se almacenan en una estructura denominada FILT (“Frequent-Itemsets Linked Table”), que mantiene distintos enlaces de relación entre los mismos.

2. transformación de la base de datos. En base a la estructura FILT del paso anterior se arman un conjunto de tablas denominadas FIT (“Frequent-Itemset Tables”). Se arma una tabla para cada conjunto de k-itemsets frecuentes descubiertos. Cada una de estas tablas mantiene información para cada valor de el/los atributo/s dimensional/es, correspondiente a una transacción, sobre los itemsets frecuentes contenidos en la mismas, relacionándolos con la tabla FILT.

3. minería de los itemsets inter-transacción frecuentes. Se realiza a partir de las tablas FIT armadas en el paso anterior, utilizando un esquema similar al del algoritmo Apriori. Utiliza una notación particular para los itemsets extendidos en base a los itemsets contenidos dentro de las posiciones del mismo. Para la creación de nuevos candidatos en base a los itemsets inter-transacción frecuentes de la pasada anterior, define dos operaciones de join (“Intratransaction Join” y “Cross-transaction Join”) propias de los itemsets manejados.

2.3. Trabajos relacionados

Los trabajos relacionados con lo desarrollado en esta tesis se pueden dividir en aquellos que tratan inicialmente sobre el descubrimiento de patrones espacio-temporales, aunque sin tener los mismos el formato de reglas de asociación de este tipo, y los que comienzan a plantear diversos enfoques para el descubrimiento patrones que se pueden identificar como reglas de asociación espacio-temporales. En esta sección se realiza una breve reseña de algunos trabajos de cada tipo, y se realiza una comparación del trabajo actual con los del segundo caso.

2.3.1. Primeros trabajos

Existen varios trabajos que tratan sobre la minería de patrones espacio-temporales del tipo de reglas. Los primeros desarrollos si bien descubrían patrones de este tipo, los mismos no correspondían a un modelo de reglas de asociación espacio-temporales. De este tipo de trabajos, se pueden destacar los tres siguientes. En [37] se plantea un algoritmo para la búsqueda de patrones espacio-temporales. En este caso se parte de valores registrados y distribuidos dentro de grillas en distintos puntos del espacio, teniendo una grilla para cada instante de tiempo. La tarea se trata de buscar patrones secuenciales en los valores registrados, donde cada secuencia se aplica sobre un espacio de las grillas. El algoritmo planteado utiliza para el descubrimiento de los patrones un enfoque de búsqueda de primero en profundidad (Depth-First-Search). En [36] también se extraen patrones de base datos distribuidos en grillas espacio-temporales. Los datos de análisis son del tipo climático y de las ciencias naturales. El trabajo presenta primero importancia en el procesamiento de los datos para eliminar componentes no necesarios en el análisis. Luego, el enfoque propone convertir los datos a estructuras del tipo de transacciones y aplicar sobre las mismas los algoritmos convencionales para la búsqueda de patrones. Los algoritmos aplicados son los correspondientes al descubrimiento de reglas de asociación y patrones secuenciales. Los mismos se aplican sobre una misma celda, para obtener los patrones convencionales, y entre diferentes celdas, para obtener patrones que


13

muestren una relación espacial. Para este último caso se relacionan distintas zonas del espacio asociando con cada item una región del espacio; esto se debe a que los items manejados son índices climáticos aplicados en regiones de interés para el análisis de los mismos. De esta manera, los patrones espacio-temporales descubiertos son, al igual que en el trabajo anterior, patrones secuenciales aplicados entre distintas regiones del espacio. En [17] y [21] se plantea un algoritmo para el descubrimiento de patrones a partir de datos espacio-temporales, con el objetivo de manejar riesgos de sequía. Los datos manejados son de tipo oceánicos, atmosféricos y climáticos. El enfoque en este trabajo esta en el descubrimiento de reglas de asociación, aunque para este caso los items de las mismas son episodios. Cada episodio se define como una secuencia de eventos. De esta manera las reglas descubiertas presentan una componente temporal. Los datos de origen son medidos en diferentes posiciones geográficas. A continuación, son procesados para obtener series de tiempo con los valores de diversos índices, climáticos y atmosféricos, correspondientes a las diferentes posiciones geográficas, siendo estos valores representados en los eventos de los episodios. Teniendo en cuenta esto, se podría considerar que las reglas representan también una componente espacial, ya que cada una se corresponde con la posición geográfica de los episodios que muestra. Aunque para este caso, las reglas no muestran información espacial propia de las posiciones geográficas desde donde fueron descubiertas. El algoritmo para la obtención de las reglas se basa en existentes para el descubrimiento de episodios frecuentes a partir de series de eventos. En [21], el trabajo se extiende utilizando métodos de interpolación para permitir el descubrimiento de reglas en ubicaciones donde no existan muestras registradas.

2.3.2. Otros enfoques de reglas de asociación espacio-temporales

Uno de los primeros trabajos que se puede considerar que trata sobre el descubrimiento de reglas de asociación espacio-temporales, que muestren ambos tipos de conocimiento, es [25]. El mismo maneja datos que fueron obtenidos de dos fuentes: datos censales y de áreas geográficas. Estos datos fueron procesados integrando ambas fuentes de datos, discretizando los valores medidos y definiendo jerarquías para los mismos que permitan obtener reglas multi-nivel. Además, los valores de las variables registradas se tomaron como la diferencia entre los correspondientes a los años 1970 y 1990, permitiendo registrar aumentos o disminuciones en este período de tiempo. De esta manera, se obtuvieron transacciones correspondientes a polígonos espaciales definidos en los datos, las que registraban como valores aumentos o disminuciones en el tiempo para las variables medidas, correspondientes a datos geográficos -de los polígonos- y no geográficos –censales-. Para obtener las reglas espacio-temporales en base a estas transacciones, se aplican algoritmos convencionales para el descubrimiento de reglas de asociación. En el caso del trabajo, se utilizo Apriori ([3]). Como desventaja, se puede señalar que el tema está tratado de manera particular para los conjuntos de datos de trabajo. En [15] y [14] se plantea un método para el descubrimiento de reglas de asociación espacio-temporales donde también se procesan los datos para obtener transacciones y luego sobre las mismas se aplican los algoritmos convencionales para el descubrimiento de las reglas de asociación. En este caso el método de conversión, denominado pivoting ([15]), es más genérico. El mismo consiste en la selección de dos atributos del dataset, por parte del usuario con conocimiento del dominio y la tarea, agrupar los registros en base a los valores del primer atributo, e ir asignando a cada uno de estos registros agrupados una lista de valores del segundo atributo. Según los atributos seleccionados en el mismo, permite obtener reglas del


14

tipo espacial, temporal, o espacio-temporal. Además, el trabajo muestra un enfoque mas abarcativo comenzando con un análisis de los diferentes tipos de reglas espacio-temporales posibles de ser descubiertas, y diferentes tipos de dataset espacio-temporales en base a los cuales descubrir las mismas. El trabajo [35] también propone aplicar un algoritmo para el descubrimiento de reglas en base a una estructura de transacciones definida. En este caso se manejan eventos geográficos, los cuales ocurren cuando determinados atributos toman determinados valores en una posición e instante de tiempo determinados. Los valores también se discretizan, y se arman transacciones identificadas por el instante de tiempo. Los atributos registrados pueden corresponder al instante de tiempo, o a determinadas áreas o posiciones geográficas dentro del mismo. Esta estructura es denominada tabla de decisión, debido a que el trabajo diferencia los atributos de la misma en atributos de condición y atributos de decisión. Los atributos de condición formarán parte del antecedente de las reglas a descubrir, y los de decisión de su consecuente. Para el descubrimiento de las reglas, el algoritmo propuesto aplica primero conceptos de la teoría de rough set para determinar que atributos de condición determinan los atributos de decisión. Luego, el algoritmo continúa con el descubrimiento de itemsets de mayor tamaño de manera similar a los algoritmos convencionales para el descubrimiento de reglas. El trabajo es aplicado para hallar patrones de comportamiento en los geo-eventos, aportados por datos de la industria pesquera de China. Un detalle a señalar en el trabajo es el ciclo de descubrimiento de reglas planteado. El mismo tiene una estructura retroalimentada y permite refinar el conocimiento aportado por las reglas en base a conocimiento previo, el cual puede provenir de conocimientos del dataset o de las reglas descubiertas anteriormente. Si bien el trabajo plantea un modelo, el mismo tiene una extensión reducida; ya que solamente se presenta la definición de las reglas a ser descubiertas y los itemsets que las componen, sin ningún concepto adicional propio del modelo. El trabajo [41] en cambio plantea, de manera completa, un modelo para el descubrimiento de reglas de asociación espacio-temporales a partir de bases de datos de objetos móviles (OMDB). Las reglas de asociación de este modelo tratan de representar movimientos de objetos entre regiones entre dos intervalos de tiempo. El modelo planteado define conceptos propios, como por ejemplo cobertura espacial y temporal, soporte espacial y temporal. Además clasifica diferentes tipos de regiones en base los conceptos del modelo. Luego, para el descubrimiento de las reglas plantea un algoritmo en donde se va realizando por etapas el descubrimiento de los diferentes tipos de regiones anteriormente planteadas, hasta obtener las reglas del modelo en base a una combinación de determinadas regiones anteriormente descubiertas. Esto se debe a que en realidad estos tipos de regiones anteriormente identificadas son casos particulares de las reglas de asociación planteadas por el modelo. Este algoritmo planteado mejora notablemente los tiempos de ejecución frente a un algoritmo básico -de tipo “fuerza bruta”- de descubrimiento de reglas que realice la combinatoria de todas las regiones posibles a partir de la base de datos. Por último, [20] también plantea un modelo para el descubrimiento de reglas de asociación espacio-temporales. Las reglas planteadas tratan de representar los diferentes lugares e intervalos de tiempo donde ocurren los items de las mismas, mediante el uso de patrones denominados calendario-mapa. Los mismos son tuplas donde sus elementos representan el valor de un atributo temporal o espacial a diferentes granularidades, o un ‘*’ para expresar cualquier valor posible para el atributo particular. Los tipos de patrones a ser descubiertos por las reglas los determina el usuario mediante un esquema relacional de calendario-mapa, donde se definen los correspondientes atributos temporales y espaciales. El modelo también define conceptos propios, los que se usaran posteriormente en el algoritmo planteado. Para este último, se plantean dos versiones. El primero es una extensión del algoritmo Apriori ([3])


15

aplicando los conceptos planteados en el modelo. El segundo es un algoritmo que trata de mejorar al anterior respecto a la cantidad de pasadas a la base de datos y el uso de memoria, ya que en este trabajo se deben almacenar una mayor cantidad de itemsets frecuentes posibles para las diferentes combinaciones de ubicación y tiempo existente en la base de datos a diferentes granularidades. El mismo genera los candidatos en dos etapas: primero los de tamaño 2 y luego los demás, aplicando propiedades del modelo que permiten restringir la cantidad de candidatos. De esta manera, el algoritmo realiza solamente dos pasadas de contabilización sobre la base de datos.

2.3.3. Comparación con el trabajo propuesto en esta tesis

Se puede realizar una comparación del trabajo propuesto en esta tesis con los señalados anteriormente para el descubrimiento de reglas de asociación espacio-temporales. El trabajo propuesto en esta tesis plantea un modelo de reglas de asociación espacio-temporales a ser descubiertas. Esto lo diferencia de los trabajos de [25] y [15], que plantean esquemas para la conversión de datasets –en un caso de manera particular y en el otro más general-, y en base a los datos transformados aplicar algoritmos convencionales para el descubrimiento de reglas de asociación. Para el caso de [35], si bien se plantea un modelo, el mismo presenta una extensión reducida. Esto se debe, como se explicó en la sección anterior, a que se definen las reglas e itemsets a ser descubiertos, pero no otros conceptos relacionados a los mismos. En cuanto al modelo planteado en esta tesis, el mismo se aplica sobre bases de datos conteniendo transacciones con componentes espaciales y temporales. Esto lo diferencia del trabajo [41], el cual desarrolla un modelo para ser aplicado sobre bases de datos de objetos móviles. Otra característica del modelo propuesto es que su enfoque para representar el conocimiento, espacial y temporal, de las reglas resulta de la integración de conceptos planteados en modelos desarrollados previamente para el descubrimiento de reglas de asociación espaciales, reglas de asociación temporales y reglas de asociación inter-transacciones, de manera separada. En cambio, los otros trabajos sobre reglas de asociación espacio-temporales no muestran esta característica. En el trabajo [35], el conocimiento espacio-temporal de las reglas propuestas se encuentra dado por el atributo temporal utilizado en la tabla de decisión, y las características espaciales que pueden presentar los diferentes atributos de condición seleccionados para la misma. Además los datos se deben corresponder con regiones espaciales seleccionadas previamente, para poder realizar el procesamiento necesario de los atributos básicos. Por otro lado, el conocimiento aportado por las reglas del modelo [20], respecto a la parte temporal, tiene una semejanza con los modelos de [30] y [28]. Esto se debe a que el conocimiento aportado por las mismas representa intervalos temporales y espaciales de validez en base a un esquema seleccionado. Asimismo, al utilizarse comodines –el carácter ‘*’- en los patrones de calendario-mapa, se puede obtener información sobre ciclos temporales, aunque los mismos no se representan de una manera genérica como la propuesta en [28], como se comentó anteriormente en 2.2.2. Por otro lado, el modelo de [20] se diferencia de estos dos modelos temporales representando el conocimiento en múltiples granularidades, mediante el uso de diferentes atributos temporales y espaciales; y planteando el problema de descubrimiento de las reglas del modelo como la obtención de todas las que cumplen con el esquema de relación de calendario-mapa definido por el usuario. Esto último lo diferencia de [30], donde el problema plantea la obtención de las reglas según los intervalos de tiempo definidos en los patrones de calendario.


16

Por último, respecto a la estructura de datos que plantea el modelo, se puede señalar que la misma presenta algunas semejanzas con las manejadas por algunos trabajos anteriores. La estructura de datos básicos aportados por el usuario es semejante a la del trabajo de [20]. En el caso de [35], se comparte una estructura similar con el dataset del modelo propuesto en esta tesis, ya que en ambos casos se manejan transacciones agrupadas por la componente temporal. Para el trabajo [15], el mecanismo de pivoting propuesto para la conversión de datasets puede presentar similaridad con el algoritmo de conversión entre datasets planteado en esta tesis, para el caso en que el primero se aplica con datos temporales como primer atributo de pivoting. Este caso es ejemplificado en el trabajo [15] con el dataset denominado “DMI”.


17

3. Modelo

En este capitulo se describen los conceptos del modelo de reglas de asociación espacio-temporales propuesto en esta tesis. Se comienza explicando los itemsets del mismo, su verificación en transacciones y el cálculo de soporte manejado. Luego, en base a la descripción de los itemsets, se presentan las reglas de asociación espacio-temporales manejadas por el modelo. Por último, se realiza la prueba de la Propiedad de Monotonía para los itemsets presentados, que permite definir en el siguiente capítulo el tipo de algoritmo a partir del cual descubrir estos itemsets. Previo a la explicación de los conceptos del modelo se señala la estructura de los datos a partir de la cual se obtiene el modelo tratado.

3.1. Estructura de datos

El modelo trabaja con bases de datos que contienen elementos espaciales y temporales, planteando un esquema general para la estructura de las mismas. Si bien la estructura de datos manejada puede variar según el área donde se aplique, se puede plantear una estructura de datos común. La misma es posible de ser obtenida en diferentes áreas de aplicación, ya sea de manera directa o mediante conversiones menores. Esta estructura de datos tiene los siguientes elementos identificados: • sensor: representa la fuente de medición. Suele mantener dos datos asociados al mismo

o id sensor: identificación del sensor o posición: ubica espacialmente a las mediciones realizadas por el sensor dentro

de las dimensiones de un plano o un mapa. Puede ser representada, por ejemplo, mediante un punto en el plano o coordenadas geográficas.

• t: instante de tiempo en que fueron realizadas las mediciones por el sensor • mediciones: items registrados por el sensor en el instante de tiempo t

La figura 3.1 muestra una representación de esta estructura de datos. Se observa en la estructura señalada que los registros se distribuyen por sensor e instante de tiempo de las mediciones, identificando ambos elementos a un registro. Debido a las características propias del modelo planteado, en la estructura de datos manejada por el mismo las transacciones se van a agrupar por instante de tiempo, conteniendo cada una los items registrados por todos los sensores en este instante de tiempo. Tampoco es necesaria la existencia de un identificador de los sensores de medición. De esta manera, el modelo maneja una estructura de datos donde el elemento temporal se representa mediante un timestamp señalando el tiempo en que se registra la transacción. El espacial son las posiciones geográficas –representadas mediante una posición en el plano, coordenadas en grados u otro esquema similar- asociadas a cada item en la transacción, indicando donde se registraron los mismos. Representando ambos elementos en conjunto queda: Sea I={ i1, i2, i3, … ik, … in } un conjunto de items, se define a la base de datos D como un

conjunto de duplas, denominadas transacciones, de la forma

( ){ }jjki yxit ,,,


18

donde ti será el timestamp en el que se registra la transacción, y (xj, yj) la posición geográfica

asociada a cada item en la misma e indicando la ubicación espacial donde se registro el item

ik dentro del timestamp ti.

3.2. Itemset y conceptos relacionados

En el modelo de reglas de asociación ([2]) un itemset es un conjunto de items pertenecientes a I – el conjunto de items del modelo-, como se menciono en el capítulo anterior. En el modelo propuesto en este trabajo cada itemset se encuentra asociado a una componente espacial y otra temporal. La componente espacial se basa en el modelo de reglas de asociación intertransacciones ([22], [23]), mencionado en el capítulo anterior, para el caso en que se consideran como atributos dimensionales los 2 componentes de las posiciones geográficas. Además, en este modelo indicado, las transacciones se agrupan por cada posición geográfica. De esta manera, permite relacionar un item con los demás en otras transacciones, del tipo mencionado, a través de los componentes de las posiciones geográficas. Así, en cada itemset extendido ([23]) los items se relacionan con respecto a la posición de un item base, la cual corresponde a la posición de referencia del itemset. En el modelo propuesto se aplica esta idea salvo que se utiliza un conjunto de predicados espaciales definidos entre dos posiciones geográficas, identificado como PredS, para señalar las relaciones espaciales entre los items del conjunto. Esto permite relacionar items ubicados en cualquier posición geográfica de la base de datos y no solamente los cercanos, limite dado por la ventana de desplazamiento ([23]). Además, para permitir esta relación geográfica entre los items de todas las posiciones geográficas existentes en la base de datos, se adopta la estructura de transacciones agrupadas por timestamp, comentada anteriormente. Mediante variables de posición, agregadas entre paréntesis al lado de cada item y nomencladas como POSi, se permite identificar para cada predicado espacial a que par de posiciones geográficas de cada item del conjunto se aplica el

Figura 3.1. Estructura de datos a manejar


19

mismo. La componente temporal se basa en el modelo de reglas de asociación temporales generalizadas de [4] y [5]. De esta manera, está compuesta del lifespan o tiempo de vida del itemset, identificado como l. El mismo representa el período en el cual el itemset se verifica en la base de datos ([5]). Sea X un k-itemset de la forma ( ) ( ) ( ){ }kk POSiPOSiPOSiX ,..., 2211= , P un conjunto de

predicados espaciales definidos entre dos variables { }ppredpredpredP ,..., 21= e I={ i1, i2, i3,

… ik, … in } un conjunto de items definidos sobre una base de datos ( ){ }{ }jjki yxitD ,,,= .

PredS para X vale:

Si k = 1:

∅=XedSPr

Si k > 1:

{ }),(),...,(),,(Pr 1313212 kjkjjX POSPOSpredPOSPOSpredPOSPOSprededS =

El lifespan de X es:

[ ]21,ttlx = , donde

{ }{ }),(),(,,,/1 XTrverificayxitTrDTrtmínt jjk ∧=∈=

{ }{ }),(),(,,,/2 XTrverificayxitTrDTrtmáxt jjk ∧=∈=

De la definición de PredS dada se observa que los predicados tienen como primera posición geográfica POS1. El item asociado a la misma se lo denomina dentro del modelo como “item principal”, y el mismo corresponde al item dentro del conjunto items respecto del cual se relacionan los demás. En la definición de lifespan anterior, se hablo del concepto de un itemset verificado en una transacción de la base de datos. Para el modelo actual el mismo implica además de la aparición de los items del itemset contenidos dentro de la transacción, como se mencionó en el modelo de reglas de asociación convencional ([2]), la verificación entre las posiciones geográficas de los items de la misma de los predicados espaciales definidos dentro de la componente PredS del itemset. Este concepto se representa en la figura 3.2.

Sea X un k-itemset, ( ) ( ) ( ){ }kk POSiPOSiPOSiX ,..., 2211= y una transacción { }),(,, jjk yxitTr =

perteneciente a D, se indica que Tr verifica X (señalándolo con verifica(Tr,X)) si:

Para el caso de ser { }1iX= un 1-itemset:

De esta manera se puede identificar a VD(X, [t,t’]) como el conjunto de transacciones dentro del intervalo de tiempo [t,t’] que verifican X ([5]):

En este caso se aplica también la definición de “verifica” dada por el modelo, que considera la componente espacial del itemset. Considerando lo anterior, las métricas del modelo se definen de igual manera a [5].

( )( ))),(),,((,:1,: ''''1 kkkkjllkklkk yxyxprediiTrilXiiiTri ∧=∈∃>∈∀∧=∈∃

( )1:),( iiTriXTrverifica kk =∈∃=

{ }{ }),(]',[/),(,,])',[,( XTrverificatttDyxitTrttXV jjkD ∧∈∈==


20

Sea X un k-itemset, ( ) ( ) ( ){ }kk POSiPOSiPOSiX ,..., 2211= , P un conjunto de predicados

espaciales definidos entre dos variables { }ppredpredpredP ,..., 21= e I={ i1, i2, i3, … ik, … in

} un conjunto de items definidos sobre una base de datos D.

Se define el soporte de X dentro del intervalo de tiempo [t,t’] como la proporción de

transacciones dentro del mismo que verifican X:

donde D[t,t’] es el conjunto compuesto por todas las transacciones de D que ocurren dentro

del intervalo de tiempo [t,t’] y |D[t,t’] | representa la cardinalidad del mismo:

Se define el soporte temporal de un itemset X dentro del intervalo de tiempo [t,t’] como la

amplitud de este último:

|[t,t’]|.

Se destaca que si bien el concepto de soporte se define de igual manera que en [5], el mismo incluye, dentro de su definición VD(X, [t,t’]), el concepto de verificación de un itemset dentro de una transacción, el cual considera la componente espacial del itemset, como se mencionó arriba. Para devolver al usuario solamente aquellas reglas de asociación que sean representativas en el conjunto de datos, se definen dos parámetros a dar por el mismo: un mínimo valor para el soporte de un itemset, σ (denominado minsupport en [2]), y un mínimo para su soporte temporal, τ ([5]). En base a los mismos se identificarán los itemsets frecuentes. Pueden existir itemsets que no sean frecuentes dentro de todo su lifespan sino dentro de subintervalos contenidos dentro de estos últimos. Para estos casos se utiliza el concepto de lifespan frecuente de un itemset, definido como el conjunto de subintervalos dentro de su lifespan donde el itemset es frecuente ([5]). Del mismo no se consideran todos los subintervalos donde se superen los umbrales de soporte (σ y τ), sino aquellos que superen el umbral del soporte y soporte temporal y sean maximales respecto a este último.

Figura 3.2. Verificación de un itemset en una transacción del modelo

{ }{ }]',[/),(,,]',[ tttDyxitTrD jjktt ∈∈==

]',[

])',[,(])',[,(

tt

D

D

ttXVttXSup =


21

Para estos itemsets el lifespan frecuente pasa a ser su componente temporal, representada por fl:

Teniendo en cuenta lo anterior se puede definir cuando un itemset resulta frecuente en su lifespan de manera similar a [5]: Sea X un k-itemset ( ) ( ) ( ){ }kk POSiPOSiPOSiX ,..., 2211= , P un conjunto de predicados

espaciales definidos entre dos variables { }ppredpredpredP ,..., 21= e I={ i1, i2, i3, … ik, … in

} un conjunto de items definidos sobre una base de datos D

X es frecuente en lX si: existe un intervalo [t,t’] ⊆ lx donde Sup(X,[t,t’]) ≥ σ,

|[t,t’]| ≥ τ, y

[t,t’] es maximal en lx

Para concluir se puede dar una definición resumida de un itemset espacio-temporal del modelo.

Sea una base de datos D con transacciones de la forma ( ){ }{ }jjki yxit ,,, , I={ i1, i2, i3, … ik,

… in } un conjunto de items definidos sobre la misma, y P un conjunto de predicados

espaciales definidos entre dos variables { }ppredpredpredP ,..., 21=

Un itemset X es un conjunto de items pertenecientes a I, de la forma

( ) ( ) ( ){ }kk POSiPOSiPOSiX ,..., 2211= , y asociado a dos componentes:

• espacial: determinada por PredS. Relacionará a los elementos de X mediante

relaciones espaciales definidas por predicados pertenecientes a P.

• temporal: serán un conjunto de intervalos de tiempo dentro de los cuales X es

frecuente, denominados en general “intervalos frecuentes”. Lo determina el lifespan

frecuente (fl). En el caso extremo, fl puede contener un solo intervalo y que este sea el

lifespan (l) del itemset X.

3.2.1. Predicados Espaciales

Cada itemset del modelo se encuentra asociado a un PredS. El mismo permite señalar las relaciones espaciales entre los items del itemset; y se encuentra conformado por un conjunto de predicados espaciales definidos entre dos posiciones geográficas. Cada uno de estos predicados espaciales representa una relación espacial que ocurre entre dos posiciones geográficas; siendo estas últimas los parámetros de los predicados espaciales. La elección de una relación espacial determinada permite obtener diversos conocimientos de un dataset. Entre los tipos de relaciones espaciales existentes se puede diferenciar las relaciones de una dimensión y las de dos dimensiones. Los siguientes son ejemplos de estas relaciones espaciales. 1 dimensión

• distancia simple: representa solamente la distancia entre dos posiciones. La figura 3.3

muestra la representación gráfica de la misma, la cual se puede identificar como dist(X1,X2,d).

( )( ){ }σστ ≥∧⊂¬∃∧≥∧≥⊆= ])',[,sup(]',[]',[:]',[])',[,sup(]',[/]',[ 222222 ttXttttttttXttlttfl XX


22

2 dimensiones

• distancia y orientación: representa la distancia entre los dos posiciones más el ángulo

de orientación respecto a la horizontal del segmento formado entre la primera y segunda posición (en sentido antihorario). La figura 3.4 muestra la representación gráfica de la misma, la cual se puede identificar como dist-or(X1,X2,d,α)

• distancia en dos dimensiones: representa la distancia paralela a los ejes -horizontal y

vertical, por ejemplo- de la segunda posición respecto a la primera. La figura 3.5 muestra la representación gráfica de la misma, la cual se puede identificar como distXY(X1,X2,d1,d2)

X1

X2

d

Figura 3.3. Relación espacial de

distancia simple - dist(X1,X2,d)

X1

X2

d

αααα

Figura 3.4. Relación espacial de distancia y

orientación - dist-or(X1,X2,d,α)

X1

X2

d1

d2

Figura 3.5. Relación espacial de distancia en dos

dimensiones - distXY(X1,X2,d1,d2)


23

La componente espacial PredS fue definida para contener la cantidad mínima de predicados que describa las relaciones espaciales entre todos los items de un itemset. Las relaciones espaciales entre dos posiciones del itemset que no se encuentran definidas explícitamente en PredS pueden determinarse en base a la relación espacial de ambas posiciones respecto a la posición del item principal del itemset. Por este motivo, no deberían usarse aquellos predicados que representen relaciones espaciales de una dimensión, debido a que las mismas no representan una relación univoca entre los dos puntos sobre la cual se definen. De esta manera, si se relacionara una posición con dos posiciones distintas mediante relaciones espaciales de una dimensión no se podría determinar la relación espacial posible entre estas dos posiciones. Por lo tanto, para este caso PredS no describiría las relaciones espaciales existentes entre todos los items del itemset. Se puede generalizar lo anterior para el manejo de cualquier cantidad de dimensiones espaciales existentes en los datos. Para estos casos se debe considerar que el número de dimensiones de trabajo, existentes en los datos a procesar, sea siempre igual al número de parámetros manejados en las relaciones espaciales correspondientes a los predicados a utilizar en el modelo. En las relaciones espaciales definidas los elementos en verde señalan los parámetros que definen la relación espacial. De esta manera, puede llegar a existir un predicado por cada par de parámetros existentes; pero al ser los mismos continuos, la cantidad de predicados espaciales posibles terminaría siendo infinita. Como el conjunto de predicados P es finito, se debe discretizar los parámetros de las relaciones espaciales para definir una cantidad finita de las mismas, que pueda ser manejable computacionalmente y a la vez permita realizar el descubrimiento de items, con sus respectivos predicados, que tengan el soporte suficiente. Por ejemplo, para el caso de elegir la relación de “distancia y orientación”, se deben discretizar en intervalos las posibles distancias entre dos posiciones y el ángulo de orientación respecto a la horizontal del segmento conformado por las mismas. Si bien esta discretización de las relaciones espaciales ya no definiría de forma univoca la relación entre dos puntos, la misma permite restringir los conjuntos de puntos sobre los cuales es válida una relación, en mayor medida que si se considerara la discretización de una relación espacial de una dimensión.

3.3. Reglas de asociación espacio-temporales

Una regla de asociación espacio-temporal va a estar compuesta por dos itemsets, mostrando las componentes espacial y temporal de los mismos como el conocimiento espacio-temporal aportado por la regla. A continuación se da una definición inicial de la misma. Sea I={ i1, i2, i3, … ik, … in } un conjunto de items definidos sobre una base de datos D, una

regla de asociación espacio-temporal esta representada por la expresión:

];[Pr: YXYX fledSYX ∪∪→

donde

X, Y: itemsets de la forma ( ) ( ) ( ){ }kk POSiPOSiPOSiX ,..., 2211= ,

( ) ( ) ( ){ }llkkkk POSiPOSiPOSiY ,..., 2211 ++++=

cada predp ∈ { }ppredpredpredP ,..., 21= , que es el conjunto de predicados espaciales

definidos entre dos variables

{ ),,(),...,(),,(Pr 1313212 kkjjYX POSPOSpredjPOSPOSpredPOSPOSprededS =∪

}),(),...,(, 111)1( ljlkkj POSPOSpredPOSPOSpred ++


24

{ ∧≥∪∧≥⊆= ∪∪ στ ])',[,sup(]',[/]',[ ttYXttlttfl YXYX

Para poder presentar al usuario las reglas con suficiente representatividad e implicancia, se definen las medidas de interés de la misma de manera similar a [5]. Sea I={ i1, i2, i3, … ik, … in } un conjunto de items definidos sobre una base de datos D, dos

k-itemset, ( ) ( ) ( ){ }kk POSiPOSiPOSiX ,..., 2211= e ( ) ( ) ( ){ }llkkkk POSiPOSiPOSiY ,..., 2211 ++++= , y

una regla de asociación espacio-temporal definida entre los mismos

];[Pr: YXYX fledSYX ∪∪→ .

Se define el soporte de la regla X →→→→ Y en su flX∪∪∪∪Y como el soporte del itemset conformado

por la unión de los itemsets que forman la regla dentro de cada intervalo de YXfl ∪ :

{ }YXYX flttttYXSupflYXSup ∪∪ ∈∪=→ ]',/[])',[,(),(

Se define la confianza de la regla X →→→→ Y dentro del intervalo de tiempo [t,t’] como la

proporción de transacciones dentro del intervalo de tiempo [t,t’] que verifican X y también

verifican Y:

])',[,(

])',[,(])',[,(

ttXSup

ttYXSupttYXConf

∪=→

Se define la confianza de la regla X →→→→ Y en su flX∪∪∪∪Y como la confianza de la misma dentro

de cada intervalo de YXfl ∪ :

{ }YXYX flttttYXConfflYXConf ∪∪ ∈→=→ ]',/[])',[,(),(

Para ambas medidas existen umbrales mínimos a definir por el usuario: un mínimo valor para el soporte de la regla, σ, y un mínimo valor para su confianza, θ. De esta manera, se van a proporcionar al usuario aquellas reglas donde exista al menos un intervalo [t,t’] ∈ flx∪y en el cual Sup(X ∪ Y,[t,t’]) ≥ σ y Conf(X → Y,[t,t’]) ≥ θ, presentándose al usuario solamente estos intervalos donde se superen ambos umbrales a la vez -contenidos dentro de la componente temporal de la regla-. Considerando lo señalado se puede expresar de manera completa la definición de las reglas, junto con su interpretación. Sea I={ i1, i2, i3, … ik, … in } un conjunto de items definidos sobre una base de datos D y P un

conjunto de predicados espaciales definidos entre dos variables { }ppredpredpredP ,..., 21= ,

se define una regla de asociación espacio-temporal como la expresión:

];[Pr: YXYX lfedSYX ∪∪′→ : [{s1, s2, …, sm}; {c1, c2, …,cm}]

donde

X, Y: itemsets de la forma ( ) ( ) ( ){ }kk POSiPOSiPOSiX ,..., 2211= ,

( ) ( ) ( ){ }llkkkk POSiPOSiPOSiY ,..., 2211 ++++=

con

{ ∧≥∪∧≥⊆= ∪∪ στ ])',[,sup(]',[/]',[ ttYXttlttfl YXYX

( )( )}σ≥∪∧⊂¬∃ ])',[,sup(]',[]',[:]',[ 222222 ttYXtttttt

{ ),,(),...,(),,(Pr 1313212 kkjjYX POSPOSpredjPOSPOSpredPOSPOSprededS =∪

}),(),...,(, 111)1( ljlkkj POSPOSpredPOSPOSpred ++

( )( )}σ≥∪∧⊂¬∃ ])',[,sup(]',[]',[:]',[ 222222 ttYXtttttt

{ }θσ ≥→∧≥∪∈=′∪∪ ])',[,(conf])',[,sup(/]',[ ttYXttYXflttlf YXYX


25

{s1, s2, …, sm }: valores de soporte superando el umbral σ dentro de los intervalos de

fl’x∪y

{c1, c2, …,cm}: valores de confianza superando el umbral θ dentro de los intervalos de

fl’x∪y

La misma se puede interpretar como: “Dentro de los intervalos de tiempo definidos por

fl’x∪y, se registran en conjunto dentro s1, s2, …, sm % de las transacciones los elementos de

X∪Y con las relaciones espaciales representadas según PredSx∪y, definidas entre las posiciones geográficas donde se registraron los items. Además cada vez que se registran los

elementos del conjunto de items X, en c1, c2, …,cm % de las transacciones dentro de los

intervalos de tiempo definidos por fl’x∪y, tienden a registrarse los valores del conjunto de

items Y con las relaciones espaciales representadas según PredSx∪y, definidas entre las

posiciones geográficas donde se registraron los items”.

3.4. Propiedad de Monotonía del modelo

Para poder descubrir los itemsets del modelo mediante un algoritmo basado en el algoritmo Apriori ([3]) -o en algoritmos basados en el mismo-, es necesario verificar que los itemsets cumplan la Propiedad de Monotonía planteada por Apriori. A continuación se muestra una prueba de la misma. Propiedad: Sea X un k-itemset, con un PredSX asociado, no frecuente en lX, entonces no existe

un itemset Y, con PredSY asociado, que contenga a X y sea frecuente en lY.

Prueba

Consideremos X, Y k-itemsets de la forma ( ) ( ) ( ){ }kk POSiPOSiPOSiX ,..., 2211=

( ) ( ) ( ) ( ){ }llkk POSiPOSiPOSiPOSiY ,,..., 2211=

Se puede demostrar por absurdo: suponemos Y frecuente, entonces existe [t,t’] ⊆ lY donde Sup(Y,[t,t’]) ≥ σ, |[t,t’]| ≥ τ y [t,t’] es maximal en lY . Considerando que X se encuentra contenido en Y, se aplica la definición de verifica(Tr,X) para ambos itemset:

De los mismos se observa que si se cumple el predicado verifica(Tr,Y) entonces se cumple verifica(Tr,X), ya que el primero agrega la condición existencia para el item il y la verificación de su predicado predjl. De esta manera, dada una transacción Tr en D, si Tr verifica Y entonces Tr verifica X. Por este mismo, motivo cualquier transacción del intervalo [t,t’] que verifique Y, verificará X; con lo cual [t,t’] ⊆ lX. Además por definición, cualquier elemento Tr de VD(Y,[t,t’]) pertenece también a VD(X,[t,t’]) ya que el intervalo de tiempo es el mismo y ya se observo que si se cumple verifica(Tr,Y)

{ } ( )( ))),(),,((::..2,:),( ''''1 kkkkjmmkkmkk yxyxprediiTrikmXiiiTriXTrverifica ∧=∈∃∈∈∀∧=∈∃=

{ } { } ( )( ))),(),,((::..2,:),( ''''1 kkkkjmmkkmkk yxyxprediiTrilkmYiiiTriYTrverifica ∧=∈∃∪∈∈∀∧=∈∃=


{ }),(),,(),...,(),,(Pr 11313212 ljlkjkjjY POSPOSpredPOSPOSpredPOSPOSpredPOSPOSprededS =


26

entonces se cumple verifica(Tr,X). Así: VD(Y,[t,t’]) ⊆ VD(X,[t,t’]) y |VD(X,[t,t’])| ≥ |VD(Y,[t,t’])|. Calculando el soporte para X:

σ≥=≥= ])',[,(])',[,(])',[,(

])',[,(]',[]',[

ttYSupD

ttYV

D

ttXVttXSup

tt

D

tt

D (por ser Y frecuente)

Además como |[t,t’]| ≥ τ (por el supuesto inicial) y [t,t’] ⊆ lX, queda X es frecuente en lX. Como esto contradice el hecho de que X no es frecuente se llega por absurdo a demostrar que no puede existir un itemset Y que contenga a X, y sea frecuente en lY.

3.4.1. Variantes de la propiedad

En la prueba dada se considero X,Y k-itemsets con el formato dado, que corresponde al caso más general. Dentro del proceso de descubrimiento de los itemsets espacio-temporales pueden darse otros dos casos donde X e Y tengan un formato diferente al anterior. Para los mismos se analiza el cumplimiento de: “si se cumple verifica(Tr,Y) entonces se cumple verifica(Tr,X)”, ya que la prueba de la Propiedad de Monotonía se basa en el mismo. (1). X es un 1-itemset, Y es un 2-itemset

El formato correspondiente a los mismos es: { }1iX= , ∅=XedSPr

( ) ( ){ }2211 , POSiPOSiY= , { }),(Pr 2112 POSPOSprededSY =

Para este caso, al aplicar la definición de verifica(Tr,X) se obtiene:

Se observa que dada un transacción Tr perteneciente a D si se cumple verifica(Tr,Y) entonces se cumple verifica(Tr,X), ya que verifica(Tr,Y) agrega la condición de existencia para el item i2 y la verificación de su predicado pred12. De esta manera, dada una transacción Tr en D, si Tr verifica Y entonces Tr verifica X. Siguiendo la prueba dada y teniendo en cuenta lo anterior, para este caso se verifica la Propiedad de Monotonía. (2). Varia el item principal

El formato de X e Y es: ( ) ( ) ( ){ }kk POSiPOSiPOSiX ,..., 2211=

( ) ( ) ( ) ( ){ }kkll POSiPOSiPOSiPOSiY ,...,, 2211=

Este caso puede darse en donde se conozca Y y se quiera determinar el subitemset X contenido dentro del mismo. Para este último se puede determinar de manera directa cuales son los items que lo componen en base a Y, aunque es un poco más complejo determinar los predicados que componen a PredSX.

( )1:),( iiTriXTrverifica kk =∈∃=

{ } ( )( ))),(),,((::2,:),( ''''1 kkkkjmmkkmkk yxyxprediiTrimYiiiTriYTrverifica ∧=∈∃∈∈∀∧=∈∃=

( )( ))),(),,((:: ''122''1 kkkkkkkk yxyxprediiTriiiTri ∧=∈∃∧=∈∃=


{ }),(),...,(),,(),,(Pr 332211 klqklqlqlqY POSPOSpredPOSPOSpredPOSPOSpredPOSPOSprededS =


27

Aplicando la definición de verifica(Tr,X) para X e Y se obtiene:

Para este caso no se puede confirmar que si se cumple verifica(Tr,Y) entonces se cumple verifica(Tr,X) ya que los predicados espaciales que involucran a cada uno de los predicados “verifica(Tr,X)” son distintos. Si pudiera expresar PredSY en un PredSY’ equivalente de la forma

{ }),(),,(),...,(),,('Pr 11313212 ljlkjkjjY POSPOSpredPOSPOSpredPOSPOSpredPOSPOSprededS = ,

quedaría:

Con lo cual se podría confirmar el cumplimiento de “si se cumple verifica(Tr,Y) entonces se cumple verifica(Tr,X)”, ya que verifica(Tr,Y) solo agrega la condición de existencia para el item il y la verificación de su predicado predjl. Para obtener PredSY’ equivalente, salvo predjl(POS1,POSl) que sería la inversa de predq1(POSl,POS1), debo poder inferir los predicados de PredSY’ en base a los de PredSY. Si las relaciones espaciales que representan los predicados fueran exactas las mismas se podrían inferir de manera directa. Al manejarse relaciones discretas lo que se podría hallar es un conjunto de predicados que juntos abarquen el correspondiente predicado de PredSY’, inferidos en base a los predicados espaciales de PredSY. La figura 3.6 muestra una representación gráfica del problema.

De esta manera puedo definir un PredSY^ que abarque a los predicados de PredSY’:

Figura 3.6. Representación del problema de hallar un PredSY’ equivalente dado PredSY

{ } ( )( ))),(),,((::..2,:),( ''''1 kkkkjmmkkmkk yxyxprediiTrikmXiiiTriXTrverifica ∧=∈∃∈∈∀∧=∈∃=

{ } ( )( ))),(),,((::..1,:),( '''' kkkkqmmkkmlkk yxyxprediiTrikmYiiiTriYTrverifica ∧=∈∃∈∈∀∧=∈∃=

{ } { } ( )( ))),(),,((::..2,:),( ''''1 kkkkjmmkkmkk yxyxprediiTrilkmYiiiTriYTrverifica ∧=∈∃∪∈∈∀∧=∈∃=


28

{ }),(^),,(^),...,(^),,(^^Pr 11313212 ljlkjkjjY POSPOSpredPOSPOSpredPOSPOSpredPOSPOSprededS =

En el mismo, pred^jk correspondería a un conjunto de predicados espaciales posibles, que abarcarían al correspondiente predicado en PredSY’. En este caso la verificación de un itemset Y^ (asociado a un PredSY^) se puede expresar como:

De la misma manera se podría expresar un itemset X^ con PredSX^ asociado:

{ }),(^),...,(^),,(^^Pr 1313212 kjkjjX POSPOSpredPOSPOSpredPOSPOSprededS =

Considerando lo anterior, para este caso particular la Propiedad de Monotonía debería ser expresada como: Propiedad’: Sea X un k-itemset con un PredSX asociado. En base al mismo, se define a X^

como el itemset conformado por los items de X, y asociado a PredSX^ formado por conjuntos

de predicados que abarcan a cada uno de los predicados de PredSX. Si X^ no es frecuente en

lX, entonces no existe un itemset Y, con PredSY asociado, que contenga a X y sea frecuente en

lY. A continuación se muestra la prueba de la misma. Prueba’

a). Se probara “Sea X^, con PredSX^ asociado, no frecuente en lx, entonces no existe itemset Y^, con PredSY^ asociado, que contenga a X^ y sea frecuente en lY.” Por contradicción: Sup. Y^ frecuente, entonces existe [t,t’] ⊆ lY donde Sup(Y^,[t,t’]) ≥ σ, |[t,t’]| ≥ τ y [t,t’] es maximal en lY . Dadas las definiciones de verifica(Tr,Y^) y verifica(Tr,X^) expresadas arriba, se observa que si se cumple verifica(Tr,Y^) entonces se cumple verifica(Tr,X^), ya que el primero agrega la condición de existencia para el item il y la verificación de un predicado de su pred^jl asociado. Por este mismo motivo cualquier transacción del intervalo [t,t’] que verifique Y^, verificará X^; con lo cual [t,t’] ⊆ lX. Además por definición, cualquier elemento Tr de VD(Y^,[t,t’]) pertenece también a VD(X^,[t,t’]) ya que el intervalo de tiempo es el mismo y ya se observo que si se cumple verifica(Tr,Y^) entonces se cumple verifica(Tr,X^). Así: VD(Y^,[t,t’]) ⊆ VD(X^,[t,t’]) y |VD(X^,[t,t’])| ≥ |VD(Y^,[t,t’])|. Calculando el soporte para X^:

σ≥=≥= ])',[,^(])',[,^(])',[,^(

])',[,^(]',[]',[

ttYSupD

ttYV

D

ttXVttXSup

tt

D

tt

D (por ser Y^ frecuente)

Además como |[t,t’]| ≥ τ (por el supuesto inicial) y [t,t’] ⊆ lX, queda X^ es frecuente en lX. Como esto contradice el hecho de que X^ no es frecuente en lX se llega por contradicción a demostrar que no puede existir Y^ que contenga a X^, y sea frecuente en lY. b). Se probará: “Sea Y un k-itemset con un PredSY asociado. En base al mismo, se define a Y^ como el itemset conformado por los items de Y, y asociado a PredSY^ formado por conjuntos

de predicados que abarcan a cada uno de los predicados de PredSY. Si Y^ no es frecuente en

lY, entonces el itemset Y tampoco es frecuente en lY.”

{ } { } (( ∧=∈∃∪∈∈∀∧=∈∃= mkkmkk iiTrilkmYiiiTriYTrverifica ''1 ::..2,^:)^,(

)))),(),,((:),(^),( ''11 kkkkmjmm yxyxpredPOSPOSpredPOSPOSpred ∈∃

{ } (( ∧=∈∃∈∈∀∧=∈∃= mkkmkk iiTrikmXiiiTriXTrverifica ''1 ::..2,^:)^,(

)))),(),,((:),(^),( ''11 kkkkmjmm yxyxpredPOSPOSpredPOSPOSpred ∈∃


29

Por contradicción: suponemos Y frecuente, entonces existe [t,t’] ⊆ lY donde Sup(Y,[t,t’]) ≥ σ, |[t,t’]| ≥ τ y [t,t’] es maximal en lY . Dado que cada uno de los elementos de PredSY^ son conjuntos que abarcan a cada uno de los predicados de PredSY, y teniendo en cuenta las expresiones de “verifica(Tr,Y)” y “verifica(Tr,Y^)”, se observa que si una Tr verifica Y entonces verifica Y^. Además por definición, cualquier elemento Tr de VD(Y,[t,t’]) pertenece también a VD(Y^,[t,t’]) ya que el intervalo de tiempo es el mismo y ya se observo que si se cumple verifica(Tr,Y) entonces se cumple verifica(Tr,Y^). Así: VD(Y,[t,t’]) ⊆ VD(Y^,[t,t’]) y |VD(Y^,[t,t’])| ≥ |VD(Y,[t,t’])|. Calculando el soporte para Y^:

σ≥=≥= ])',[,(])',[,(])',[,^(

])',[,^(]',[]',[

ttYSupD

ttYV

D

ttYVttYSup

tt

D

tt

D (por ser Y frecuente)

Además como |[t,t’]| ≥ τ y [t,t’] ⊆ lY (por el supuesto inicial), queda Y^ es frecuente en lY. Como esto contradice el hecho de que Y^ no es frecuente en lY se llega por contradicción a demostrar que Y tampoco puede ser frecuente en lY. c). Considerando las pruebas de a). y b). juntas, se prueba la propiedad’.


30

4. Algoritmos

En este capítulo se presentan los algoritmos para el descubrimiento de las reglas de asociación espacio-temporales y sus itemsets asociados, los cuales fueron presentados en el capitulo anterior. En cuanto al descubrimiento de los itemsets, se muestra el pseudocódigo del algoritmo y se explican los conceptos del mismo. Además se presenta una prueba de correctitud y un análisis de complejidad del algoritmo planteado; este último permite tener una aproximación teórica del comportamiento del algoritmo con los datos de entrada. Se finaliza explicando los algoritmos necesarios a aplicar sobre datasets que no cumplan con el esquema de datos planteado por el modelo.

4.1. Descubrimiento de las reglas de asociación espacio-temporales

La tarea de descubrimiento de las reglas de asociación espacio-temporales propuestas por el modelo se puede dividir en dos etapas, de manera similar a la tarea de [2]:

1. Descubrimiento de los itemsets espacio-temporales frecuentes en su lifespan. 2. En base a los itemsets espacio-temporales frecuentes descubiertos en la etapa anterior,

obtener las reglas de asociación espacio-temporales que superan los umbrales de confianza.

Teniendo en cuenta este esquema, se plantea un algoritmo para cada etapa. A continuación se presentan los mismos.

4.1.1. Descubrimiento de los itemsets espacio-temporales frecuentes

El algoritmo Apriori ([3]) fue desarrollado para el descubrimiento de itemsets frecuentes. El mismo se caracteriza por un esquema de armado de candidatos en función solamente de itemsets frecuentes de tamaño menor, sin considerar la base de datos; y presenta un comportamiento lineal en función de la cantidad de transacciones sobre las cuales se aplica. Debido a que los itemsets del modelo presentado cumplen la Propiedad de Monotonía de Apriori, se decide tomar este algoritmo como base para el desarrollo del algoritmo para el descubrimiento de los itemsets espacio-temporales frecuentes. De esta manera, al algoritmo Apriori se le incorporaron las modificaciones correspondientes para el descubrimiento de las componentes espaciales y temporales. Para estas últimas se tuvo en cuenta las modificaciones propuestas en [5] extendidas para el caso del modelo actual. Si bien para ser tomados como base existen otros algoritmos para el descubrimiento de itemsets frecuentes basados en Apriori y más eficientes que este último, como por ejemplo FP-growth ([16]), se selecciono Apriori por su simplicidad. Además, la identificación de los componentes a ser modificados sobre Apriori permite aplicarlos a futuro para extender otros algoritmos. El algoritmo propuesto se denomina STApriori. El mismo es presentado en las secciones siguientes.


31

4.1.1.1.Conceptos del algoritmo STApriori

El algoritmo STApriori propone modificaciones, que extienden al algoritmo Apriori, en los siguientes pasos: • Descubrimiento de items frecuentes • Generación de itemsets candidatos • Verificación en transacciones y contabilización de itemsets • Verificación de itemsets frecuentes según parámetros de umbrales

Descubrimiento de items frecuentes

Para los items o 1-itemsets, el ciclo de descubrimiento es similar al aplicado para itemsets de mayor tamaño, salvo detalles adicionales. Para el caso del armado de los itemsets candidatos, se tiene en cuenta el conjunto I, generando un candidato por cada uno de los items contenidos en el mismo. Respecto a determinar si un item se verifica en una transacción, se aplica la definición del modelo. Para este caso hay que considerar que corresponde la definición para k=1; de esta manera se debe verificar que la transacción contenga el mismo item que compone al 1-itemset. Durante la etapa de contabilización se agrega el mantenimiento de una lista de posiciones del item. La misma contendrá las posiciones geográficas donde el item se verifico en alguna transacción. Se actualizara cada vez que el item se verifica en alguna transacción, observando en la misma todas las posiciones geográficas donde se registra el item, y agregándolas a la lista correspondiente. Esta lista se utiliza posteriormente como poda en la generación de los 2-itemset candidatos. También durante la etapa de contabilización se incrementa, por cada transacción, el contador dentro del intervalo correspondiente en el histograma temporal de transacciones del dataset. El mismo mantiene la cantidad de transacciones en cada intervalo de discretización del dataset, determinado en base al parámetro ∆t definido por el usuario ([5]); y se utiliza posteriormente para los cálculos de soporte dentro de subintervalos contenidos en el lifespan, en la verificación de los itemsets frecuentes. Esta contabilización se realiza solamente en esta etapa, ya que luego no varía en las siguientes iteraciones del algoritmo.

Generación de itemsets candidatos

Para el caso de la generación de 2-itemsets candidatos, en el paso de junta se pasaran a formar itemsets conteniendo predicados espaciales dentro de su componente PredS. Para este caso los candidatos se formaran tomando pares de 1-itemsets frecuentes y agregándole a PredS algún predicado espacial posible entre los mismos. Se podrían considerar como posibles todos los predicados de P, el conjunto de predicados espaciales del algoritmo. De esta manera para cada par de 1-itemsets frecuentes formado se generaría un nuevo 2-itemset candidato en base a cada predicado espacial posible, determinado por P. Esto obligaría posteriormente a realizar la contabilización de todos los candidatos armados, cuando pueden existir predicados espaciales que nunca se verifiquen, y/o tampoco el correspondiente candidato conteniendo el mismo, de acuerdo a las combinaciones de posiciones geográficas existentes en el dataset. Considerando esto, se puede realizar una poda sobre el conjunto de predicados posibles para cada par formado. Para cada uno de los mismos, el conjunto de predicados espaciales posibles


32

se puede armar teniendo en cuenta la información recolectada en la contabilización de los 1-itemsets frecuentes respecto a la lista de posiciones geográficas donde se verifico el itemset. Los predicados se arman en base a pares de las mismas: por cada posición geográfica de la lista de un 1-itemset frecuente, se forman pares con cada una las posiciones geográficas de la lista del otro 1-itemset frecuente del par. Se evitan los pares duplicados, o con los mismos elementos invertidos, estos últimos debido a que generarían el predicado inverso equivalente. Luego los predicados se determinan calculando el correspondiente para cada uno de los pares de posiciones geográficas recién formados. Para este caso, también se evitan los predicados repetidos. De esta manera se obtienen 2-itemsets candidatos cuyos predicados espaciales sean solamente los posibles entre los items que forman a los mismos, debido a que se determinaron en base a todas las posiciones geográficas posibles que involucraban a los mismos en el dataset. En el caso de itemsets candidatos de tamaño mayor a 2 el paso de junta es similar al aplicado en el algoritmo Apriori. Se agrega en la condición de junta verificar también la igualdad de los predicados de PredS correspondientes a cada itemset frecuente que formará al candidato, hasta el penúltimo elemento de cada componente. De esta manera el nuevo candidato se encuentra formado por los elementos comunes de ambos candidatos mas los diferentes de los mismos, siendo estos elementos los items junto con sus predicados asociados dentro de PredS. El caso de que los itemsets frecuentes del par que formará al candidato tengan iguales items y difieran en sus PredS no es necesario de ser verificado; el mismo no ocurriría debido a que: • en la generación de candidatos de tamaño 2 los items del par son distintos; y entre

pares con iguales items los predicados son distintos • en la generación de candidatos de tamaño mayor a 2 los items de los candidatos

formados no pueden repetirse, ya que en este caso sería eliminados en el paso de poda, debido a que el mismo no encontraría como frecuente al subitemset que contenga items repetidos -considerar que comenzando con la generación de candidatos de tamaño 2 estos itemsets no fueron generados-.

A diferencia de lo propuesto en [5], para este modelo el lifespan del nuevo candidato no es posible de ser determinado en base al de los itemsets que lo forman. El cálculo propuesto en [5] indica que el lifespan del nuevo candidato se armara en base a la intersección de los lifespan de los itemsets frecuentes generadores del mismo. Esta condición implica el hecho de que si en una transacción se verifican los itemsets frecuentes generadores del candidato, debe verificarse el candidato. Esto no es cierto para este modelo, ya que esta condición es necesaria pero no suficiente. En este modelo, en la transacción además

• para el caso k = 2, debe verificarse el predicado espacial que relaciona a los items del nuevo candidato; o bien

• para el caso k > 2, los predicados espaciales de los nuevos items agregados al candidato deben verificarse ambos respecto a la misma posición geográfica de la transacción -la que se correspondería con la posición del item principal dentro del itemset candidato-.

De esta manera el lifespan se genera, en todos los casos, de manera dinámica durante la contabilización. Igualmente, el hecho de que si en una transacción se verifican los itemsets frecuentes generadores del candidato sea condición necesaria para verificar el candidato, permite señalar que para el nuevo candidato ic, formado en base a los itemsets ij e ik,

kjc iineci llll ∩=⊆ . Esto se puede utilizar como poda adicional de tipo temporal de los nuevos

candidatos, verificando que τ≥necl , similar a como se plantea en [4].

En el caso de la generación de 2-itemsets candidatos, el Paso de Poda propuesto en el algoritmo Apriori no es necesario aplicarlo ya que los dos itemsets que forman al candidato


33

son frecuentes, por formar parte de L1. En el caso de la poda de tipo temporal comentada en el párrafo anterior, la misma se aplica junto con la generación y no en un paso aparte. Esto es así ya que permite aplicarla una vez formado el par de items, en base a los dos 1-itemsets frecuentes, pero antes de determinar el conjunto de predicados posibles para el mismo y armar los correspondientes 2-itemsets candidatos. De esta manera, si el par de items armado no cumple la condición de la poda temporal, se evita el cálculo de los predicados posibles para el mismo, junto con el armado de los correspondientes 2-itemsets candidatos, los cuales tendrían todos el mismo resultado frente a la poda temporal. En el caso de la generación de itemset candidatos de tamaño mayor a 2, la poda temporal se agrega al Paso de Poda junto a lo propuesto por el algoritmo Apriori. En el mismo primero se valida la condición de la poda temporal, en base al lnec calculado en la generación del candidato. Luego se aplica el Paso de Poda propio del algoritmo Apriori, extendido para el modelo actual. Para el mismo se debe considerar que los “subconjuntos” de un candidato se encuentran conformados por los items más los predicados espaciales que conforman PredS. Si el subconjunto considerado contiene al item principal del candidato (en general el primero dentro del mismo), no habrá problema en determinar el PredS del subconjunto: como todos los predicados son respecto a este primer item, simplemente se debe eliminar el predicado correspondiente al item eliminado. En cambio, si el subconjunto considerado no contiene a este item principal, se puede aplicar lo considerado en la variante de la Propiedad de Monotonía de Apriori para el modelo. La misma fue explicada en el capítulo anterior, en el punto 3.4.1, dentro del caso (2). El caso planteado para la misma es el mismo que aplica en este punto: se tiene el itemset Y y el itemset X es el subconjunto del mismo el cual se debe determinar, ya que se desconoce cuales son los predicados que lo componen. Teniendo en cuenta la propiedad planteada se debe trabajar con el item X^. Para la obtención del mismo se debe partir desde Y, y en base al mismo obtener Y^, determinando los conjuntos de predicados que van a componer PredSY^. Los mismos deben abarcar a los de PredSY y estar expresados respecto al item principal de X. Luego, para obtener X^ se deben eliminar de Y^ el item y su correspondiente elemento en PredSY^ que no forma parte de X (ni de X^) –el cual se corresponde con el item principal del itemset Y original-. Por último, para poder utilizar la propiedad se debe determinar si X^ no es frecuente en lX, aunque para esto solo se tiene el conjunto de itemsets frecuentes de la pasada anterior, conteniendo los posibles itemsets X que abarcaría X^. Como simplificación para determinar esto se puede solamente verificar la no existencia de un itemset que contenga los items de X. Si el mismo no existe, implica que X^ no es frecuente, y, en base a la propiedad planteada, que el itemset candidato Y no es frecuente. Si llegará a existir algún itemset, puede ser que X^ sea o no frecuente, pero para el caso de la simplificación no se tiene en cuenta, suponiendo que en la mayoría de estos casos X^ es frecuente. De esta manera, se verifica en el conjunto de (k-1)-itemsets frecuentes la existencia de un itemset que contenga solamente los items que conforman al “subconjunto” y no los posibles predicados que pudiera tener el mismo. Si el mismo no existe, implica que X^ no es frecuente y, por lo tanto, Y puede ser podado por no ser frecuente. Si el mismo existe, se supone que X^ es frecuente, aunque esto no nos asegura nada sobre Y. De esta manera, al igual que en el caso de un subitemset que contiene al item principal, la poda no puede aplicarse. Debido a que esta verificación se realiza mirando los itemsets frecuentes de la pasada anterior de manera parcial, ignorando los predicados espaciales de PredS, es conveniente realizar la misma luego de haber verificado los demás subitemsets que contienen al item principal.

Verificación en transacciones y contabilización de itemsets


34

Para determinar si un itemset se verifica dentro de una transacción se aplica la definición dada por el modelo. De esta manera se verifica que los items estén contenidos dentro de la transacción, y que los predicados espaciales definidos por PredS se verifiquen en las correspondientes posiciones geográficas de la transacción. Para este caso se decide realizar una simplificación a lo propuesto por Apriori y no aplicar una versión extendida del hash-tree ([3]) propuesta en el mismo, debido a la complejidad de adaptación de la misma para obtener una versión que trabaje con los itemsets del modelo actual. Se prefiere aplicar la alternativa propuesta en [3] de uso de un bitmap para mantener la información de cada transacción. Debido a que en las transacciones del modelo propuesto cada item se encuentra asociado con una posición geográfica -conteniendo cada posición geográfica un conjunto de items asociados- se propone extender la estructura de [3] con una colección de bitmaps. Cada entrada de la misma tiene el valor de una posición geográfica de la transacción y un bitmap con el contenido de los items asociados a esta posición geográfica. Se utiliza una colección y no un arreglo de bitmap –con longitud fija- debido a que las transacciones pueden contener diferente cantidad de posiciones geográficas, evitándose forzar a conocer la misma previo al armado de la estructura de bitmaps. Para el caso en que se manejen items del tipo “atributo-valor” –como se explica mas adelante en la sección 4.2-, la estructura de bitmap puede ser reemplazada con un arreglo, conteniendo los valores de los items manejados. Debido, a que cada item representa una dupla “atributo-valor”, cada posición geográfica de una transacción contendrá a lo sumo un item para cada atributo manejado en el dataset. De esta manera, se propone, en reemplazo del bitmap, el uso de un arreglo con una posición para cada atributo manejado, almacenando en cada posición el valor en base a cada item -de tipo “atributo-valor”- perteneciente a la transacción para la posición geográfica actual. Debido a que este esquema de verificación de cada itemset en la transacción puede ser aplicado de manera separada por cada itemset candidato -y no requiere ser aplicado para todo el conjunto de itemsets candidatos como en el caso del esquema propuesto en Apriori-, se decide aplicarlo de esta manera, para evitar mantener en una estructura aparte el conjunto de itemsets contenidos en la transacción. Respecto a la contabilización, cada itemset va a tener asociados un conjunto de atributos: • count: contador de transacciones donde se verifica el itemset • lifespan.min, lifespan.max: extremos del lifespan. • trans_number: contador de la cantidad de transacciones dentro del lifespan del itemset. • trans_number_aux: contador auxiliar. Se utiliza debido al cálculo del lifespan

dinámicamente. • histogram[]: histograma temporal conteniendo contadores de la cantidad de

transacciones donde se verifica el itemset en cada intervalo de discretización de su lifespan, definido por el parámetro ∆t ([5]). Se utiliza posteriormente para los cálculos de soporte dentro de subintervalos contenidos en el lifespan del itemset.

• positions[]: lista de posiciones geográficas dentro de las transacciones donde se verifico el itemset (usada en el caso k=1).

Si el itemset se verifica en la transacción, se actualizan los campos: count, lifespan.min, lifespan.max -el lifespan se calcula dinámicamente siempre-, trans_number -en base a trans_number_aux-, contador dentro del intervalo correspondiente en histogram[] y, si es un 1-itemset candidato, positions[]. El incremento del extremo superior del lifespan permite realizar el cálculo del mismo de manera dinámica. Para el caso del histograma temporal, también se arma de manera dinámica,


35

incrementado el contador del intervalo correspondiente, y completando 0, si corresponde, en los intervalos intermedios donde no se verificaron transacciones. Como el lifespan se determina de manera dinámica, para calcular la cantidad de transacciones dentro del mismo, el esquema de contabilización para cada candidato es de la siguiente manera: luego de actualizarse el lifespan del itemset según la verificación (o no) del mismo en la transacción, • si la transacción se encuentra dentro del lifespan del candidato, se incrementa

trans_number. En este caso, como se actualizó previamente el lifespan del itemset, se actualiza la cantidad de transacciones dentro del mismo.

• caso contrario, si el candidato comenzó a contabilizarse se incrementa trans_number_aux. En este caso, al no haberse actualizado previamente el lifespan del itemset, se comienza a generar un posible “hueco” -intervalo contenido dentro del lifespan del itemset donde no se verifica en la base de datos- en el mismo, por lo tanto se incrementa el contador auxiliar trans_number_aux. De esta manera, cuando el candidato vuelva a verificarse en alguna transacción, el valor de este atributo auxiliar se incrementará sobre trans_number, permitiendo contabilizar la cantidad de transacciones dentro del “hueco” del lifespan donde no se verifico el itemset.

Verificación de itemsets frecuentes según parámetros de umbrales

Al momento de verificar cuales itemsets candidatos contabilizados son frecuentes, se deben verificar dos umbrales, los cuales se aplican primero sobre el lifespan según las definiciones del modelo: • el de soporte temporal (τ), comparándolo con el cálculo del soporte temporal del

itemset dentro de su lifespan • el de soporte (σ), comparándolo con el cálculo del soporte del itemset espacio-

temporal dentro de su lifespan En caso de que el itemset no verifique el umbral de soporte y si el de soporte temporal se aplica el algoritmo a-posteriori ([5]) para hallar los subintervalos maximales frecuentes contenidos dentro del lifespan. Si se encuentra algún intervalo para el itemset en cuestión, el mismo pasa a formar parte del conjunto de itemsets frecuentes de la pasada. Si el itemset no supera el umbral de soporte temporal, sin importar si se supera el umbral de soporte, no se aplica el algoritmo a-posteriori ya que no van a existir subintervalos dentro contenidos del lifespan que superen el umbral de soporte temporal. El algoritmo a-posteriori utiliza como parámetros, para hallar los subintervalos maximales frecuentes contenidos dentro del lifespan, los histogramas temporales del itemset candidato y del dataset, junto con la unidad de discretización ∆t de los mismos. Estos histogramas fueron actualizados durante los ciclos de contabilización previos, incrementado los contadores propios de los intervalos de tiempo correspondientes. Estos intervalos de tiempo fueron determinados en base a la unidad de discretización ∆t del algoritmo. La misma, comentada en el capítulo 2 –sección 2.2.2-, es un parámetro definido por el usuario ([5]). Para el caso en que se aplique este algoritmo, si se descubre durante el mismo algún subintervalo que abarque intervalos ∆t que contengan a los extremos del lifespan del candidato, se tiene en cuenta los extremos dados por este último y no los de los intervalos ∆t correspondientes. Esto se debe a tres motivos: • al identificar el subintervalo frecuente evito considerar intervalos de tiempo que no

estén completamente incluidos en el lifespan, los cuales se identificarían debido a la


36

unidad de discretización ∆t utilizada. Esto no sería compatible con la definición de lifespan frecuente del modelo.

• en el cálculo del soporte temporal, se evita aumentar el valor del mismo respecto al sector del subintervalo de tiempo que no corresponde, ya que se encuentra fuera del lifespan. Según la unidad de discretización considerada pueden ocurrir casos donde se supere el umbral de soporte temporal al tomar un sector pequeño del intervalo que contiene al extremo del lifespan. En este caso, el soporte temporal del intervalo correcto, es decir, sin tomar los instantes de tiempo de las transacciones no pertenecientes al lifespan, es menor y puede no superar el umbral del soporte temporal. De esta manera, el itemset puede ser considerado frecuente cuando en realidad no lo es.

• para el caso del cálculo el soporte, el valor calculado debe abarcar el intervalo ∆t que contiene al extremo del lifespan de manera completa, ya que se discretizan los histogramas de todos los itemsets de igual manera para utilizar siempre en los cálculos de soporte los contadores del mismo histograma correspondiente al dataset. De esta manera, el valor del mismo es menor al verdadero valor del soporte dentro del subintervalo que abarca hasta el extremo del lifespan, ya que el divisor en el cálculo del soporte es mayor. Con lo cual si esta cuenta supera el umbral de soporte, seguramente lo hará el valor verdadero. Teniendo en cuenta esto, si bien estaría aproximando, o estimando, el valor del soporte por uno menor, no estaría considerando como frecuente un itemset que no lo sea, como ocurría en el caso anterior con el soporte temporal.

La última consideración no influye para el caso en que se toma el extremo superior como parte del subintervalo descubierto y este coincide con el fin del dataset. En este caso el valor calculado del soporte es igual al verdadero ya que no existen más transacciones por contabilizar, con lo cual el divisor de la cuenta toma el mismo valor. Igualmente, el intervalo ∆t del histograma correspondiente al candidato también se corta en el mismo instante que el del histograma del dataset, el cual se corresponde con el final de este último. Esto es para evitar el segundo punto considerado, y para que el intervalo descubierto se encuentre completamente contenido dentro del intervalo de tiempo de la base de datos.

4.1.1.2.Pseudocódigo algoritmo STApriori

El siguiente es el pseudocódigo del algoritmo STApriori, considerando los conceptos explicados en la sección anterior. El mismo permite tener una idea de la estructura general del algoritmo. Entradas:

• base de datos ( ){ }{ } ( ) { }{ }{ }kjjjjkr iyxtyxitTD ,,,,,, ===

• conjunto de items { }kiiiI ,,21, K=

• conjunto de predicados espaciales P definidos entre dos posiciones geográficas (representando las relaciones espaciales posibles entre todos los puntos existentes en la base de datos)

• umbral de soporte σ

• umbral de soporte temporal τ

• intervalo unidad de discretización ∆t

37

Salida: conjunto de itemsets espacio-temporales frecuentes L, existentes en D STApriori(D, I, P, σ, τ, ∆t) {

L1 = calcular1ItemsetsFrecuentes(D, I, σ, τ, ∆t);

for (k=2; Lk-1 ≠ ∅ ; k++) { Ck = stapriori-gen(Lk-1); for each Tr in D { for each c in Ck { if verifica(Tr,c) incrementarContadores(c); incrementarContadoresAuxiliares(c); } } Lk = verificarFrecuentes(Ck);

}

return L = Uk

kL ;

} /*genera itemsets espacio-temporales candidatos*/ stapriori-gen(Lk-1){ if (k = 2) return stapriori-gen_Initial(Lk-1); else return stapriori-gen_High(Lk-1); } stapriori-gen_Initial(Lk-1){

return { } { }{ )()(2 ,),(Pr,)(),(ljk iinecljjlklljjk lllPOSPOSprededSPOSiPOSiiC ∩====

}'/ Ppredlii jlneclj k∈∧≥∧< τ

, donde P’=predicadosPosibles(ij,il) } predicadosPosibles(ij,il){

{ }{ }21.2.1/2,1 posposPOSITIONSiposPOSITIONSiposposposPairs lj ≠∧∈∧∈=

//P’ ordenado según P

return

} stapriori-gen_High(Lk-1){

//paso de Junta

{ }{ ,)(),(,),(),( 112211 kkkkkk POSiPOSiPOSiPOSiiC −−== K

{ },),(),,(),,(Pr 111)1(212 kjkkkjjk POSPOSpredPOSPOSpredPOSPOSprededS −−= K

:,/ 1)()( −∈∃∩= kljiinec Liilllljk

{ },)(),(,),(),( 11222211 −−−−= kkkkj POSiPOSiPOSiPOSii K

{ },)(),(,),(),( 222211 kkkkl POSiPOSiPOSiPOSii −−= K

( )}kk ii <∧ −1

(CC)

{ /)2,1(' PpospospredicadopredP ∈==

{ }),(),,(Pr 11)1(212 −−= kkjjj POSPOSpredPOSPOSprededS K

{ }),(),,(Pr 1212 kjkjl POSPOSpredPOSPOSprededS K=

{ } }Pairspairpospospairpospos ∈∀=∈ ,2,12,1

38

//paso de Poda

return ( ){ 1:)()/( −∈∈∀∧≥∈= kneckk LscssubitemsetslCcCk

τ

{ }( )( )}1'132 Pr,,,,' −− ∉∀=¬∧ kskk LedSiiiis K

} /*retorna subitemsets que contienen al item principal*/ subitemsets(c){

return { }{ }kkciprededSedSicc kjkkkk ,,2',,PrPr, ''1'1 K∈∈∀−=−= −−

} verifica(Tr,c){ if (|c| = 1)

return ( )1: iiTri kk =∈∃

else

return ( )( )( )),(),,(,:1,: ''''1 kkkkjllkklkk yxyxprediiTrilciiiTri ∧=∈∃>∈∀∧=∈∃

} incrementarContadores(c){ c.COUNT++; c.HISTOGRAM[n]++ , n / c.HISTOGRAM[n].MIN<=Tr.t<=c.HISTOGRAM[n].MAX if (Tr.t > c.LIFESPAN.MAX){ c.LIFESPAN.MAX = Tr.t; c.TRANS_NUMBER = c.TRANS_NUMBER + c.TRANS_NUMBER_AUX; c.TRANS_NUMBER_AUX = 0; } if (|c| = 1){

c.POSITIONS = c.POSITIONS { }1/),( iiTryx kjj =∈U

} } incrementarContadoresAuxiliares(c){ if (c.LIFESPAN.MIN <= Tr.t <= c.LIFESPAN.MAX) c.TRANS_NUMBER++; else

if (c.LIFESPAN ≠ ∅) c.TRANS_NUMBER_AUX++; } incrementarContadoresDataset(Tr){ D.HISTOGRAM[n]++ , n / D.HISTOGRAM[n].MIN<=Tr.t<=D.HISTOGRAM[n].MAX } verificarFrecuentes(Ck){

L = ∅; for each c in Ck {

if ( (c.LIFESPAN.MAX – c.LIFESPAN.MIN + 1) >= τ){ if ( (c.COUNT/c.TRANS_NUMBER) >= σ ){ L = L U {c}; } else{ a-posteriori(c);

if (c.FREQ_LIFESPAN ≠ ∅) L = L U {c}; }

}

39

} return Lk = L;

} a-posteriori(c){ INDEX = n / D.HISTOGRAM[n].MIN = c.HISTOGRAM[1].MIN; h=1; while (h <= c.HISTOGRAM.SIZE){

m=0;

∑=

=SIZEHISTOGRAMc

hi

iHISTOGRAMcCOUNTSUM..

][._ ;

∑+

+=

=INDEXSIZEHISTOGRAMc

INDEXhj

jHISTOGRAMDTRANSSUM..

][._ ;

FR = SUM_COUNT/SUM_TRANS; while( (FR < σ) ^ ((c.HISTOGRAM.SIZE + 1 – m - h)*∆t >= τ) ){ SUM_COUNT -= c.HISTOGRAM[c.HISTOGRAM.SIZE - m]; SUM_TRANS -= D.HISTOGRAM[c.HISTOGRAM.SIZE – m + INDEX]; FR = SUM_COUNT/SUM_TRANS; m++; } if ((c.HISTOGRAM.SIZE + 1 – m - h)*∆t >= τ){ c.FREQ_LIFESPAN U

{[((h+INDEX-1)*∆t)+1; (c.HISTOGRAM.SIZE–m+INDEX)*∆t]};

h = c.HISTOGRAM.SIZE – m + 1; } else h++;

} } calcular1ItemsetsFrecuentes(D, I, σ, τ, ∆t){

{ }{ }IiedSiiC jkjk ∈∅=== /Pr,1 ;

for each Tr in D { for each c in C1 { if verifica(Tr,c) incrementarContadores(c); incrementarContadoresAuxiliares(c); }

incrementarContadoresDataset(Tr); } return L1 = verificarFrecuentes(C1); }

4.1.1.3.Prueba de correctitud

La siguiente es la prueba de correctitud del algoritmo STApriori presentado. Con la misma se verifica que el algoritmo cumple adecuadamente su objetivo de obtener el conjunto de todos los itemsets espacio-temporales frecuentes, en base a los parámetros de entrada, del dataset D. Para probar la correctitud del algoritmo primero se va a probar el siguiente lema. Lema 1. Para cada nivel k STApriori descubre el conjunto de todos los itemsets espacio-

temporales frecuentes para ese nivel.

(CC1)


40

Prueba:

Designamos el predicado del enunciado Qk, vamos a analizar diferentes valores de k. Para el caso de Q1, C1 contiene a L1 ya que contiene todos los candidatos posibles tomados en base a I. La verificación de los candidatos en la transacción es correcta ya que se aplica la definición de “verifica(Tr,X)” del modelo. Luego de procesarse el ciclo de contabilización (CC1) cada contador indicará:

• c.LIFESPAN: lifespan del itemset, ya que el mismo se fue armando dinámicamente cada vez que el itemset se verificaba en alguna transacción. En estos casos se extendía el mismo, asignando como extremo superior el timestamp de la transacción en contabilización

• c.COUNT: cantidad de transacciones donde se verifica el itemset, dentro de su lifespan, ya que se incrementa cada vez que el candidato se verifica en alguna transacción

• c.POSITIONS: posiciones geográficas donde se verifica el itemset en cada transacción, ya que son incluidas cada vez que se verifica el candidato en alguna transacción, observando los items que se verifican en cada una de las posiciones geográficas de la misma

• c.HISTOGRAM: cantidad de transacciones en cada intervalo ∆t del lifespan del itemset, ya que se fue armando dinámicamente de forma similar al lifespan e incrementando el contador correspondiente cada vez que el itemset se verificaba en alguna transacción

• c.TRANS_NUMBER: cantidad de transacciones en el lifespan del itemset, ya que el mismo se incrementaba de dos maneras:

o cada vez que el itemset se verificaba en la transacción, se extendía el lifespan del mismo. Luego c.TRANS_NUMBER se incrementaba en una unidad ya que el timestamp de la transacción se verificaba dentro del lifespan (recién extendido)

o cuando el itemset no se verificaba en la transacción se incrementaba c.TRANS_NUMBER_AUX, de esta manera mantenía el acumulado de la cantidad de transacciones existentes en el periodo, dentro del lifespan, en donde el itemset no se verificaba en alguna transacción. Luego, cuando el itemset volvía a verificarse en una transacción se incrementa c.TRANS_NUMBER en base al valor de c.TRANS_NUMBER_AUX, actualizando la cantidad de transacciones en el lifespan del itemset incluyendo las pertenecientes al periodo anterior donde no se verifico el itemset. Luego c.TRANS_NUMBER_AUX se asigna en 0 por si es necesaria volver a realizar la misma contabilización en otro periodo.

• D.HISTOGRAM: cantidad de transacciones en cada intervalo ∆t del dataset, ya que se fue incrementando el intervalo correspondiente con cada transacción.

Luego, la verificación de los itemsets espacio-temporales frecuentes obtiene todos los itemsets frecuentes ya que solo elimina aquellos que no cumplen la definición:

• en el caso de ser itemsets frecuentes en su lifespan (l): el intervalo l es maximal por ser el lifespan y aplicando las definiciones del modelo con los contadores del ciclo (CC1) queda:

o MBERc.TRANS_NU

c.COUNT==

l

D

D

lcVlcSup

),(),(

o SupT(c,l) = |l| = c.LIFESPAN.MAX – c.LIFESPAN.MIN + 1 • en el caso de ser frecuentes en subintervalos maximales dentro del lifespan: se aplica

el algoritmo a-posteriori ([5]) para hallar los intervalos maximales frecuentes dentro del lifespan. Los intervalos descubiertos por el mismo son maximales (o tan

41

maximales como sea posible por el algoritmo) ya que se obtienen decrementando desde el máximo intervalo posible (empezando por el todo el lifespan) de a una unidad de discretización ∆t (manejada por el algoritmo). Aplicando las definiciones del modelo sobre estos intervalos, en base a los contadores mantenidos por a-posteriori queda:

o ==MAXIMALINTEVALO

D

D

MAXIMALINTERVALOcVMAXIMALINTERVALOcSup

_

)_,()_,(

FRTRANSSUM

COUNTSUM

iHISTOGRAMD

iHISTOGRAMc

MAXIMALINTERVALOi

MAXIMALINTERVALOi===

∑

∑

∈

∈

_

_

][.

][.

_

_

o SupT(c,INTERVALO_MAXIMAL) = |INTERVALO_MAXIMAL|

=max(INTERVALO_MAXIMAL) – min(INTERVALO_MAXIMAL) + 1 =((c.HISTOGRAM.SIZE–m+INDEX)*∆t)-(((h+INDEX-1)* ∆t)+1) + 1 =((c.HISTOGRAM.SIZE + 1 – m – h) *∆t)

El mismo solo se aplica en caso de que no se supere el umbral de soporte y si el de soporte temporal, ya que si no se supera el umbral de soporte temporal no puede existir un intervalo incluido dentro del lifespan que supere el mismo.

Como solo elimino de C1 aquellos itemsets que no aplican la definición de frecuentes, L1 va a contener todos los itemsets espacio-temporales frecuentes de tamaño 1 existentes en D. Para el caso de k>1, vamos a suponer que Qk-1 es cierta para probar Qk. Primero vamos a probar que para el Ck generado kk LC ⊇ .

Para el caso de k=2, 22 LC ⊇ ya que se forma armando todos los elementos posibles:

• cada par de items se forma tomando todos los pares de L1, la condición “ij < il” permite asegurar que no se repitan pares.

• todos los predicados posibles asignados a cada par de items (P’) permitirán relacionar espacialmente a cada par de puntos posibles del dataset para cada par de items, ya que son calculados en base a cada par de puntos existente que verifique el par de items en D, considerando lo contabilizado por c.POSITIONS en (CC1). El hecho de tomar cada par de puntos como conjunto “{pos1, pos2}” se hace para evitar un par de puntos invertido que generaría el predicado inverso equivalente -repitiendo el significado de su inverso anterior-. Tomando P’ como conjunto evito generar predicados iguales. De esta manera, se evita considerar los predicados que seguramente no se verificarán para el par de items tomado.

La condición τ≥knecl evita generar candidatos cuyo lifespan no superará el umbral de soporte

temporal. Esto se debe a que el knecl , definido como )()( ljk iinec lll ∩= , abarca al lifespan del

candidato; ya que las transacciones contenidas en el mismo cumplen una condición necesaria, pero no suficiente -debido a que no se considera el PredS- para verificar el candidato formado. Esta poda temporal se aplica dentro de la generación de los 2-itemsets candidatos, luego del armado del par de 1-itemsets frecuentes. De esta manera si la condición de la misma no se verifica, se evita generar los predicados posibles y los candidatos conteniendo a los mismos. Esto candidatos no serán frecuentes, ya que el valor de lnec será el mismo para todos, debido a que depende solamente de los dos (k-1)-itemsets que conforman los items de estos candidatos.

42

Para el caso de k>2, dado un c perteneciente a Ck, por cumplir el modelo la Propiedad de Monotonía, como se comento en la sección 3.4 del capítulo anterior, se puede considerar: sea c un k-itemset candidato, con PredSc asociado, frecuente en lc, entonces no puede existir sub-

itemset s, con PredSs asociado, contenido en c y que no sea frecuente en ls.

De esta manera para armar cada elemento de Ck dados los de Lk-1, se tomaría cada elemento de Lk-1, se extendería con cada item i perteneciente a I y predicado pred perteneciente a P; y luego se verificaría que cada subitemset sea frecuente. De esta manera obtendría todos los candidatos posibles de Ck. El paso de junta planteado equivale a extender cada elemento de Lk-1 con una combinación de item más predicado posible, según I y P, y luego eliminar aquellos candidatos extendidos cuyos subitemsets conformados eliminando los elementos k y (k-1), junto a sus predicados, no pertenecen a Lk-1. La condición “ik-1 < ik” evitaría los duplicados, permitiendo combinar todos los elementos de Lk-1 entre si en base a un orden determinado.

En el paso de poda se verifica también la condición τ≥knecl . Al igual que en el caso de la

generación de candidatos de k=2, la misma evita generar candidatos cuyo lifespan no superará el umbral de soporte temporal. Luego se verifica la Propiedad de Monotonía para los subitemsets. En el caso del subitemset que no incluye al item principal, al aplicarse la variante de la Propiedad de Monotonía, de la manera explicada en la sección 4.1.1.1 –dentro de “Generación de itemsets candidatos”-, se asegura que se eliminan los itemsets que no serán frecuentes. La simplificación aplicada solamente restringe los mismos al caso más común donde X^ no es frecuente, y por lo tanto Y tampoco. En el caso de existir un itemset frecuente en Lk-1 que tenga iguales items, puede ocurrir el caso que X^ no sea frecuente, pero este caso se omite por cuestiones de simplicidad, considerando que la poda en estos casos no puede aplicarse. De esta manera, los candidatos de estos casos serán contabilizados en la siguiente pasada. Teniendo en cuenta lo anterior, de todos los candidatos de Ck, solo elimino aquellos que no serán frecuentes, por no cumplir condiciones espaciales, temporales y/o la Propiedad de Monotonía del modelo. Así, kk LC ⊇ , para cualquier k>2 -se puede extender a k > 1 por la

explicación anterior para el caso k=2-. La verificación de los itemsets espacio-temporales en las transacciones es correcta ,ya que también se aplica en base a la definición de “verifica(Tr,X)” del modelo. Luego de procesarse el ciclo de contabilización (CC), los contadores del mismo registrarán los mismos valores que en el ciclo (CC1), excepto c.POSITIONS, que no corresponde al caso ya que |c| > 1, y D.HISTOGRAM, el cual no necesario actualizarlo en sucesivas pasadas ya que su valor -cantidad de transacciones en cada intervalo de discretización ∆t del dataset- no varia. La verificación de los itemsets espacio-temporales candidatos obtiene todos los itemsets frecuentes en Ck, eliminando solamente aquellos que no aplican la definición, de la misma manera a como se comento para k=1; de esta manera Lk contiene todos los itemsets espacio-temporales frecuentes de tamaño k existentes en D.□ Como para cada nivel k se cumple el lema 1 dado por el predicado Qk, STApriori descubre el conjunto de todos los itemsets espacio-temporales frecuentes existentes en D.

4.1.1.4.Análisis de complejidad

43

El siguiente es un análisis de complejidad del algoritmo STApriori. El mismo permite tener una idea inicial a nivel teórico del comportamiento del algoritmo en las pruebas de performance. Observando los parámetros de entrada del algoritmo STApriori, se pueden identificar cuales son los que influyen en el análisis de complejidad:

• |D|: cantidad de transacciones de la base de datos • |GPD|: cantidad de posiciones geográficas existentes en D • |I|: cantidad de items existentes • |P|: cantidad de predicados espaciales posibles • σ: umbral de soporte • τ: umbral de soporte temporal • ∆t : intervalo unidad de discretización

Hay que tener en cuenta que GPD es el conjunto de posiciones geográficas existentes en D, y |GPD| la cantidad de elementos del mismo. El motivo por el cuál ninguno de los no aparece como parámetro del algoritmo STApriori, en los elementos de las entradas de su pseudocódigo, es porque viene contenido dentro D; y es a través de este, en particular de sus transacciones, donde el algoritmo realiza el procesamiento de GPD. Para este caso se coloca como un parámetro más de manera separada, ya que influye en el análisis de complejidad, aunque en esencia para el algoritmo sería un parámetro ligado a D. Considerando la estructura base del algoritmo, se puede identificar 4 componentes principales:

1). generación de L1, 2). generación de candidatos mediante stapriori-gen, 3). ciclo de verificación y contabilización de candidatos (CC) 4). verificación de candidatos frecuentes.

En base a los mismos se pueden identificar la cantidad de operaciones del algoritmo STApriori:

ops = genL1 + (kmax -1)(stapriori-gen + |D| |Ck| verified-count + verifyFrecuents) kmax depende de la cantidad de ciclos en la ejecución del algoritmo, con lo que puede ser acotado por kmax <= |I|.|GPD|, es decir, la cantidad máxima posible de elementos de una transacción -suponiendo cada transacción con valores para todas las posiciones geográficas posibles en D-. |Ck| para cada k se puede obtener en base a los valores de k-1: k=1

|C1| = |I| k=2 (combino cada elemento de L1 con los demás y genero P’ en base a c.POSITIONS de

cada 1-itemset del par formado)

|C2| <= |L1|(|L1|+1)/2 * |P^’| = |L1|(|L1|+1)/2 * ν|P|

obs.: ∑ ∑

= =

+==

1

||

11||

11

1

2

)1|(|||

Lj

L

j

LLjj

k>2 (para cada elemento de L(k-1) aplico join con los demás siguientes –tomo el conjunto

de manera ordenada-)

44

|Ck| <= |L(k-1)JoinMax||Lk-1| = (βk|Lk-1|)|Lk-1| , donde:

• |P^’|: cantidad promedio de predicados que se verifican entre todos los pares de posiciones geográficas, para cada par de 1-itemsets frecuentes

• ν: proporción promedio de predicados, respecto a P, que se verifican entre todos los pares de posiciones geográficas, para cada par de 1-itemsets frecuentes

• |L(k-1)JoinMax|: cantidad máxima de (k-1)-itemsets frecuentes que cumplen condición de join para cada (k-1)-itemset frecuente

• βk: proporción máxima de (k-1)-itemsets frecuentes que cumplen condición de join para cada (k-1)-itemset frecuente

Para el caso de Lk, se puede obtener en base a Ck, para todo k: |Lk| = αk. |Ck| , donde:

• αk: proporción de k-itemsets candidatos que son frecuentes Las operaciones involucradas en 1) son:

ops(genL1) = |D||C1|verified-count + verifyFrecuents

Con lo que considerando ambos componentes en la expresión anterior, la cantidad de queda: ops ≤ |I| |GPD| (stapriori-gen + |D| |Ck| verified-count + verifyFrecuents)

Para el caso de 2). la cantidad de operaciones varía según k: |I|. gen1-Itemset , si k=1 ops(stapriori-gen)= (|L1|(|L1|+1)/2)(temporal-prune + ν|P| gen2-Itemset ) ≈ ≈ (|L1|(|L1|+1)/2) ν|P| gen2-Itemset ,si k=2 |L(k-1)JoinMax|.gen-verifk-Itemset |Lk-1| =

= βk |Lk-1|. gen-verifk-Itemset |Lk-1| = βk |Lk-1|

2. gen-verifk-Itemset , si k > 2 Para el caso de 3), el ciclo ya se encuentra representado en la expresión de STApriori. verified-count es una operación aplicada sobre una transacción e itemset candidato: verificar si el candidato se verifica en la transacción, aplicando la definición, e incrementar los contadores correspondientes del candidato. Por último, las operaciones que involucran a 4) son:

ops(verifyFrecuents) = |Ck|.verifyFrecuent Teniendo en cuenta estos, casos la cantidad de operaciones de STApriori se puede expresar como:

ops ≤ |I|gen1-Itemset + (|L1|(|L1|+1)/2). ν|P| gen2-Itemset + (|I| |GPD| - 2) βk |Lk-1|2.

gen-verifk-Itemset + |I| |GPD| |Ck| (|D| verified-count + verifyFrecuent) Reemplazando las expresiones de |L1| y |Lk-1| por las expresiones anteriormente indicadas:


45

ops ≤ |I|gen1-Itemset + (α1|I|( α1|I|+1)/2). ν|P| gen2-Itemset + (|I| |GPD| - 2) βk (αk-1)2 |Ck-1|

2. gen-verifk-Itemset + |I| |GPD| |Ck| (|D| verified-count + verifyFrecuent)

Luego, en vez de tomar valores de |Ck|, βk, αk dependientes según el valor de k, se reemplazan por valores promedio (|C^k|, β^, α^ respectivamente). Considerando esta expresión como el orden de STApriori, donde las operaciones básicas tienen un costo, se puede señalar que la complejidad del algoritmo STApriori esta dada por:

O(|I|Cgen1-Itemset + ((α1|I|(α1|I|+1))/2) ν|P| Cgen2-Itemset + (|I||GPD|-2)(β^)(α^)2|C^k-1|

2

Cgen-verifk-Itemset + |I||GPD||C^k|(|D| . Cverified-count + CverifyFrecuent) ) , donde:

• α1: proporción de 1-itemsets candidatos que son frecuentes • ν: proporción promedio de predicados, respecto a P, que se verifican entre todos los

pares de posiciones geográficas, para cada par de 1-itemsets frecuentes • β^: proporción promedio de (k-1)-itemsets frecuentes que cumplen condición de join

con cada (k-1)-itemset frecuente • α^: proporción promedio de k-itemsets candidatos que son frecuentes • |C^k|: cantidad promedio de k-itemsets candidatos • Cgen1-Itemset: costo en generar un 1-itemset candidato • Cgen2-Itemset: costo en generar un 2-itemset candidato • Cgen-verifk-Itemset: costo en generar y verificar condiciones de un k-itemset candidato

(armado y verificación de condiciones de join y poda) • Cverified-count: costo en verificar en transacción y contabilizar un k-itemset • CverifyFrecuent: costo en verificar si es frecuente un k-itemset contabilizado (incluye costo

de a-posteriori para hallar subintervalos maximales frecuentes dentro del lifespan) De la expresión anterior, los elementos marcados en azul son los determinados en base a los parámetros de entrada. Se puede expresar de manera más simple la expresión considerando solamente estos parámetros de entrada marcados. De esta manera se aproxima a una función más simple, para permitir tener una idea del orden de complejidad de la misma. Teniendo en cuenta esto, en la expresión anterior se pueden identificar 5 términos en la suma, cada uno asociado a su costo correspondiente. Expresando cada termino por su orden de complejidad:

O(|I|. Cgen1-Itemset) + O(|I|2.|P|. Cgen2-Itemset) + O(|I|.|GPD|. Cgen-verifk-Itemset)

+ O(|I|.|GPD|.|D|. Cverified-count) + O(|I|.|GPD|. CverifyFrecuent) Se observa de la expresión dada que el orden que domina la misma es el del 4º término.

O(|I|.|GPD|.|D|. Cverified-count)

El mismo se corresponde con el ciclo de contabilización del algoritmo STApriori. Para finalizar el análisis, es necesario verificar si el costo Cverified-count no depende de los parámetros de entrada. El mismo se puede expresar como:

Cverified-count = Cverified + Ccount

Cverified es el costo de verificar un itemset en la transacción, aplicando la definición del modelo y la estructura de colección de bitmaps, presentadas anteriormente en el capítulo. En base a las mismas, el orden varia según el tamaño del k-itemset -las definiciones se pueden observar escritas en el pseudocódigo dentro de “verifica(Tr,c)”-:


46

• Si k=1, O(|GPD|) • Si k>1, O(|GPD|.(k-1).(|GPD| - 1)) ≈ O(k.|GPD|

2) Siendo el termino mas importante el segundo, el cual es el considerado. Para el caso de Ccount, el mismo es el costo en incrementar los contadores del itemset candidato. El mismo en general es fijo, ya que implica incrementar los atributos del candidato. En el caso de k=1, al actualizarse la lista de posiciones geográficas, se debe considerar el costo como O(|GPD|). Considerando ambos términos:

O(Cverified-count) = O(k.|GPD|2) + O(|GPD|)

El término que domina es el primero. Considerando el mismo es la expresión inicial del orden del 4º término, queda:

O(|I|.|GPD|3.|D|)

Esta expresión señala, de manera general, la complejidad del algoritmo STApriori planteado.

4.1.2. Generación de reglas de asociación espacio-temporales

Para el armado de las reglas de asociación, junto con el algoritmo Apriori, [3] propone el algoritmo Faster Algorithm. El mismo, comentado en el capítulo 2, tiene la ventaja de evitar generar reglas que no tendrán la confianza suficiente, teniendo en cuenta las reglas previamente generadas cuyo consecuente es subitemset del consecuente de las reglas en consideración a generarse. Esto se realiza, para cada itemset frecuente descubierto, mediante una generación por etapas de acuerdo al tamaño del consecuente de las reglas, aplicando la función apriori-gen sobre los consecuentes de la etapa anterior para obtener los consecuentes de las reglas de la etapa actual. Para el armado de las reglas de asociación espacio-temporales propuestas por el modelo, se propone una extensión de este algoritmo, donde se aplican las modificaciones propias del modelo presentado. Las reglas descubiertas se arman en base a los itemsets espacio-temporales frecuentes obtenidos. El componente temporal de los mismos es el lifespan frecuente, pudiendo ser el mismo en caso extremo el lifespan. El componente espacial de los mismos será PredS, que contiene relaciones espaciales relativas a la posición geográfica del item “principal”. Como estas relaciones espaciales pasarán a formar parte de la regla, y serán también relativas al item “principal” de la misma, se decide que este item se encuentre siempre del lado del antecedente de las reglas formadas. Esto evitaría posibles confusiones en interpretar las reglas por parte del usuario. Para el armado de los consecuentes de las nuevas reglas en base a los existentes de las reglas anteriores, en vez de aplicar la función apriori-gen como se propone en [3], se decide aplicar solamente el paso de junta de la misma, sin el de poda. Esto se debe a que los consecuentes considerados, al haber sido descubiertos por el algoritmo STApriori, son frecuentes, con lo cual no son necesarias realizar las validaciones del paso de poda. Además siempre se aplica el paso de junta de la generación de candidatos de tamaño mayor a 2, debido a que todos los consecuentes tienen predicados dentro de su PredS, los cuales son relativos al item principal de la regla; por lo tanto, es necesario considerar los mismos en la generación de nuevos consecuentes. Para el cálculo de la confianza de las reglas es necesario determinar el soporte de la premisa en el intervalo frecuente del itemset que forma la regla, el cual puede ser distinto al intervalo


47

frecuente de la premisa. Para realizar esto, se toman las propuestas de [5] de la siguiente manera: • si el intervalo frecuente del itemset que forma la regla es su lifespan y la premisa

también es frecuente en su lifespan: se calcula suponiendo una distribución temporal uniforme de la premisa en su lifespan, y en particular dentro del lifespan de la regla. De esta manera tendrá el mismo valor al soporte en su propio lifespan.

• si el intervalo frecuente del itemset que forma la regla forma parte de su lifespan frecuente: en este caso existe una mayor diferencia de amplitud entre el intervalo frecuente de la premisa y el del itemset que forma la regla. De esta manera, el soporte de la premisa en los intervalos frecuentes del lifespan frecuente de la regla se estima en base a su histograma.

• si el itemset que forma la regla es frecuente en su lifespan y la premisa en su lifespan frecuente: en este caso la premisa no tiene una distribución temporal uniforme en su lifespan. Para estos casos, se seleccionará el subintervalo frecuente de la premisa que mas solape al lifespan de la regla y se supondrá una distribución temporal uniforme alrededor del mismo. Este intervalo siempre será encontrado debido a que el modelo cumple la Propiedad de Monotonía, planteada en el capítulo anterior. De esta manera, si el itemset que forma la regla se verifica en una transacción de un instante de tiempo t, la premisa de la regla también se verificará en la misma transacción, ya que es un subitemset del itemset que forma la regla. Puede ocurrir que el subintervalo seleccionado no coincida completamente con el lifespan de la regla, debido a la manera en que el algoritmo a-posteriori descubre estos subintervalos, que se basa en la unidad de discretización ∆t dada por el usuario; mientras el lifespan del itemset que forma la regla fue determinado de manera dinámica en cada paso de contabilización del algoritmo STApriori. De esta manera, el soporte de la premisa en el lifespan de la regla será igual al soporte de la misma en el subintervalo seleccionado.

En base al cálculo de confianza en cada uno de los intervalos frecuentes de la regla, se determinan los intervalos que quedaran como parte de la componente temporal de la misma, evaluando los valores calculados respecto al umbral de confianza. Si la regla queda sin intervalos frecuentes dentro de su componente temporal, la misma es eliminada, ya que no supera el umbral de confianza dentro de ninguno de sus intervalos frecuentes.

4.2. Extensión para atributos continuos

Los items con los cuales trabaja el modelo planteado implican el uso de atributos discretos, pero varios de los posibles datasets sobre los cuales se puede aplicar el mismo contienen atributos continuos. Es necesario seleccionar entonces, algún esquema existente para su uso con el modelo. Las reglas de asociación descubiertas a través de datasets que contienen atributos continuos, o atributos con valores numéricos discretos cuyo dominio de valores sea demasiado amplio como para tomar cada valor como un item separado, se denominan reglas de asociación cuantitativas ([34]). Existen varios enfoques para su descubrimiento además del planteado en [34]: [6], [40], [26] son otros trabajos existentes. En general, los esquemas planteados proponen discretizar los atributos continuos para luego aplicar los algoritmos convencionales para el descubrimiento de reglas de asociación booleanas. En el modelo planteado, de la misma manera que en el modelo original, el conjunto de items se puede representar mediante atributos binarios. Cuando se indica que un item pertenece a una transacción con determinada posición geográfica, en realidad lo que se


48

señala es que el atributo correspondiente al item, para la correspondiente posición, dentro de la transacción tiene valor 1. Por otro lado, los items que no se listan como pertenecientes a una transacción en determinada posición, presentan sus atributos, para la posición correspondiente, con valor 0. Teniendo en cuenta lo comentado, en las estructuras de datos a trabajar, cada posición en cada instante de tiempo tiene un conjunto de valores registrados, para cada atributo, por los sensores. Al discretizar estos atributos en base a un esquema seleccionado, cada item pasa a ser una dupla atributo-valor: ik = (an,vnm). Si bien esto afecta al modelo, solo lo hace en la definición de los items y dataset; ya que una vez establecida la correspondencia de un item con una dupla atributo-valor, el modelo se define de igual manera. Luego, a nivel implementación hay que tener en cuenta tres consideraciones: • al ser cada item el valor discreto, o conjunto de valores, de un atributo, para determinar

su pertenencia a una transacción se debe verificar la igualdad de su valor, o la contención del intervalo de discretización, con el del correspondiente valor del atributo dentro de la transacción.

• cada posición geográfica de una transacción contendrá a lo sumo un item para cada atributo manejado en el dataset. En el caso de registrarse en todas las posiciones geográficas valores para todos los atributos, cada transacción pasa a tener una cantidad fija de items; ya que en cada posición geográfica se presenta solamente un item por cada atributo registrado en el dataset original

• en base a lo anterior, para la verificación de los itemsets en las transacciones la estructura de colección de bitmap, comentada en la sección 4.1.1.1, puede ser reemplazada por una colección de arreglos. La longitud de cada arreglo de la misma se determina en base a la cantidad de atributos manejada en el dataset. Y el valor de cada posición de estos arreglos es el del correspondiente item para el atributo de la misma.

En la figura 4.1 se muestra una representación de la estructura de datos considerando el uso de items como duplas atributo-valor.

Figura 4.1. Estructura de datos a manejar utilizando atributos continuos


49

En [6] se descubren reglas de asociación cuantitativa de tipo fuzzy. Para obtener los intervalos se aplica un algoritmo de clustering. Como al mismo se le debe definir la cantidad de clusters a obtener, el esquema general del algoritmo aplica el algoritmo de clustering varias veces, definiendo cada vez un número incremental de la cantidad de clusters a obtener. En los clusters obtenidos en cada pasada se calculan ciertas medidas en base a la interconectividad y cercanía de los clusters, y se selecciona el conjunto de clusters que minimiza esta medida. Cada uno de los clusters descubiertos son conjuntos que pasarán a ser los intervalos de discretización a utilizar, ya que se esta trabajando con una sola dimensión. La principal desventaja de este trabajo es el tener que aplicar el algoritmo de clustering varias veces sobre el conjunto de datos para cada atributo. En [40] los intervalos de discretización se obtienen en base a clusters descubiertos con una red neuronal SOM (Self-Organizing Map). En este caso, se debe indicar previamente la cantidad máxima de intervalos sobre los cuales dividir el atributo a discretizar, ya que este es un parámetro necesario para armar la red. Por último, [26] aplica el algoritmo de clustering BIRCH para la discretización de los datos. Este algoritmo es de tipo adaptativo, con lo cual determina la cantidad de clusters a formar en base a los valores del atributo a discretizar. Para este modelo, se propone seleccionar un esquema basado en el trabajo propuesto por [26]. La idea es seleccionar un algoritmo de clustering de tipo adaptativo para discretizar cada uno de los atributos continuos. Los conjuntos determinados por los clusters descubiertos son los intervalos de discretización, ya que se esta trabajando con una sola dimensión. El uso de un algoritmo de clustering adaptativo permite evitar al usuario determinar la cantidad de intervalos en que se debe discretizar cada atributo. Además, el esquema es conveniente para los atributos continuos ya que determina los intervalos de discretización en base a la distribución de valores de los mismos. En cuanto al algoritmo de clustering a utilizar, se permitirá el uso y selección de los algoritmos ya existentes según el entorno de implementación. De esta manera se permite aprovechar los desarrollos existentes, los cuales ya se encuentran probados y estables.

4.3. Conversión entre estructuras de dataset

En base a la estructura de datos planteada para el modelo, en el capítulo anterior, se pueden identificar dos datasets involucrados en el descubrimiento de la reglas de asociación espacio-temporales: • dataset base: identificado con la letra B. Corresponde al dataset con la estructura de

datos habitual obtenida en el área de aplicación. Se encuentra compuesto por el instante de la medición, los datos geográficos del sensor, y los items registrados por el mismo en el instante actual. En caso de tener atributos con valores continuos se supone que ya se aplico el esquema explicado en la sección anterior. El tamaño de este dataset se encuentra determinado por la cantidad de instantes de medición y la cantidad de sensores (o posiciones geográficas de los mismos) existentes. Además, el tamaño de los registros para este dataset base lo determinan la cantidad de items registrados en cada uno.

• dataset del modelo: se identifica con la letra D. Corresponde al dataset definido para el modelo. Las transacciones que lo componen tienen el formato definido:

( ){ } ( ) { }{ }kjjijjki iyxtyxit ,,,,,, = . El tamaño de este dataset del modelo se encuentra

determinado por la cantidad de instantes de medición. Además, para este caso el tamaño de las transacciones del dataset lo determinan la cantidad de sensores (o


50

posiciones geográficas de los mismos) junto con la cantidad de items registrados para cada uno de los sensores en el instante de tiempo actual.

Teniendo en cuenta las diferencias planteadas entre el dataset posible a obtener como fuente –dataset base B-, y el necesario como entrada para el algoritmo STApriori –dataset del modelo D-, es necesario plantear un algoritmo de preprocesamiento que realice la conversión entre los dos datasets. La principal función de este algoritmo es: dado un dataset base B, procesar los registros del mismos agrupándolos por instantes de medición, para obtener un dataset del modelo D, con las estructura de transacciones que componen al mismo. Para facilitar el funcionamiento del algoritmo se pone como requerimiento sobre el dataset B que los registros se encuentren ordenados por instante de medición.


51

5. Implementación

En este capítulo se describen los detalles de la solución implementada, que permite obtener el modelo planteado en los capítulos anteriores. La implementación se compone de los algoritmos para la obtención del modelo de reglas de asociación espacio-temporales presentado, así como los algoritmos auxiliares necesarios para el preprocesamiento de los datos a ser utilizados por estos algoritmos del modelo. Se explican detalles generales de la estructura desarrollada, junto con el uso de la misma para la obtención del modelo propuesto.

5.1. Solución implementada

Se ha desarrollado una implementación del algoritmo propuesto sobre el sistema Weka [44], la misma es una herramienta para el análisis de datos aplicando tareas de la minería de datos. Se encuentra desarrollada en java, y abarca un conjunto variado de algoritmos para ser utilizados en las tareas de minería de datos: clasificación, clustering, reglas de asociación, visualización. Estos algoritmos pueden ser utilizados desde la interfaz gráfica propia de Weka, o desde otros programas java, como una librería convencional de algoritmos. Debido a su licencia open source GPL (GNU General Public License), se pueden obtener el código fuente de Weka, modificarlo y/o extenderlo. Esto permite utilizar a la herramienta como un entorno adecuado para el desarrollo de nuevos algoritmos, o extensión de los existentes; ya que la misma provee un conjunto apropiado de interfaces y clases para que los nuevos algoritmos desarrollados puedan ser integrados de manera simple con la interfaz gráfica, así como un amplio conjunto de clases utilitarias de ayuda en el desarrollo de estos nuevos algoritmos. Estas clases utilitarias están orientadas a proveer mecanismos comunes para las tareas de minería de datos y el entorno propio de Weka, con lo cual carecen de funcionalidad para el manejo de datos espaciales. Para este propósito se utiliza GeoTools [13], una librería desarrollada en java para la manipulación de datos geoespaciales, utilizada en la implementación de sistemas relacionados con la tecnología de los GIS. Para el caso de la solución implementada, su uso es en el cálculo de las relaciones espaciales entre posiciones geográficas. Weka cuenta con una implementación de los algoritmos Apriori y Faster ([3]) . La misma sirvió de base para el desarrollo de los algoritmos para el descubrimiento de las reglas de asociación espacio-temporales, teniendo en cuenta las modificaciones planteadas, en capítulos anteriores, para el descubrimiento de las componentes espacial y temporal del modelo. Asimismo, Weka provee clases con diferentes algoritmos para el preprocesamiento de las fuentes de datos a analizar, denominados filtros. Siguiendo el mismo esquema, se han desarrollado clases para realizar el preprocesamiento planteado por los algoritmos explicados en el capítulo anterior, junto a otros filtros necesarios en base a los datasets de ejemplo. Además, en los casos que parecieron convenientes, se han utilizado algunos algoritmos ya provistos por Weka. A continuación se explican los diferentes elementos desarrollados y/o utilizados, que permiten obtener el modelo planteado, junto con una referencia de uso de los mismos. Respecto al uso, las clases desarrolladas pueden utilizarse desde la interfaz gráfica propia de Weka, o a través de la línea de comandos. De esta manera, se indica la identificación de los correspondientes parámetros de uso para cada caso.


52

5.2. Obtención de reglas de asociación espacio-temporales

Para la obtención de las reglas de asociación espacio-temporales se encuentra desarrollada la clase SpatioTemporalApriori, la cual se encuentra en Weka en la carpeta spatiotemporal ubicada dentro de associations. La misma implementa el algoritmo STApriori planteado, para el descubrimiento de los itemsets espacio-temporales frecuentes, junto con la extensión al algoritmo Faster ([3]), para el descubrimiento de las reglas de asociación espacio-temporales en base a estos itemsets espacio-temporales frecuentes. El dataset de entrada para el algoritmo debe tener la estructura de datos planteada en los capítulos anteriores –secciones 3.1 y 4.3-. En caso de no cumplir el dataset con todos los elementos de esta estructura, se deben aplicar algunos de los filtros explicados en las secciones siguientes.

5.2.1. Parámetros de uso

La tabla 5.1 indica los parámetros de uso de la clase SpatioTemporalApriori. Se toman en base a los planteados para el algoritmo STApriori –sección 4.1.1.2-, y la extensión del algoritmo Faster –sección 4.1.2-. En caso de que algún parámetro tenga un valor por defecto, el mismo se señala entre paréntesis dentro de la columna “Valor”.

5.2.2. Clases asociadas

Para implementar los algoritmos STApriori y la extensión de Faster, junto con la clase comentada se desarrollaron otras clases, manteniéndose SpatioTemporalApriori como la interfaz de las mismas para el uso de estos algoritmos. Estas clases se corresponden con: • manejo de los elementos de los algoritmos, los itemsets y las reglas de asociación

espacio-temporales • manejo de los predicados espaciales, por ejemplo los de distancia y orientación, así

como el cálculo de los mismos • manejo de la contabilización temporal de las transacciones del dataset

Debido a que estas clases no forman parte de la interfaz de uso de los algoritmos, no se comentan en mayor detalle en esta sección. Mayor información sobre las características de las mismas y su diseño se puede encontrar en el anexo A, dentro de la sección A.2.


53

5.3. Filtros

Los filtros son las clases que implementan los algoritmos de preprocesamiento utilizados para preparar el dataset para que cumpla determinadas características y pueda ser utilizado con los algoritmos de data mining. Los siguientes son los filtros a ser utilizados para obtener una estructura de dataset que pueda ser utilizada con el algoritmo de la sección anterior. La mayoría fueron desarrollados para el uso con este algoritmo, de acuerdo a conceptos

Parámetros

SpatioTemporalApriori Pará-

metros

algorit-

mos

Línea de coman-dos

Interfaz Gráfica Valor Comentario

D t corresponde al dataset en uso actual

dataset Parámetro provisto por las clases de Weka o interfaz gráfica

I Se obtiene en base a información de los atributos del dataset, provista en las clases de Weka

SPC predicateCalculator nombre completo de la clase (weka.associations.spatiotemporal.predicates.DistanceAnglePredicateGeographicCalculator)

P1 component1LimitsAndLabels

P

P2 component2LimitsAndLabels

Formato LIM1[INT1],LIM2[INT2],…LIN

N-1[INTN-1],LIMN , donde LIMi son los extremos de los intervalos e INTi la etiqueta identificatoria de los mismos (0[MC],200[C],500[MED],800[L],1200[ML],INF y -157.5[SO],-112.5[S],-67.5[SE],-22.5[E],22.5[NE],67.5[N],112.5[NO],157.5[O],-157.5)

En base a estos tres parámetros se determina el conjunto de predicados espaciales del algoritmo (cantidad de elementos y tipo de los mismos). Los dos últimos indican los limites de los intervalos de discretización de cada parámetro de los predicados espaciales, junto con sus etiquetas identificatorias (utilizada en la presentación de las reglas resultantes).

σ MS minimumSupport numero entre 0 y 1 (0.65) τ MTS minimunTemporalSu

pport número menor a la amplitud del dataset (10)

∆t THU temporalHistogramUnit

número menor a la amplitud del dataset (5)

TU temporalUnit DAY, … (DAY) Unidad de tiempo de los dos parámetros anteriores

θ MC minimumConfidence numero entre 0 y 1 (0.8) I outputItemsets (false) Muestra los itemsets

descubiertos en la salida del algoritmo

IL logItemsets (false) Envía a archivos de log los itemsets descubiertos en cada iteración, en notación interna para debug

Tabla 5.1. Parámetros de uso del algoritmo para el descubrimiento de las reglas de asociación

espacio-temporales


54

planteados en el capítulo anterior o detalles que fueron apareciendo durante las pruebas con datasets.

5.3.1. Filtros de discretización

La clase SpatioTemporalApriori trabaja con atributos discretos, los cuales representan los items planteados por el modelo. En caso de que el dataset sobre el cual se quieran descubrir las reglas de asociación contenga atributos continuos, se debe aplicar algún filtro de discretización sobre cada uno de los mismos. Para este caso se puede utilizar un filtro desarrollado para utilizar con el modelo, o un filtro provisto por Weka.

5.3.1.1.Filtro de discretización desarrollado

En el capítulo anterior, se planteo la idea de discretizar los atributos continuos utilizando un algoritmo de clustering. Para este propósito, se desarrollo el filtro ClusterDiscretize. El mismo dado un atributo seleccionado y un algoritmo de clustering existente en Weka, aplica este algoritmo de clustering sobre los valores del atributo y luego asigna a cada valor del atributo el cluster correspondiente. Actualmente, el algoritmo de clustering aplicado con mejores resultados fue EM (Expectation Maximisation), que utiliza validación cruzada para determinar el número de clusters; de esta manera no sería necesario determinar la cantidad de clusters –o conjuntos- a dividir un atributo. Además, hay que tener en cuenta que el mismo es el único, provisto por Weka, que facilita información descriptiva de los cluster descubiertos –media y desvío estándar de la distribución normal que modeliza a cada cluster descubierto-, que puede utilizarse para mostrar al usuario en la identificación de los mismos. Para los otros algoritmos de clustering, se identifica a los mismos de manera genérica, mediante un índice incremental.

Parámetros de uso

En la tabla 5.2 se indican los parámetros de uso del filtro ClusterDiscretize. Entre paréntesis dentro de la columna “Valor” se señala el valor por defecto de los parámetros, en los casos que el mismo exista.

Parámetros

ClusterDiscretize Paráme-

tros filtro Línea de coman-dos


dataset filtrar

o corresponde al dataset en uso actual


atributo I attributeIndex índice del atributo (4) algoritmo de clustering

W discretizeClusterer nombre completo de la clase del algoritmo de clustering (weka.clusterers.EM -- -I 100 –N -1 –M 1.0E-6 –S 100)

Por línea de comandos, los parámetros a la misma se indica al final luego de “--“

Tabla 5.2. Parámetros de uso del filtro de discretización de atributos en base a un algoritmo de

clustering


55

5.3.1.2.Filtro de discretización existente en Weka

En el caso que el usuario tenga conocimiento de los datos, y pueda determinar la cantidad de intervalos en los cuales dividir un atributo, se puede utilizar el filtro de discretización provisto por Weka. El mismo se denomina Discretize, y permite discretizar los valores de los atributos continuos en intervalos mediante un esquema de igual ancho o uno de igual frecuencia. En el caso de usar un esquema de igual ancho, se puede indicar el número de intervalos a obtener o pedir que el algoritmo optimice el mismo, en base a una estimación mediante el esquema leave-one-out. En la discretización en igual frecuencia se puede indicar el peso deseado de las instancias por cada intervalo, en vez de la cantidad de intervalos a obtener. Para este caso, el esquema más simple de uso es el de discretización en igual ancho, seleccionando la cantidad de intervalos a obtener. Este valor se puede determinar en base a los resultados obtenidos con el filtro, observando como se distribuye la cantidad de valores en cada intervalo, y verificando que esta cantidad no tome valores que abarquen un porcentaje muy alto o muy bajo respecto al total de valores del atributo. La documentación completa de este filtro puede ser consultada dentro de la documentación javadoc de las clases incluídas en Weka. Esta documentación de Weka, correspondiente a la versión utilizada con la aplicación desarrollada, es provista junto con la aplicación dentro del instalador de la misma.

5.3.2. Filtro para atributos de posiciones geográficas

La implementación del algoritmo para el descubrimiento de los itemsets espacio-temporales frecuentes maneja los componentes de las posiciones geográficas como números reales. De esta manera, si el dataset sobre el cual se quiere descubrir las reglas de asociación contiene posiciones geográficas cuyos componentes de longitud y latitud son campos de texto, se debe aplicar el filtro desarrollado para este caso, denominado DegressToDecimalFormat. Este filtro toma los valores de los atributos correspondientes a las componentes de las posiciones geográficas, de tipo texto con el formato DDºMM’SS’’, y las convierte a un campo de tipo numérico con formato DD,dddd , en donde dddd es la parte decimal de los minutos –MM- y segundos –SS- respecto a los grados DD. Para indicar dentro de los valores de los atributos el hemisferio y/o la latitud, se considera el uso de un signo de orientación delante del valor del atributo correspondiente, siendo negativos el hemisferio O y la latitud S.

Parámetros

DegressToDecimalFormat Paráme-

tros

filtro Línea de coman-dos


dataset a filtrar



atributos C attributesIndexs índice de los atributos, separados por “,” (2,3)

corresponden a los atributos con los componentes de las posiciones geográficas en formato de texto

Tabla 5.3. Parámetros de uso para filtro de conversión de atributos de componentes de

posiciones geográficas


56

5.3.2.1.Parámetros de uso

La tabla 5.3 indica los parámetros de uso del filtro DegressToDecimalFormat. Entre paréntesis dentro de la columna “Valor” se señala el valor por defecto de los parámetros, en los casos correspondientes

5.3.3. Filtro para conversión entre estructuras de datasets

En el capítulo anterior se planteo la necesidad de desarrollar un algoritmo que permita convertir de un dataset B, generalmente dado por el usuario, a un dataset D, utilizado por el modelo. La estructura de este dataset D es la que procesa la implementación del algoritmo para la obtención de las reglas de asociación espacio-temporales (clase SpatioTemporalApriori). Para este caso, se desarrollo el filtro PropositionalToTemporalMultiSpatialInstance. El mismo toma una estructura de datos de la forma (dataset B):

(t1, posX1, posY1, att_val1, att_val2, …, att_valn) (t1, posX2, posY2, att_val1, att_val2, …, att_valn) …. (t1, posXn, posYn, att_val1, att_val2, …, att_valn) … … (tm, posX1, posY1, att_val1, att_val2, …, att_valn) … (tm, posXn, posYn, att_val1, att_val2, …, att_valn)

, y la convierte en la estructura de base de datos de entrada al algoritmo STApriori (dataset D):

(t1, ( (posX1, posY1, att_val1, att_val2, …, att_valn) (posX2, posY2, att_val1, att_val2, …, att_valn) …. (posXn, posYn, att_val1, att_val2, …, att_valn)))

… (tm, ( (posX1, posY1, att_val1, att_val2, …, att_valn)

… (posXn, posYn, att_val1, att_val2, …, att_valn)))

Se observa en este nuevo dataset que cada registro es una transacción compuesta por el instante de tiempo y los items registrados para el mismo. Estos últimos son implementados como un atributo de tipo relacional, que permite mantener un dataset interno como atributo de un registro. En este dataset interno los dos primeros atributos contienen los valores de las componentes de las posiciones geográficas desde donde se registraron los items. Los restantes son los valores de los atributos correspondientes a los items en cada registro del dataset B, registrados en las posiciones anteriores y dentro del instante de tiempo del registro principal (la transacción). Se debe tener en cuenta que, como este dataset resultante sería la entrada del algoritmo implementado en SpatioTemporalApriori, se debería verificar que los componentes de las


57

posiciones geográficas sean números reales, y los atributos restantes se encuentren discretizados. En caso de que esto no ocurra, se pueden utilizar los filtros explicados anteriormente para obtener estas características necesarias.

5.3.3.1.Parámetros de uso

La tabla 5.4 indica los parámetros de uso del filtro PropositionalToTemporalMultiSpatialInstance. Entre paréntesis dentro de la columna “Valor” se señala el valor por defecto de los parámetros, en los casos correspondientes

Parámetros

PropositionalToTemporal-

MultiSpatialInstance Paráme-

tros

filtro Línea de coman-dos

Interfaz Gráfica

Valor Comentario

dataset a filtrar



atributo timestamp

T timestampIndex índice del atributo temporal (1)

atributo posición

P positionIndex índice del primer atributo de los componentes de la posición (2)

Supone los atributos de la posición contiguos (solo se indica el primero).

Tabla 5.4. Parámetros de uso para filtro de conversión entre estructuras de datasets


58

6. Experimentación

En base a la solución implementada descripta en el capítulo anterior, a continuación se muestran los detalles de la experimentación realizada con la misma. Se comienza explicando los casos de aplicación trabajados, junto a otras aplicaciones posibles encontradas. Luego, se pasa a explicar las pruebas de performance y escalabilidad realizadas en base a la implementación desarrollada y los datasets presentados en la primera parte del capítulo. Estas pruebas permiten tener una idea amplia del funcionamiento del algoritmo bajo diferentes configuraciones de datasets y parámetros de uso del mismo.

6.1. Ejemplos de aplicación

6.1.1. Transporte de gas

La solución implementada ha sido aplicada sobre un dataset utilizado en el área del transporte de gas. El mismo contiene mediciones del gas natural transportado a través de determinados gasoductos. Su uso convencional es en el control de la medición física del gas natural en el transporte del mismo a través de gasoductos. Dentro de este uso, uno de los objetivos principales es la verificación de los montos facturados. Los gasoductos de los cuales se obtuvieron las mediciones son: el gasoducto Norte y el Centro Oeste, ambos son propiedad de TGN (Transportadora de Gas del Norte S.A.). Ubicadas a lo largo de estos gasoductos existen estaciones de medición, las cuales miden diferentes variables. Los valores se registran a determinada hora del día como un acumulado de las 24 horas anteriores, con lo cual las mediciones son de tipo diario. Estos datos fueron facilitados por un usuario que trabaja con los mismos, que pertenece al área de Mediciones y Calidad de Gas de TGN. Además de facilitar los datos del caso de ejemplo, este usuario dio explicaciones sobre las características de los mismos, su uso y detalles del dominio de aplicación actual. Estas explicaciones son las que se describen en esta parte del capítulo respecto a características particulares del dataset utilizado. Teniendo en cuenta estas consideraciones, se pueden identificar los registros del dataset base: • instante de tiempo: corresponde a la fecha de las mediciones (conteniendo el

acumulado de la misma) • estación de medición: corresponde al sensor del dataset desde donde se registraron los

items. Los datos utilizados de cada una de estas estaciones son: o código: permite identificar a las estaciones de medición o posición geográfica: los componentes de la misma son longitud y latitud

• items registrados: serán duplas atributo-valor, ya que son conformados por los valores de las variables medidas por las estaciones de medición en el día correspondiente. Los atributos se corresponden con cada una de las variables medidas:

o volume_9300_kcal: caudal de gas de midió la estación o heating_value: poder calorífico del gas o diff_pressure: presión diferencial en el punto de medición o pressure: presión estática o temperature: temperatura del gas medido


59

6.1.1.1.Caso de Ejemplo

Para el caso de ejemplo se seleccionaron las mediciones registradas por 8 estaciones de medición, cuyos códigos son los siguientes: B3390, C2790, C2830, C4145, N1280, N1470, N2380 y P5541. Los valores registrados corresponden a las 365 mediciones de un año. Para este caso, el dataset base contiene un total de 2648 registros. Las variables de medición seleccionadas fueron: volume_9300_kcal, heating_value, pressure y temperature. A continuación se comentan los parámetros seleccionados para la obtención de las reglas de asociación espacio-temporales, junto con la selección de los filtros.

Atributo volume_9300_kcal

Conjuntos de discretización

Distribución normal Nro

Media Desvío Standard Etiqueta de identificación

1 7.9115 5.8097 VOLUME_9300_KCAL_VL 2 24.8078 10.494 VOLUME_9300_KCAL_L 3 335.8984 190.5891 VOLUME_9300_KCAL_ML 4 1091.9509 349.7073 VOLUME_9300_KCAL_MH 5 2004.9664 186.3547 VOLUME_9300_KCAL_H 6 2540.1259 177.6137 VOLUME_9300_KCAL_VH

Atributo heating_value




1 0 4.2148 HEATING_VALUE_VL 2 37.5781 0.0468 HEATING_VALUE_L 3 37.6372 0.1354 HEATING_VALUE_ML 4 38.5669 0.0453 HEATING_VALUE_MH 5 38.805 0.5161 HEATING_VALUE_H 6 38.9553 0.0335 HEATING_VALUE_VH

Atributo pressure




1 4.7256 4.1993 PRESSURE_L 2 20.4961 0.5883 PRESSURE_M 3 56.2126 4.7756 PRESSURE_H

Atributo temperature




1 10.0291 4.8795 TEMPERATURE_L 2 16.0552 1.5274 TEMPERATURE_M 3 24.0677 3.6158 TEMPERATURE_H

Tabla 6.1. Conjuntos de discretización de los atributos del caso de ejemplo del dataset de

transporte de gas


60

Parámetros de uso

Debido a que para el caso del dataset, los componentes de la posición geográfica son tipo texto, se aplica el filtro DegressToDecimalFormat para obtener la longitud y latitud expresadas como números reales. Las columnas seleccionadas fueron las definidas por defecto en el filtro. Para la discretización de los atributos continuos, se utilizo el filtro ClusterDiscretize. El mismo se aplico sobre cada uno de los atributos seleccionados del dataset, utilizando el algoritmo de clustering por defecto: EM, con sus parámetros predefinidos. Considerando esto, cada uno de los atributos se encuentra conformado por los conjuntos de discretización indicados en la tabla 6.1. Los mismos conforman los elementos del conjunto de items I, conteniendo 18 elementos. Para la obtención del dataset del modelo en base a la estructura del dataset obtenida hasta este estado, se aplico el filtro PropositionalToTemporalMultiSpatialInstance, con los parámetros por defecto correspondientes al mismo. De esta manera, el dataset obtenido corresponde al utilizado por el modelo planteado. El mismo se encuentra compuesto de 365 transacciones. En cuanto al algoritmo SpatioTemporalApriori, la tabla 6.2 muestra los parámetros seleccionados para el mismo

Resultados obtenidos

A continuación se muestra un resumen de la salida del algoritmo dada por Weka, mostrando los elementos destacados de la misma. === Run information === Scheme: weka.associations.spatiotemporal.SpatioTemporalApriori -MS 0.9 -MC 0.95 -I -IL -MTS 120.0 -THU 60.0 -TU DAY -SPC weka.associations.spatiotemporal.predicates.DistanceAnglePredicateGeographicCalcula

Parámetros SpatioTemporalApriori Pará-

metros

algorit-

mos

Línea de coman-dos

Interfaz Gráfica Valor

D t corresponde al dataset en uso actual dataset procesado por los filtros comentados I

SPC predicateCalculator default

P1 component1LimitsAndLabels 0[MC],40[C],100[MDC],220[MED],450[MDL],900[L],1800[ML],INF

P

P2 component2LimitsAndLabels default σ MS minimumSupport 0.9 τ MTS minimunTemporalSupport 120 ∆t THU temporalHistogramUnit 60 TU temporalUnit default θ MC minimumConfidence 0.95 I outputItemsets true IL logItemsets true

Tabla 6.2. Parámetros de uso para el algoritmo implementado por SpatioTemporalApriori, en el

caso de ejemplo del dataset de transporte de gas (sección 6.1.1.1)


61

tor -SP1 0[MC],40[C],100[MDC],220[MED],450[MDL],900[L],1800[ML],INF -SP2 -157.5[SO],-112.5[S],-67.5[SE],-22.5[E],22.5[NE],67.5[N],112.5[NO],157.5[O],-157.5 Relation: Multi-ST-Instance-Dataset-weka.filters.unsupervised.attribute.PropositionalToTemporalMultiSpatialInstance-T1-P2 Instances: 365 Attributes: 2 timestamp spatial_items === Associator model (full training set) === Spatio-Temporal Apriori ======================= Parameters ---------- Minimum Support: 0.9 Minimum Temporal Support: 120.0 DAY Minimum Confidence: 0.95 Temporal Histogram Unit: 60.0 DAY Spatial Predicate Calculator: weka.associations.spatiotemporal.predicates.DistanceAnglePredicateGeographicCalculator Spatial Predicates Parameters 1: 0[MC],40[C],100[MDC],220[MED],450[MDL],900[L],1800[ML],INF Spatial Predicates Parameters 2: -157.5[SO],-112.5[S],-67.5[SE],-22.5[E],22.5[NE],67.5[N],112.5[NO],157.5[O],-157.5 Discovered Itemsets shown. Discovered Itemsets reported. Total Summaries ----------------- Frequent Itemsets Discovered: Total: 1296 - Time: 178.954s Spatio-Temporal Association Rules Discovered: Total: 7450 - Time: 0.093s Sets of frequent Itemsets Discovered ----------------------------------- Size of frequent itemsets L(1): 10 - Report File: 20071020182632_L1.txt 1). { volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1) } [ { } ; [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] ] [ 1 ] 2). { volume_9300_kcal = volume_9300_kcal_[ Mean=24.8078; StdDev= 10.494](POS1) } [ { } ; { [Thu May 01 00:00:00 ART 2003; Thu Aug 28 00:00:00 ART 2003] } ] [ { 0.925 } ] ( lifespan = [Wed Jan 22 00:00:00 ART 2003; Sun Nov 23 00:00:00 ART 2003] - [ 0.4346 ] ) 3). { heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS1) } [ { } ; { [Thu May 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9102 } ] ( lifespan = [Fri Jan 03 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] - [ 0.876 ] ) ... Size of frequent itemsets L(2): 145 - Report File: 20071020182632_L2.txt 1). { volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), volume_9300_kcal = volume_9300_kcal_[ Mean=24.8078; StdDev= 10.494](POS2) } [ { DISTANCE_C-ORIENTATION_O(POS1,POS2) } ; { [Thu May 01 00:00:00 ART 2003; Thu Aug 28 00:00:00 ART 2003] } ] [ { 0.925 } ] ( lifespan = [Thu Apr 17 00:00:00 ART 2003; Tue Nov 04 00:00:00 ART 2003] - [ 0.5941 ] )


62

2). { volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), volume_9300_kcal = volume_9300_kcal_[ Mean=24.8078; StdDev= 10.494](POS2) } [ { DISTANCE_MDC-ORIENTATION_S(POS1,POS2) } ; { [Thu May 01 00:00:00 ART 2003; Thu Aug 28 00:00:00 ART 2003] } ] [ { 0.925 } ] ( lifespan = [Thu Apr 17 00:00:00 ART 2003; Tue Nov 04 00:00:00 ART 2003] - [ 0.5941 ] ) ... Size of frequent itemsets L(6): 56 - Report File: 20071020182632_L6.txt 1). { volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), volume_9300_kcal = volume_9300_kcal_[ Mean=24.8078; StdDev= 10.494](POS2), pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS3), pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS4), pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS5), temperature = temperature_[ Mean=16.0552; StdDev= 1.5274](POS6) } [ { DISTANCE_C-ORIENTATION_O(POS1,POS2), DISTANCE_MDL-ORIENTATION_O(POS1,POS3), DISTANCE_MDC-ORIENTATION_NO(POS1,POS4), DISTANCE_MED-ORIENTATION_SE(POS1,POS5), DISTANCE_MDL-ORIENTATION_N(POS1,POS6) } ; { [Thu May 01 00:00:00 ART 2003; Thu Aug 28 00:00:00 ART 2003] } ] [ { 0.925 } ] ( lifespan = [Thu Apr 17 00:00:00 ART 2003; Tue Nov 04 00:00:00 ART 2003] - [ 0.5941 ] ) 2). { volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), volume_9300_kcal = volume_9300_kcal_[ Mean=24.8078; StdDev= 10.494](POS2), pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS3), pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS4), pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS5), temperature = temperature_[ Mean=16.0552; StdDev= 1.5274](POS6) } [ { DISTANCE_C-ORIENTATION_O(POS1,POS2), DISTANCE_MDL-ORIENTATION_O(POS1,POS3), DISTANCE_MDC-ORIENTATION_NO(POS1,POS4), DISTANCE_MDL-ORIENTATION_NO(POS1,POS5), DISTANCE_MDL-ORIENTATION_N(POS1,POS6) } ; { [Thu May 01 00:00:00 ART 2003; Thu Aug 28 00:00:00 ART 2003] } ] [ { 0.925 } ] ( lifespan = [Thu Apr 17 00:00:00 ART 2003; Tue Nov 04 00:00:00 ART 2003] - [ 0.5941 ] ) ... Spatio-Temporal Association Rules Discovered -------------------------------------------- 1). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1) ===> heating_value = heating_value_[ Mean=38.5669; StdDev= 0.0453](POS2) [ { DISTANCE_MDC-ORIENTATION_NO(POS1,POS2) }; { [Mon Jun 30 00:00:00 ART 2003; Mon Oct 27 00:00:00 ART 2003] } ] [ { 0.95 }; { 0.95 } ] 2). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1) ===> heating_value = heating_value_[ Mean=38.5669; StdDev= 0.0453](POS2) [ { DISTANCE_MED-ORIENTATION_S(POS1,POS2) }; { [Mon Jun 30 00:00:00 ART 2003; Mon Oct 27 00:00:00 ART 2003] } ] [ { 0.9583 }; { 0.9583 } ] 3). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1) ===> heating_value = heating_value_[ Mean=38.5669; StdDev= 0.0453](POS2) [ { DISTANCE_MDL-ORIENTATION_S(POS1,POS2) }; { [Mon Jun 30 00:00:00 ART 2003; Mon Oct 27 00:00:00 ART 2003] } ] [ { 0.95 }; { 0.95 } ] ... 11). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) [ { DISTANCE_C-ORIENTATION_E(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Apr 30 00:00:00 ART 2003] } ] [ { 0.9917 }; { 0.9917 } ]


63

12). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) [ { DISTANCE_MDC-ORIENTATION_N(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Apr 30 00:00:00 ART 2003] } ] [ { 0.9917 }; { 0.9917 } ] 13). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) [ { DISTANCE_MDC-ORIENTATION_NO(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] 14). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) [ { DISTANCE_MDL-ORIENTATION_S(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] 15). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) [ { DISTANCE_MDL-ORIENTATION_N(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] .... 34). volume_9300_kcal = volume_9300_kcal_[ Mean=24.8078; StdDev= 10.494](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) [ { DISTANCE_C-ORIENTATION_E(POS1,POS2) }; { [Thu May 01 00:00:00 ART 2003; Thu Aug 28 00:00:00 ART 2003] } ] [ { 0.925 }; { 1 } ] 35). volume_9300_kcal = volume_9300_kcal_[ Mean=24.8078; StdDev= 10.494](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) [ { DISTANCE_MDC-ORIENTATION_N(POS1,POS2) }; { [Thu May 01 00:00:00 ART 2003; Thu Aug 28 00:00:00 ART 2003] } ] [ { 0.925 }; { 1 } ] 36). volume_9300_kcal = volume_9300_kcal_[ Mean=24.8078; StdDev= 10.494](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) [ { DISTANCE_MDL-ORIENTATION_N(POS1,POS2) }; { [Thu May 01 00:00:00 ART 2003; Thu Aug 28 00:00:00 ART 2003] } ] [ { 0.925 }; { 1 } ] ... 43). heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) [ { DISTANCE_C-ORIENTATION_E(POS1,POS2) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9135 }; { 0.9883 } ] 44). heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) [ { DISTANCE_MDC-ORIENTATION_N(POS1,POS2) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9135 }; { 0.9883 } ] 45). heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) [ { DISTANCE_MDC-ORIENTATION_NO(POS1,POS2) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9135 }; { 0.9883 } ] 46). heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) [ { DISTANCE_MED-ORIENTATION_NE(POS1,POS2) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ]


64

[ { 0.9027 }; { 0.9766 } ] 47). heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) [ { DISTANCE_MDL-ORIENTATION_E(POS1,POS2) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9027 }; { 0.9766 } ] 48). heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) [ { DISTANCE_MDL-ORIENTATION_N(POS1,POS2) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9135 }; { 0.9883 } ] 49). heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) [ { DISTANCE_L-ORIENTATION_N(POS1,POS2) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9027 }; { 0.9766 } ] ... 59). heating_value = heating_value_[ Mean=38.5669; StdDev= 0.0453](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) [ { DISTANCE_MDL-ORIENTATION_N(POS1,POS2) }; { [Mon Jun 30 00:00:00 ART 2003; Mon Oct 27 00:00:00 ART 2003] } ] [ { 0.95 }; { 0.9661 } ] ... 73). pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS1) ===> temperature = temperature_[ Mean=24.0677; StdDev= 3.6158](POS2) [ { DISTANCE_MED-ORIENTATION_E(POS1,POS2) }; { [Fri Aug 29 00:00:00 ART 2003; Sun Dec 28 00:00:00 ART 2003] } ] [ { 0.96 }; { 0.96 } ] ... 105). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), volume_9300_kcal = volume_9300_kcal_[ Mean=24.8078; StdDev= 10.494](POS2) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS3) [ { DISTANCE_C-ORIENTATION_O(POS1,POS2), DISTANCE_MDC-ORIENTATION_NO(POS1,POS3) }; { [Thu May 01 00:00:00 ART 2003; Thu Aug 28 00:00:00 ART 2003] } ] [ { 0.925 }; { 1 } ] 106). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), volume_9300_kcal = volume_9300_kcal_[ Mean=24.8078; StdDev= 10.494](POS2) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS3) [ { DISTANCE_C-ORIENTATION_O(POS1,POS2), DISTANCE_MDL-ORIENTATION_N(POS1,POS3) }; { [Thu May 01 00:00:00 ART 2003; Thu Aug 28 00:00:00 ART 2003] } ] [ { 0.925 }; { 1 } ] ... 121). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS2) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS3) [ { DISTANCE_MDC-ORIENTATION_S(POS1,POS2), DISTANCE_MDL-ORIENTATION_N(POS1,POS3) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9135 }; { 1 } ] 122). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS2) ===> pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS3) [ { DISTANCE_MDC-ORIENTATION_S(POS1,POS2), DISTANCE_MED-ORIENTATION_N(POS1,POS3) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9135 }; { 1 } ]


65

123). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS2) ===> pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS3) [ { DISTANCE_MDC-ORIENTATION_S(POS1,POS2), DISTANCE_MDL-ORIENTATION_SE(POS1,POS3) }; { [Mon Jun 30 00:00:00 ART 2003; Mon Oct 27 00:00:00 ART 2003] } ] [ { 0.9 }; { 1 } ] ... 127). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS2) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS3) [ { DISTANCE_MDC-ORIENTATION_SE(POS1,POS2), DISTANCE_MDL-ORIENTATION_N(POS1,POS3) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9135 }; { 1 } ] 128). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS2) ===> pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS3) [ { DISTANCE_MDC-ORIENTATION_SE(POS1,POS2), DISTANCE_MED-ORIENTATION_N(POS1,POS3) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9135 }; { 1 } ] 129). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS2) ===> pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS3) [ { DISTANCE_MDC-ORIENTATION_SE(POS1,POS2), DISTANCE_MDL-ORIENTATION_SE(POS1,POS3) }; { [Mon Jun 30 00:00:00 ART 2003; Mon Oct 27 00:00:00 ART 2003] } ] [ { 0.9 }; { 1 } ] ... 132). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS2) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS3) [ { DISTANCE_MED-ORIENTATION_SO(POS1,POS2), DISTANCE_MDL-ORIENTATION_N(POS1,POS3) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9027 }; { 1 } ] 133). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS2) ===> pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS3) [ { DISTANCE_MED-ORIENTATION_SO(POS1,POS2), DISTANCE_MED-ORIENTATION_N(POS1,POS3) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9027 }; { 1 } ] 134). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS2) ===> pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS3) [ { DISTANCE_MED-ORIENTATION_SO(POS1,POS2), DISTANCE_MDL-ORIENTATION_SE(POS1,POS3) }; { [Mon Jun 30 00:00:00 ART 2003; Mon Oct 27 00:00:00 ART 2003] } ] [ { 0.9 }; { 1 } ] ... 138). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS2) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS3) [ { DISTANCE_MDL-ORIENTATION_S(POS1,POS2), DISTANCE_MDL-ORIENTATION_S(POS1,POS3) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9135 }; { 1 } ]


66

139). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS2) ===> pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS3) [ { DISTANCE_MDL-ORIENTATION_S(POS1,POS2), DISTANCE_MED-ORIENTATION_S(POS1,POS3) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9135 }; { 1 } ] 140). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS2) ===> pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS3) [ { DISTANCE_MDL-ORIENTATION_S(POS1,POS2), DISTANCE_L-ORIENTATION_SE(POS1,POS3) }; { [Mon Jun 30 00:00:00 ART 2003; Mon Oct 27 00:00:00 ART 2003] } ] [ { 0.9 }; { 1 } ] ... 142). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS2) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS3) [ { DISTANCE_L-ORIENTATION_S(POS1,POS2), DISTANCE_MDL-ORIENTATION_S(POS1,POS3) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9027 }; { 1 } ] 143). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS2) ===> pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS3) [ { DISTANCE_L-ORIENTATION_S(POS1,POS2), DISTANCE_MED-ORIENTATION_S(POS1,POS3) }; { [Mon Jun 30 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9027 }; { 1 } ] 144). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), heating_value = heating_value_[ Mean=37.5781; StdDev= 0.0468](POS2) ===> pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS3) [ { DISTANCE_L-ORIENTATION_S(POS1,POS2), DISTANCE_L-ORIENTATION_SE(POS1,POS3) }; { [Mon Jun 30 00:00:00 ART 2003; Mon Oct 27 00:00:00 ART 2003] } ] [ { 0.9 }; { 1 } ] ... 212). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS2) ===> temperature = temperature_[ Mean=24.0677; StdDev= 3.6158](POS3) [ { DISTANCE_MDC-ORIENTATION_S(POS1,POS2), DISTANCE_MDC-ORIENTATION_S(POS1,POS3) }; { [Fri Aug 29 00:00:00 ART 2003; Sun Dec 28 00:00:00 ART 2003] } ] [ { 0.952 }; { 0.9754 } ] 213). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1) ===> pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS2), temperature = temperature_[ Mean=24.0677; StdDev= 3.6158](POS3) [ { DISTANCE_MDC-ORIENTATION_S(POS1,POS2), DISTANCE_MDC-ORIENTATION_S(POS1,POS3) }; { [Fri Aug 29 00:00:00 ART 2003; Sun Dec 28 00:00:00 ART 2003] } ] [ { 0.952 }; { 0.952 } ] ... 228). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS2) ===> temperature = temperature_[ Mean=24.0677; StdDev= 3.6158](POS3) [ { DISTANCE_MED-ORIENTATION_SO(POS1,POS2), DISTANCE_MDC-ORIENTATION_S(POS1,POS3) }; { [Fri Aug 29 00:00:00 ART 2003; Sun Dec 28 00:00:00 ART 2003] } ] [ { 0.952 }; { 0.952 } ] ...


67

231). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS2) ===> temperature = temperature_[ Mean=24.0677; StdDev= 3.6158](POS3) [ { DISTANCE_MED-ORIENTATION_SO(POS1,POS2), DISTANCE_MED-ORIENTATION_SO(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Apr 30 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] 232). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1) ===> pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS2), temperature = temperature_[ Mean=24.0677; StdDev= 3.6158](POS3) [ { DISTANCE_MED-ORIENTATION_SO(POS1,POS2), DISTANCE_MED-ORIENTATION_SO(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Apr 30 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] ... 271). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS2) ===> temperature = temperature_[ Mean=24.0677; StdDev= 3.6158](POS3) [ { DISTANCE_MDL-ORIENTATION_SO(POS1,POS2), DISTANCE_MDL-ORIENTATION_S(POS1,POS3) }; { [Fri Aug 29 00:00:00 ART 2003; Sun Dec 28 00:00:00 ART 2003] } ] [ { 0.912 }; { 0.95 } ] ... 286). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS2) ===> temperature = temperature_[ Mean=24.0677; StdDev= 3.6158](POS3) [ { DISTANCE_MDL-ORIENTATION_S(POS1,POS2), DISTANCE_MDL-ORIENTATION_S(POS1,POS3) }; { [Fri Aug 29 00:00:00 ART 2003; Sun Dec 28 00:00:00 ART 2003] } ] [ { 0.952 }; { 0.9754 } ] ... 306). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS2) ===> temperature = temperature_[ Mean=24.0677; StdDev= 3.6158](POS3) [ { DISTANCE_MDL-ORIENTATION_O(POS1,POS2), DISTANCE_MDL-ORIENTATION_O(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Apr 30 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] ... 324). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS2) ===> temperature = temperature_[ Mean=24.0677; StdDev= 3.6158](POS3) [ { DISTANCE_L-ORIENTATION_S(POS1,POS2), DISTANCE_L-ORIENTATION_S(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Apr 30 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] ... 338). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), temperature = temperature_[ Mean=16.0552; StdDev= 1.5274](POS2) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS3) [ { DISTANCE_MDL-ORIENTATION_N(POS1,POS2), DISTANCE_C-ORIENTATION_E(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Apr 30 00:00:00 ART 2003] } ] [ { 0.9917 }; { 0.9917 } ] ... 347). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), temperature = temperature_[ Mean=10.0291; StdDev= 4.8795](POS2) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS3)


68

[ { DISTANCE_MDC-ORIENTATION_N(POS1,POS2), DISTANCE_MDC-ORIENTATION_N(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Apr 30 00:00:00 ART 2003] } ] [ { 0.9917 }; { 1 } ] ... 350). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), temperature = temperature_[ Mean=16.0552; StdDev= 1.5274](POS2) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS3) [ { DISTANCE_MDL-ORIENTATION_N(POS1,POS2), DISTANCE_MDC-ORIENTATION_N(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Apr 30 00:00:00 ART 2003] } ] [ { 0.9917 }; { 0.9917 } ] .... 510). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), temperature = temperature_[ Mean=16.0552; StdDev= 1.5274](POS2) ===> pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS3) [ { DISTANCE_MDL-ORIENTATION_S(POS1,POS2), DISTANCE_L-ORIENTATION_SE(POS1,POS3) }; { [Thu May 01 00:00:00 ART 2003; Thu Aug 28 00:00:00 ART 2003] } ] [ { 0.95 }; { 1 } ] ... 1000). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), volume_9300_kcal = volume_9300_kcal_[ Mean=24.8078; StdDev= 10.494](POS2), pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS3) ===> pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS4) [ { DISTANCE_C-ORIENTATION_O(POS1,POS2), DISTANCE_MDL-ORIENTATION_O(POS1,POS3), DISTANCE_MED-ORIENTATION_SE(POS1,POS4) }; { [Thu May 01 00:00:00 ART 2003; Thu Aug 28 00:00:00 ART 2003] } ] [ { 0.925 }; { 1 } ] 1001). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), volume_9300_kcal = volume_9300_kcal_[ Mean=24.8078; StdDev= 10.494](POS2) ===> pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS3), pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS4) [ { DISTANCE_C-ORIENTATION_O(POS1,POS2), DISTANCE_MDL-ORIENTATION_O(POS1,POS3), DISTANCE_MED-ORIENTATION_SE(POS1,POS4) }; { [Thu May 01 00:00:00 ART 2003; Thu Aug 28 00:00:00 ART 2003] } ] [ { 0.925 }; { 1 } ] .... 1535). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS2), pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS3) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS4) [ { DISTANCE_MED-ORIENTATION_SO(POS1,POS2), DISTANCE_MED-ORIENTATION_N(POS1,POS3), DISTANCE_MDL-ORIENTATION_N(POS1,POS4) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] .... 2600). volume_9300_kcal = volume_9300_kcal_[ Mean=24.8078; StdDev= 10.494](POS1) ===> pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS2), pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS3), temperature = temperature_[ Mean=16.0552; StdDev= 1.5274](POS4) [ { DISTANCE_MED-ORIENTATION_O(POS1,POS2), DISTANCE_MDC-ORIENTATION_N(POS1,POS3), DISTANCE_MDL-ORIENTATION_N(POS1,POS4) }; { [Thu May 01 00:00:00 ART 2003; Thu Aug 28 00:00:00 ART 2003] } ] [ { 0.925 }; { 1 } ] 2601). volume_9300_kcal = volume_9300_kcal_[ Mean=24.8078; StdDev= 10.494](POS1), pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2), pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS3) ===> pressure = pressure_[ Mean=56.2126; StdDev= 4.7756](POS4)


69

[ { DISTANCE_MDL-ORIENTATION_N(POS1,POS2), DISTANCE_MED-ORIENTATION_E(POS1,POS3), DISTANCE_MED-ORIENTATION_O(POS1,POS4) }; { [Thu May 01 00:00:00 ART 2003; Thu Aug 28 00:00:00 ART 2003] } ] [ { 0.925 }; { 1 } ] ... 6200). pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS1), pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS2), temperature = temperature_[ Mean=10.0291; StdDev= 4.8795](POS3), temperature = temperature_[ Mean=24.0677; StdDev= 3.6158](POS4) ===> temperature = temperature_[ Mean=16.0552; StdDev= 1.5274](POS5) [ { DISTANCE_MED-ORIENTATION_SE(POS1,POS2), DISTANCE_MDC-ORIENTATION_NO(POS1,POS3), DISTANCE_MDL-ORIENTATION_O(POS1,POS4), DISTANCE_MDL-ORIENTATION_N(POS1,POS5) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Apr 30 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] 6201). pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS1), temperature = temperature_[ Mean=24.0677; StdDev= 3.6158](POS2), temperature = temperature_[ Mean=16.0552; StdDev= 1.5274](POS3) ===> pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS4), temperature = temperature_[ Mean=10.0291; StdDev= 4.8795](POS5) [ { DISTANCE_MDL-ORIENTATION_O(POS1,POS2), DISTANCE_MDL-ORIENTATION_N(POS1,POS3), DISTANCE_MED-ORIENTATION_SE(POS1,POS4), DISTANCE_MDC-ORIENTATION_NO(POS1,POS5) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Apr 30 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] ... 7448). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS2) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS3), temperature = temperature_[ Mean=10.0291; StdDev= 4.8795](POS4), temperature = temperature_[ Mean=24.0677; StdDev= 3.6158](POS5), temperature = temperature_[ Mean=16.0552; StdDev= 1.5274](POS6) [ { DISTANCE_MDL-ORIENTATION_NO(POS1,POS2), DISTANCE_MDL-ORIENTATION_N(POS1,POS3), DISTANCE_MDC-ORIENTATION_NO(POS1,POS4), DISTANCE_MDL-ORIENTATION_O(POS1,POS5), DISTANCE_MDL-ORIENTATION_N(POS1,POS6) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Apr 30 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] 7449). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1), pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2) ===> pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS3), temperature = temperature_[ Mean=10.0291; StdDev= 4.8795](POS4), temperature = temperature_[ Mean=24.0677; StdDev= 3.6158](POS5), temperature = temperature_[ Mean=16.0552; StdDev= 1.5274](POS6) [ { DISTANCE_MDL-ORIENTATION_N(POS1,POS2), DISTANCE_MDL-ORIENTATION_NO(POS1,POS3), DISTANCE_MDC-ORIENTATION_NO(POS1,POS4), DISTANCE_MDL-ORIENTATION_O(POS1,POS5), DISTANCE_MDL-ORIENTATION_N(POS1,POS6) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Apr 30 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] 7450). volume_9300_kcal = volume_9300_kcal_[ Mean=7.9115; StdDev= 5.8097](POS1) ===> pressure = pressure_[ Mean=4.7256; StdDev= 4.1993](POS2), pressure = pressure_[ Mean=20.4961; StdDev= 0.5883](POS3), temperature = temperature_[ Mean=10.0291; StdDev= 4.8795](POS4), temperature = temperature_[ Mean=24.0677; StdDev= 3.6158](POS5), temperature = temperature_[ Mean=16.0552; StdDev= 1.5274](POS6) [ { DISTANCE_MDL-ORIENTATION_N(POS1,POS2), DISTANCE_MDL-ORIENTATION_NO(POS1,POS3), DISTANCE_MDC-ORIENTATION_NO(POS1,POS4), DISTANCE_MDL-ORIENTATION_O(POS1,POS5), DISTANCE_MDL-ORIENTATION_N(POS1,POS6) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Apr 30 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ]


70

En primer lugar se observa la sección “=== Run information ===”, la cual es provista de manera predeterminada por Weka. La misma contiene las características del dataset utilizado, así como los parámetros de llamada a la clase correspondiente al algoritmo. Luego, en la sección “=== Associator model (full training set) ===” se muestra el resultado del modelo obtenido por el algoritmo. Bajo el título “Parameters” se muestran los parámetros dados al algoritmo, utilizando una descripción un poco mas completa de los mismos. A continuación, en “Total Summaries” se muestra un resumen del modelo descubierto por el algoritmo. En este caso, el algoritmo para el descubrimiento de los itemsets frecuentes tardo 178.954 segundos en descubrir 1296 itemsets frecuentes. En base a los mismos, se obtuvieron 7450 reglas de asociación espacio-temporales, demorando 0.093 segundos en el armado de las mismas. A continuación, “Sets of frequent Itemsets Discovered” muestra los itemsets frecuentes descubiertos. En caso de señalarse al algoritmo que no se muestren los mismos, solamente se muestra un resumen de la cantidad de itemsets frecuentes obtenidos de cada tamaño. Por último, en la sección “Spatio-Temporal Association Rules Discovered”, se muestran las reglas de asociación espacio-temporales descubiertas para el dataset dado con los parámetros definidos. En base a las reglas obtenidas, se pueden observar algunas de probable utilidad para el usuario, según los detalles del dominio de aplicación actual de los datos aportado por el mismo. En primer lugar, la regla 73 muestra una relación entre un valor “alto” de presión y otro “alto” de temperatura. Se puede señalar que un valor “alto” para la variable temperatura puede ser una consideración de seguridad a tener en cuenta por el usuario. Si bien debido a las características del modelo, una misma relación entre dos o más items -combinación variable medida y valor- se puede repetir entre varias reglas, siempre y cuando cada una contenga conjuntos de predicados espaciales distintos, para este caso la regla señalada se observa con un solo caso de relación espacial. Teniendo en cuenta que el gas se transfiere elevándolo a presiones altas, se puede prestar atención a la relación espacial mostrada por la regla en los casos que sea necesario tener en cuenta la seguridad del gasoducto en base a la transferencia del gas. Si a la relación indicada se agrega “volumen muy bajo” en su antecedente, la misma ocurre con varios conjuntos de predicados espaciales, en las reglas 212, 228, 231, 271, 286, 306 y 324. En estos casos, las relaciones espaciales, respecto a la posición geográfica de los valores medidos de volumen, son similares; con lo cual se puede inferir que la relación espacial entre presión y temperatura tendrá una distancia cercana. De esta manera, estos casos se corresponderían con uno provisto por otra regla distinta de la anterior, ya que esta última contenía una relación espacial con predicado con distancia media. Otro caso a tener en cuenta son las reglas cuyo consecuente contiene un valor “bajo” de presión. Debido a que el gas se transfiere sometiéndolo a presiones altas, un valor bajo registrado para esta variable puede representar un tramo del gasoducto a tener en cuenta como problemático respecto a la transferencia de gas. Para el caso de relacionar un valor “muy bajo” de volumen con uno “bajo” de presión, las reglas se observan con 5 predicados espaciales dentro el dataset, correspondientes a las reglas 11 a 15. Si se aumenta el valor de volumen a “bajo” la regla ocurre con menor cantidad de predicados espaciales: 34 a 36. Además, el periodo de tiempo en que se observa la misma se reduce a 4 meses, en la mayoría de los casos –en los otros varía el cuatrimestre-. Por otro lado, si se cambia en el antecedente el volumen por un valor de poder calorífico “medio alto”, la regla ocurre en un solo caso: 59. Si se compara esta regla con otras que puedan contener un valor “bajo” de poder calorífico, se observan 6 casos: reglas 43 a 49. Con


71

lo cual la regla del primer tipo se destaca por presentar un solo caso de relación espacial donde se observa una relación del valor medido de poder calorífico con un posible problema en la transferencia del gas. Las reglas 105 y 106 son ejemplos donde el valor de presión “bajo” depende de valores bajos del volumen de gas transferido. En caso de ser necesaria una relación de valores bajos de presión con valores de volumen y temperatura, se pueden observar reglas para representar distintos valores de estas últimas variables. Si la temperatura toma valor “bajo”, se observa la regla 347. En cambio, para valores “medios” de temperatura, se pueden indicar las reglas 338 y 350. Como último ejemplo de reglas con valor de presión “bajo” en su consecuente, se puede señalar la regla 1535, la cual se encuentra compuesta por 4 items. En la misma se observa, arrancando desde un valor “muy bajo” de volumen, la disminución de los valores registrados de presión, a medida que la relación espacial se orienta al norte y aumenta su distancia. De esta manera, se puede considerar como un patrón de relaciones espaciales que señalan la disminución de los valores de presión registrados. Como último, se puede destacar las reglas que tienen como antecedente valores “muy bajo” de volumen y “bajo” de poder calorífico. Considerando que el producto de estas dos variables mide la energía transferida, las reglas observadas pueden llegar a relacionar un valor bajo de energía con otras variables. Como primer caso, se puede indicar las reglas que se relacionan también con un valor bajo de presión: 121, 127, 132, 138 y 142. Estas reglas permiten relacionar a la energía con problemas en la transferencia del gas. Junto a estas reglas señaladas se observan otro grupo de reglas más amplio que tienen como consecuente un valor de presión “medio”: 122, 123, 128, 129, 133, 134, 139, 140, 143 y 144. Con lo cual, para este otro tipo de reglas señalas, la relación se observa en una mayor cantidad de casos dentro del dataset, ya que ocurre con una mayor cantidad de relaciones espaciales. Las reglas anteriores se señalaron debido a que se destacaron en su utilidad de uso para el usuario, en base al conocimiento aportado por el mismo respecto al dominio de aplicación actual de los datos. Debido al volumen de reglas obtenido, es probable que se puedan llegar a hallar mayor cantidad de reglas con una utilidad destacada dentro de los resultados provistos por el algoritmo. Este descubrimiento de información útil en base a los resultados obtenidos se va mejorando a medida que el usuario adquiere mayor conocimiento de los resultados provistos por el algoritmo –como herramienta-. También puede llegar a facilitarse con el uso de aplicaciones de postprocesamiento de los resultados obtenidos, en base a determinadas necesidades del usuario.

6.1.1.2.Caso de ejemplo alternativo

En esta sección se aplica otro caso de ejemplo alternativo sobre el mismo tipo de dataset, para mostrar el funcionamiento de la solución implementada con otra configuración de parámetros. El caso se aplica sobre otro conjunto de estaciones de medición, compuesto por 5 elementos: N1200, C1100, C4080, P5100 y P5020. Los valores registrados corresponden también a las mediciones de todo un año, conteniendo el dataset base un total de 1825 registros. Se seleccionaron todas las variables de medición disponibles en el dataset.

Parámetros de uso


72

En cuanto a los filtros aplicados al dataset para poder obtener el dataset del modelo sobre el cual descubrir las reglas de asociación, se cambió el filtro de discretización aplicado. En este caso se seleccionó el filtro Discretize, provisto por Weka, como alternativa disponible para el manejo de atributos continuos. El esquema de discretización fue de igual ancho, seleccionando la cantidad de intervalos de discretización a obtener para cada atributo del dataset. Para seleccionar la cantidad de intervalos de discretización a utilizar, se fueron probando valores contiguos de la cantidad de intervalos a obtener y se observaron los intervalos obtenidos hasta alcanzar un conjunto de intervalos aceptable. El mismo era aquel donde no existían intervalos con un tamaño demasiado pequeño respecto a la cantidad de


Intervalos de discretización

Intervalo Nro

mínimo máximo Etiqueta de identificación

1 -∞ 452.349152 VOLUME_9300_KCAL_VL 2 452.349152 904.633293 VOLUME_9300_KCAL_L 3 904.633293 1356.917435 VOLUME_9300_KCAL_M 4 1356.917435 1809.201576 VOLUME_9300_KCAL_H 5 1809.201576 ∞ VOLUME_9300_KCAL_VH



Intervalo Nro


1 -∞ 38.239382 HEATING_VALUE_L 2 38.239382 39.301984 HEATING_VALUE_M 3 39.301984 ∞ HEATING_VALUE_H

Atributo diff_pressure


Intervalo Nro


1 -∞ 0.216833 DIFF_PRESSURE_L 2 0.216833 0.433667 DIFF_PRESSURE_M 3 0.433667 ∞ DIFF_PRESSURE_H

Atributo pressure


Intervalo Nro


1 -∞ 15.947004 PRESSURE_L 2 15.947004 31.894007 PRESSURE_ML 3 31.894007 47.84101 PRESSURE_MH 4 47.84101 ∞ PRESSURE_H



Intervalo Nro


1 -∞ 3.276892 TEMPERATURE_VL 2 3.276892 10.557669 TEMPERATURE_L 3 10.557669 17.838447 TEMPERATURE_M 4 17.838447 25.119224 TEMPERATURE_H 5 25.119224 ∞ TEMPERATURE_VH

Tabla 6.3. Intervalos de discretización de los atributos del caso de ejemplo alternativo del

dataset de transporte de gas


73

valores del atributo, o el tamaño entre todos intervalos no era extremadamente desigual. La cantidad de intervalos de partida se tomo en base a la seleccionada en el caso de ejemplo anterior por el algoritmo de clustering del filtro ClusterDiscretize. En la tabla 6.3 se muestran los intervalos obtenidos. Estos intervalos, tomados como duplas atributo-valor, conforman el conjunto de items I, con 20 elementos. Para los otros dos filtros, los parámetros fueron los mismos que en el caso anterior. De esta manera, el dataset resultante quedo con 365 transacciones. Respecto a los parámetros del algoritmo SpatioTemporalApriori, se cambiaron los límites de los intervalos de discretización de los parámetros de orientación de los predicados espaciales. También se disminuyeron los valores umbrales. La tabla 6.4 muestra los valores de los mismos.

Resultados obtenidos

El siguiente es un resumen de la salida del algoritmo obtenida por Weka, donde se muestra los elementos más destacados de la misma. === Run information === Scheme: weka.associations.spatiotemporal.SpatioTemporalApriori -MS 0.8 -MC 0.9 -I -IL -MTS 120.0 -THU 20.0 -TU DAY -SPC weka.associations.spatiotemporal.predicates.DistanceAnglePredicateGeographicCalculator -SP1 0[MC],40[C],100[MDC],220[MED],450[MDL],900[L],1800[ML],INF -SP2 -180[O->S],-135[S->O],-90[S->E],-45[E->S],0[E->N],45[N->E],90[N->O],135[O->N],180 Relation: Multi-ST-Instance-Dataset-weka.filters.unsupervised.attribute.PropositionalToTemporalMultiSpatialInstance-T1-P2 Instances: 365 Attributes: 2

Parámetros SpatioTemporalApriori Pará-

metros

algorit-

mos

Línea de coman-dos

Interfaz Gráfica Valor

D T corresponde al dataset en uso actual dataset procesado por los filtros comentados I



P

P2 component2LimitsAndLabels -180[O->S],-135[S->O],-90[S->E],-45[E->S],0[E->N],45[N->E],90[N->O],135[O->N],180

σ MS minimumSupport 0.8 τ MTS minimunTemporalSupport 120 ∆t THU temporalHistogramUnit 20 TU temporalUnit default θ MC minimumConfidence 0.9 I outputItemsets true IL logItemsets true

Tabla 6.4. Parámetros de uso para el algoritmo implementado por SpatioTemporalApriori, en el

caso ejemplo alternativo del dataset de transporte de gas (sección 6.1.1.2)


74

timestamp spatial_items === Associator model (full training set) === Spatio-Temporal Apriori ======================= Parameters ---------- Minimum Support: 0.8 Minimum Temporal Support: 120.0 DAY Minimum Confidence: 0.9 Temporal Histogram Unit: 20.0 DAY Spatial Predicate Calculator: weka.associations.spatiotemporal.predicates.DistanceAnglePredicateGeographicCalculator Spatial Predicates Parameters 1: 0[MC],40[C],100[MDC],220[MED],450[MDL],900[L],1800[ML],INF Spatial Predicates Parameters 2: -180[O->S],-135[S->O],-90[S->E],-45[E->S],0[E->N],45[N->E],90[N->O],135[O->N],180 Discovered Itemsets shown. Discovered Itemsets reported. Total Summaries ----------------- Frequent Itemsets Discovered: Total: 1936 - Time: 163.297s Spatio-Temporal Association Rules Discovered: Total: 16396 - Time: 0.406s Sets of frequent Itemsets Discovered ----------------------------------- Size of frequent itemsets L(1): 13 - Report File: 20071022012317_L1.txt 1). { volume_9300_kcal = '(-inf-452.349152]'(POS1) } [ { } ; [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] ] [ 1 ] 2). { volume_9300_kcal = '(1809.201576-inf)'(POS1) } [ { } ; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 } ] ( lifespan = [Thu Jan 23 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] - [ 0.7573 ] ) 3). { heating_value = '(-inf-38.239382]'(POS1) } [ { } ; [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] ] [ 1 ] ... 13). { temperature = '(25.119224-inf)'(POS1) } [ { } ; [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] ] [ 0.9589 ] Size of frequent itemsets L(2): 134 - Report File: 20071022012317_L2.txt 1). { volume_9300_kcal = '(-inf-452.349152]'(POS1), volume_9300_kcal = '(1809.201576-inf)'(POS2) } [ { DISTANCE_C-ORIENTATION_E->S(POS1,POS2) } ; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 } ] ( lifespan = [Thu Jan 23 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] - [ 0.7573 ] ) 2). { volume_9300_kcal = '(-inf-452.349152]'(POS1), volume_9300_kcal = '(1809.201576-inf)'(POS2) }


75

[ { DISTANCE_MED-ORIENTATION_E->S(POS1,POS2) } ; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 } ] ( lifespan = [Thu Jan 23 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] - [ 0.7573 ] ) ... Size of frequent itemsets L(3): 412 - Report File: 20071022012317_L3.txt 1). { volume_9300_kcal = '(-inf-452.349152]'(POS1), volume_9300_kcal = '(1809.201576-inf)'(POS2), heating_value = '(-inf-38.239382]'(POS3) } [ { DISTANCE_C-ORIENTATION_E->S(POS1,POS2), DISTANCE_C-ORIENTATION_E->S(POS1,POS3) } ; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 } ] ( lifespan = [Thu Jan 23 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] - [ 0.7251 ] ) ... Size of frequent itemsets L(4): 629 - Report File: 20071022012317_L4.txt 1). { volume_9300_kcal = '(-inf-452.349152]'(POS1), volume_9300_kcal = '(1809.201576-inf)'(POS2), heating_value = '(-inf-38.239382]'(POS3), diff_pressure = '(-inf-0.216833]'(POS4) } [ { DISTANCE_C-ORIENTATION_E->S(POS1,POS2), DISTANCE_C-ORIENTATION_E->S(POS1,POS3), DISTANCE_L-ORIENTATION_N->O(POS1,POS4) } ; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 } ] ( lifespan = [Thu Jan 23 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] - [ 0.7251 ] ) ... Size of frequent itemsets L(5): 511 - Report File: 20071022012317_L5.txt 1). { volume_9300_kcal = '(-inf-452.349152]'(POS1), volume_9300_kcal = '(1809.201576-inf)'(POS2), heating_value = '(-inf-38.239382]'(POS3), diff_pressure = '(-inf-0.216833]'(POS4), temperature = '(25.119224-inf)'(POS5) } [ { DISTANCE_C-ORIENTATION_E->S(POS1,POS2), DISTANCE_C-ORIENTATION_E->S(POS1,POS3), DISTANCE_L-ORIENTATION_N->O(POS1,POS4), DISTANCE_L-ORIENTATION_N->O(POS1,POS5) } ; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 } ] ( lifespan = [Thu Jan 23 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] - [ 0.7135 ] ) ... Size of frequent itemsets L(6): 207 - Report File: 20071022012317_L6.txt 1). { volume_9300_kcal = '(-inf-452.349152]'(POS1), volume_9300_kcal = '(1809.201576-inf)'(POS2), heating_value = '(-inf-38.239382]'(POS3), diff_pressure = '(-inf-0.216833]'(POS4), pressure = '(-inf-15.947004]'(POS5), temperature = '(10.557669-17.838447]'(POS6) } [ { DISTANCE_MED-ORIENTATION_E->S(POS1,POS2), DISTANCE_MED-ORIENTATION_E->S(POS1,POS3), DISTANCE_MED-ORIENTATION_E->S(POS1,POS4), DISTANCE_MED-ORIENTATION_E->S(POS1,POS5), DISTANCE_MED-ORIENTATION_E->S(POS1,POS6) } ; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 } ] ( lifespan = [Thu Jan 23 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] - [ 0.7427 ] ) ... Size of frequent itemsets L(7): 30 - Report File: 20071022012317_L7.txt 1). { volume_9300_kcal = '(-inf-452.349152]'(POS1), volume_9300_kcal = '(1809.201576-inf)'(POS2), heating_value = '(-inf-38.239382]'(POS3), diff_pressure


76

= '(-inf-0.216833]'(POS4), pressure = '(-inf-15.947004]'(POS5), temperature = '(10.557669-17.838447]'(POS6), temperature = '(25.119224-inf)'(POS7) } [ { DISTANCE_MED-ORIENTATION_E->S(POS1,POS2), DISTANCE_MED-ORIENTATION_E->S(POS1,POS3), DISTANCE_MED-ORIENTATION_E->S(POS1,POS4), DISTANCE_MED-ORIENTATION_E->S(POS1,POS5), DISTANCE_MED-ORIENTATION_E->S(POS1,POS6), DISTANCE_L-ORIENTATION_N->O(POS1,POS7) } ; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 } ] ( lifespan = [Thu Jan 23 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] - [ 0.731 ] ) ... 30). { volume_9300_kcal = '(-inf-452.349152]'(POS1), heating_value = '(-inf-38.239382]'(POS2), diff_pressure = '(-inf-0.216833]'(POS3), pressure = '(-inf-15.947004]'(POS4), temperature = '(-inf-3.276892]'(POS5), temperature = '(10.557669-17.838447]'(POS6), temperature = '(25.119224-inf)'(POS7) } [ { DISTANCE_MDL-ORIENTATION_E->N(POS1,POS2), DISTANCE_L-ORIENTATION_N->E(POS1,POS3), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS4), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS5), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS6), DISTANCE_L-ORIENTATION_N->E(POS1,POS7) } ; { [Tue Jun 10 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.8098 } ] ( lifespan = [Mon May 12 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] - [ 0.7521 ] ) Spatio-Temporal Association Rules Discovered -------------------------------------------- 1). volume_9300_kcal = '(-inf-452.349152]'(POS1) ===> heating_value = '(-inf-38.239382]'(POS2) [ { DISTANCE_C-ORIENTATION_E->S(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9562 }; { 0.9562 } ] 2). volume_9300_kcal = '(-inf-452.349152]'(POS1) ===> heating_value = '(-inf-38.239382]'(POS2) [ { DISTANCE_MED-ORIENTATION_E->S(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9781 }; { 0.9781 } ] 3). volume_9300_kcal = '(-inf-452.349152]'(POS1) ===> heating_value = '(-inf-38.239382]'(POS2) [ { DISTANCE_MDL-ORIENTATION_E->N(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] ... 10). volume_9300_kcal = '(-inf-452.349152]'(POS1) ===> pressure = '(-inf-15.947004]'(POS2) [ { DISTANCE_MED-ORIENTATION_E->S(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] 11). volume_9300_kcal = '(-inf-452.349152]'(POS1) ===> pressure = '(-inf-15.947004]'(POS2) [ { DISTANCE_MDL-ORIENTATION_E->N(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] ... 19). volume_9300_kcal = '(-inf-452.349152]'(POS1) ===> temperature = '(25.119224-inf)'(POS2) [ { DISTANCE_L-ORIENTATION_N->E(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9589 }; { 0.9589 } ]


77

20). volume_9300_kcal = '(-inf-452.349152]'(POS1) ===> temperature = '(25.119224-inf)'(POS2) [ { DISTANCE_L-ORIENTATION_N->O(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9589 }; { 0.9589 } ] ... 27). volume_9300_kcal = '(1809.201576-inf)'(POS1) ===> pressure = '(-inf-15.947004]'(POS2) [ { DISTANCE_C-ORIENTATION_O->N(POS1,POS2) }; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 }; { 1 } ] 28). volume_9300_kcal = '(1809.201576-inf)'(POS1) ===> pressure = '(-inf-15.947004]'(POS2) [ { DISTANCE_MED-ORIENTATION_O->N(POS1,POS2) }; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 }; { 1 } ] 29). volume_9300_kcal = '(1809.201576-inf)'(POS1) ===> pressure = '(-inf-15.947004]'(POS2) [ { DISTANCE_MDL-ORIENTATION_O->S(POS1,POS2) }; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 }; { 1 } ] 30). volume_9300_kcal = '(1809.201576-inf)'(POS1) ===> temperature = '(10.557669-17.838447]'(POS2) [ { DISTANCE_C-ORIENTATION_O->N(POS1,POS2) }; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 }; { 1 } ] 31). volume_9300_kcal = '(1809.201576-inf)'(POS1) ===> temperature = '(25.119224-inf)'(POS2) [ { DISTANCE_L-ORIENTATION_N->O(POS1,POS2) }; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 }; { 1 } ] ... 40). heating_value = '(-inf-38.239382]'(POS1) ===> pressure = '(-inf-15.947004]'(POS2) [ { DISTANCE_MED-ORIENTATION_O->N(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9781 }; { 0.9781 } ] 41). heating_value = '(-inf-38.239382]'(POS1) ===> pressure = '(-inf-15.947004]'(POS2) [ { DISTANCE_MDL-ORIENTATION_O->S(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] 42). heating_value = '(-inf-38.239382]'(POS1) ===> pressure = '(-inf-15.947004]'(POS2) [ { DISTANCE_MDL-ORIENTATION_E->N(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9918 }; { 0.9918 } ] ... 49). heating_value = '(-inf-38.239382]'(POS1) ===> temperature = '(25.119224-inf)'(POS2) [ { DISTANCE_L-ORIENTATION_N->E(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9507 }; { 0.9507 } ] 50). heating_value = '(-inf-38.239382]'(POS1) ===> temperature = '(25.119224-inf)'(POS2) [ { DISTANCE_L-ORIENTATION_N->O(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ]


78

[ { 0.9589 }; { 0.9589 } ] ... 53). heating_value = '(38.239382-39.301984]'(POS1) ===> pressure = '(-inf-15.947004]'(POS2) [ { DISTANCE_L-ORIENTATION_S->O(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9315 }; { 0.9605 } ] 54). heating_value = '(38.239382-39.301984]'(POS1) ===> pressure = '(-inf-15.947004]'(POS2) [ { DISTANCE_L-ORIENTATION_S->E(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9315 }; { 0.9605 } ] ... 57). diff_pressure = '(-inf-0.216833]'(POS1) ===> pressure = '(-inf-15.947004]'(POS2) [ { DISTANCE_MED-ORIENTATION_E->S(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] 58). diff_pressure = '(-inf-0.216833]'(POS1) ===> pressure = '(-inf-15.947004]'(POS2) [ { DISTANCE_MED-ORIENTATION_O->N(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] 59). diff_pressure = '(-inf-0.216833]'(POS1) ===> pressure = '(-inf-15.947004]'(POS2) [ { DISTANCE_MDL-ORIENTATION_O->S(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] 60). diff_pressure = '(-inf-0.216833]'(POS1) ===> pressure = '(-inf-15.947004]'(POS2) [ { DISTANCE_MDL-ORIENTATION_E->N(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] 61). diff_pressure = '(-inf-0.216833]'(POS1) ===> pressure = '(-inf-15.947004]'(POS2) [ { DISTANCE_L-ORIENTATION_S->O(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] 62). diff_pressure = '(-inf-0.216833]'(POS1) ===> pressure = '(-inf-15.947004]'(POS2) [ { DISTANCE_L-ORIENTATION_S->E(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] ... 72). diff_pressure = '(-inf-0.216833]'(POS1) ===> temperature = '(25.119224-inf)'(POS2) [ { DISTANCE_L-ORIENTATION_N->E(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9589 }; { 0.9589 } ] 73). diff_pressure = '(-inf-0.216833]'(POS1) ===> temperature = '(25.119224-inf)'(POS2) [ { DISTANCE_L-ORIENTATION_N->O(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9589 }; { 0.9589 } ] ... 81). pressure = '(-inf-15.947004]'(POS1) ===> temperature = '(25.119224-inf)'(POS2)


79

[ { DISTANCE_L-ORIENTATION_N->E(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9589 }; { 0.9589 } ] 82). pressure = '(-inf-15.947004]'(POS1) ===> temperature = '(25.119224-inf)'(POS2) [ { DISTANCE_L-ORIENTATION_N->O(POS1,POS2) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9589 }; { 0.9589 } ] ... 97). volume_9300_kcal = '(-inf-452.349152]'(POS1), volume_9300_kcal = '(1809.201576-inf)'(POS2) ===> pressure = '(-inf-15.947004]'(POS3) [ { DISTANCE_MED-ORIENTATION_E->S(POS1,POS2), DISTANCE_MED-ORIENTATION_E->S(POS1,POS3) }; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 }; { 1 } ] ... 103). volume_9300_kcal = '(-inf-452.349152]'(POS1), volume_9300_kcal = '(1809.201576-inf)'(POS2) ===> pressure = '(-inf-15.947004]'(POS3) [ { DISTANCE_MDL-ORIENTATION_E->N(POS1,POS2), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS3) }; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 }; { 1 } ] ... 120). volume_9300_kcal = '(-inf-452.349152]'(POS1), heating_value = '(-inf-38.239382]'(POS2) ===> temperature = '(25.119224-inf)'(POS3) [ { DISTANCE_C-ORIENTATION_E->S(POS1,POS2), DISTANCE_L-ORIENTATION_N->O(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9151 }; { 0.957 } ] ... 181). volume_9300_kcal = '(-inf-452.349152]'(POS1), heating_value = '(-inf-38.239382]'(POS2) ===> pressure = '(15.947004-31.894007]'(POS3) [ { DISTANCE_L-ORIENTATION_S->O(POS1,POS2), DISTANCE_L-ORIENTATION_S->E(POS1,POS3) }; { [Sun Mar 02 00:00:00 ART 2003; Sun Jun 29 00:00:00 ART 2003], [Sat Aug 09 00:00:00 ART 2003; Fri Dec 26 00:00:00 ART 2003] } ] [ { 0.8417, 0.8286 }; { 1, 1 } ] ... 193). volume_9300_kcal = '(-inf-452.349152]'(POS1), heating_value = '(-inf-38.239382]'(POS2) ===> pressure = '(15.947004-31.894007]'(POS3) [ { DISTANCE_L-ORIENTATION_S->E(POS1,POS2), DISTANCE_L-ORIENTATION_S->E(POS1,POS3) }; { [Sun Mar 02 00:00:00 ART 2003; Sat Jul 19 00:00:00 ART 2003], [Sat Aug 09 00:00:00 ART 2003; Fri Dec 26 00:00:00 ART 2003] } ] [ { 0.8071, 0.8286 }; { 1, 1 } ] 194). volume_9300_kcal = '(-inf-452.349152]'(POS1), temperature = '(-inf-3.276892]'(POS2) ===> heating_value = '(-inf-38.239382]'(POS3) [ { DISTANCE_L-ORIENTATION_S->E(POS1,POS2), DISTANCE_L-ORIENTATION_S->E(POS1,POS3) }; { [Sat Aug 09 00:00:00 ART 2003; Fri Dec 26 00:00:00 ART 2003] } ] [ { 0.8 }; { 1 } ] ... 248). volume_9300_kcal = '(-inf-452.349152]'(POS1), temperature = '(25.119224-inf)'(POS2) ===> diff_pressure = '(-inf-0.216833]'(POS3) [ { DISTANCE_L-ORIENTATION_N->O(POS1,POS2), DISTANCE_MED-ORIENTATION_E->S(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9589 }; { 1 } ] 249). volume_9300_kcal = '(-inf-452.349152]'(POS1), diff_pressure = '(-inf-0.216833]'(POS2) ===> temperature = '(25.119224-inf)'(POS3) [ { DISTANCE_MED-ORIENTATION_E->S(POS1,POS2), DISTANCE_L-ORIENTATION_N->O(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9589 }; { 0.9589 } ] ...


80

252). volume_9300_kcal = '(-inf-452.349152]'(POS1), diff_pressure = '(-inf-0.216833]'(POS2) ===> pressure = '(-inf-15.947004]'(POS3) [ { DISTANCE_MDL-ORIENTATION_E->N(POS1,POS2), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 1 }; { 1 } ] ... 267). volume_9300_kcal = '(-inf-452.349152]'(POS1), diff_pressure = '(-inf-0.216833]'(POS2) ===> temperature = '(25.119224-inf)'(POS3) [ { DISTANCE_MDL-ORIENTATION_E->N(POS1,POS2), DISTANCE_L-ORIENTATION_N->E(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9589 }; { 0.9589 } ] ... 295). volume_9300_kcal = '(-inf-452.349152]'(POS1), diff_pressure = '(-inf-0.216833]'(POS2) ===> temperature = '(25.119224-inf)'(POS3) [ { DISTANCE_L-ORIENTATION_N->E(POS1,POS2), DISTANCE_L-ORIENTATION_N->E(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9589 }; { 0.9589 } ] ... 316). volume_9300_kcal = '(-inf-452.349152]'(POS1), diff_pressure = '(-inf-0.216833]'(POS2) ===> temperature = '(25.119224-inf)'(POS3) [ { DISTANCE_L-ORIENTATION_N->O(POS1,POS2), DISTANCE_L-ORIENTATION_N->O(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9589 }; { 0.9589 } ] ... 328). volume_9300_kcal = '(-inf-452.349152]'(POS1), temperature = '(25.119224-inf)'(POS2) ===> pressure = '(-inf-15.947004]'(POS3) [ { DISTANCE_L-ORIENTATION_N->O(POS1,POS2), DISTANCE_MED-ORIENTATION_E->S(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9589 }; { 1 } ] 329). volume_9300_kcal = '(-inf-452.349152]'(POS1), pressure = '(-inf-15.947004]'(POS2) ===> temperature = '(25.119224-inf)'(POS3) [ { DISTANCE_MED-ORIENTATION_E->S(POS1,POS2), DISTANCE_L-ORIENTATION_N->O(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9589 }; { 0.9589 } ] 330). volume_9300_kcal = '(-inf-452.349152]'(POS1) ===> pressure = '(-inf-15.947004]'(POS2), temperature = '(25.119224-inf)'(POS3) [ { DISTANCE_MED-ORIENTATION_E->S(POS1,POS2), DISTANCE_L-ORIENTATION_N->O(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9589 }; { 0.9589 } ] ... 345). volume_9300_kcal = '(-inf-452.349152]'(POS1) ===> pressure = '(-inf-15.947004]'(POS2), temperature = '(25.119224-inf)'(POS3) [ { DISTANCE_MDL-ORIENTATION_E->N(POS1,POS2), DISTANCE_L-ORIENTATION_N->E(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.9589 }; { 0.9589 } ] ... 478). volume_9300_kcal = '(1809.201576-inf)'(POS1), diff_pressure = '(-inf-0.216833]'(POS2) ===> temperature = '(25.119224-inf)'(POS3) [ { DISTANCE_C-ORIENTATION_O->N(POS1,POS2), DISTANCE_L-ORIENTATION_N->O(POS1,POS3) }; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 }; { 1 } ] ... 493). volume_9300_kcal = '(1809.201576-inf)'(POS1), diff_pressure = '(-inf-0.216833]'(POS2) ===> temperature = '(25.119224-inf)'(POS3) [ { DISTANCE_MED-ORIENTATION_O->N(POS1,POS2), DISTANCE_L-ORIENTATION_N->O(POS1,POS3) }; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 }; { 1 } ] ...


81

508). volume_9300_kcal = '(1809.201576-inf)'(POS1), diff_pressure = '(-inf-0.216833]'(POS2) ===> temperature = '(25.119224-inf)'(POS3) [ { DISTANCE_MDL-ORIENTATION_O->S(POS1,POS2), DISTANCE_L-ORIENTATION_N->O(POS1,POS3) }; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 }; { 1 } ] ... 523). volume_9300_kcal = '(1809.201576-inf)'(POS1), diff_pressure = '(-inf-0.216833]'(POS2) ===> temperature = '(25.119224-inf)'(POS3) [ { DISTANCE_L-ORIENTATION_N->O(POS1,POS2), DISTANCE_L-ORIENTATION_N->O(POS1,POS3) }; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 }; { 1 } ] ... 700). heating_value = '(-inf-38.239382]'(POS1) ===> pressure = '(-inf-15.947004]'(POS2), temperature = '(25.119224-inf)'(POS3) [ { DISTANCE_MED-ORIENTATION_O->N(POS1,POS2), DISTANCE_L-ORIENTATION_N->O(POS1,POS3) }; { [Wed Jan 01 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.937 }; { 0.937 } ] ... 2504). volume_9300_kcal = '(1809.201576-inf)'(POS1), diff_pressure = '(-inf-0.216833]'(POS2), temperature = '(25.119224-inf)'(POS3) ===> heating_value = '(-inf-38.239382]'(POS4) [ { DISTANCE_C-ORIENTATION_O->N(POS1,POS2), DISTANCE_L-ORIENTATION_N->O(POS1,POS3), DISTANCE_MED-ORIENTATION_O->N(POS1,POS4) }; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 }; { 1 } ] ... 2506). volume_9300_kcal = '(1809.201576-inf)'(POS1), heating_value = '(-inf-38.239382]'(POS2), diff_pressure = '(-inf-0.216833]'(POS3) ===> temperature = '(25.119224-inf)'(POS4) [ { DISTANCE_MED-ORIENTATION_O->N(POS1,POS2), DISTANCE_C-ORIENTATION_O->N(POS1,POS3), DISTANCE_L-ORIENTATION_N->O(POS1,POS4) }; { [Fri Aug 29 00:00:00 ART 2003; Tue Dec 30 00:00:00 ART 2003] } ] [ { 0.808 }; { 1 } ] ... 5300). volume_9300_kcal = '(-inf-452.349152]'(POS1), heating_value = '(-inf-38.239382]'(POS2), temperature = '(-inf-3.276892]'(POS3), temperature = '(25.119224-inf)'(POS4) ===> temperature = '(10.557669-17.838447]'(POS5) [ { DISTANCE_MED-ORIENTATION_E->S(POS1,POS2), DISTANCE_MED-ORIENTATION_E->S(POS1,POS3), DISTANCE_L-ORIENTATION_N->O(POS1,POS4), DISTANCE_MED-ORIENTATION_E->S(POS1,POS5) }; { [Tue Jun 10 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.8098 }; { 1 } ] ... 10000). heating_value = '(-inf-38.239382]'(POS1), pressure = '(-inf-15.947004]'(POS2), temperature = '(17.838447-25.119224]'(POS3) ===> pressure = '(15.947004-31.894007]'(POS4), temperature = '(10.557669-17.838447]'(POS5) [ { DISTANCE_MDL-ORIENTATION_E->N(POS1,POS2), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS3), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS4), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS5) }; { [Sat Aug 09 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.8069 }; { 1 } ] ... 16394). volume_9300_kcal = '(-inf-452.349152]'(POS1), diff_pressure = '(-inf-0.216833]'(POS2), temperature = '(-inf-3.276892]'(POS3) ===> heating_value = '(-inf-38.239382]'(POS4), pressure = '(-inf-15.947004]'(POS5), temperature = '(10.557669-17.838447]'(POS6), temperature = '(25.119224-inf)'(POS7) [ { DISTANCE_L-ORIENTATION_N->E(POS1,POS2), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS3), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS4), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS5), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS6), DISTANCE_L-


82

ORIENTATION_N->E(POS1,POS7) }; { [Tue Jun 10 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.8098 }; { 0.9379 } ] 16395). volume_9300_kcal = '(-inf-452.349152]'(POS1), heating_value = '(-inf-38.239382]'(POS2), temperature = '(-inf-3.276892]'(POS3) ===> diff_pressure = '(-inf-0.216833]'(POS4), pressure = '(-inf-15.947004]'(POS5), temperature = '(10.557669-17.838447]'(POS6), temperature = '(25.119224-inf)'(POS7) [ { DISTANCE_MDL-ORIENTATION_E->N(POS1,POS2), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS3), DISTANCE_L-ORIENTATION_N->E(POS1,POS4), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS5), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS6), DISTANCE_L-ORIENTATION_N->E(POS1,POS7) }; { [Tue Jun 10 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.8098 }; { 0.9379 } ] 16396). volume_9300_kcal = '(-inf-452.349152]'(POS1), temperature = '(-inf-3.276892]'(POS2) ===> heating_value = '(-inf-38.239382]'(POS3), diff_pressure = '(-inf-0.216833]'(POS4), pressure = '(-inf-15.947004]'(POS5), temperature = '(10.557669-17.838447]'(POS6), temperature = '(25.119224-inf)'(POS7) [ { DISTANCE_MDL-ORIENTATION_E->N(POS1,POS2), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS3), DISTANCE_L-ORIENTATION_N->E(POS1,POS4), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS5), DISTANCE_MDL-ORIENTATION_E->N(POS1,POS6), DISTANCE_L-ORIENTATION_N->E(POS1,POS7) }; { [Tue Jun 10 00:00:00 ART 2003; Wed Dec 31 00:00:00 ART 2003] } ] [ { 0.8098 }; { 0.9379 } ]

En cuanto a las secciones, aparecen las mismas que en el caso anterior. En el caso de los parámetros (“=== Run information ===” y “Parameters”) se observan los nuevos valores de este caso. En la parte de los resúmenes totales, bajo el titulo “Total Summaries” se observan que la cantidad de itemsets frecuentes y reglas de asociación descubiertos es mayor, lo que se debe a la disminución de los parámetros umbrales. Para el descubrimiento de los itemsets frecuentes, el tiempo insumido fue menor debido a que el tamaño del dataset base es menor, ya que se disminuyo la cantidad de estaciones de medición. En el caso de la obtención de las reglas de asociación, el tiempo aumentó debido a que la cantidad de itemsets frecuentes -entrada de esta parte del algoritmo dentro del algoritmo total- fue mayor, y a la disminución del umbral de confianza -tener en cuenta que las reglas se arman de manera iterativa en base a los consecuentes de las reglas anteriormente obtenidas-. En cuanto a los itemset frecuentes, y las reglas obtenidas, la información de las mismas se muestra de manera diferente. Esto es debido a dos motivos: • los items del conjunto I se obtuvieron en base a un esquema de discretización donde

los elementos resultantes eran intervalos abarcando todo los valores posibles de cada atributo del dataset. De esta manera, los valores de los items que componen las reglas se muestran como intervalos continuos, con valores máximo y mínimo

• en los parámetros de los predicados espaciales, se seleccionó otro esquema para dividir a los valores de la orientación de los mismos. Se optó por una alternativa donde los límites de los intervalos estaban dados por los de los cuadrantes y sus valores intermedios. Debido a esto, se cambio la etiqueta identificatoria de cada intervalo de discretización del parámetro señalado. La misma es la que permite identificar, en parte, a los predicados espaciales de P; y es la que se observa en los elementos descubiertos.

Respecto a las reglas obtenidas, los tipos de reglas que destacan debido a su utilidad para el usuario son similares a las del caso anterior, ya que el área de aplicación es la misma. Se pueden señalar algunas diferencias, las cuales se deben a los diferentes datos seleccionados para el dataset, y a los diferentes filtros con los cuales se proceso el mismo. En cuanto a las reglas que involucraban valores altos de temperatura, en este caso el item correspondiente es “TEMPERATURE_VH”. El mismo abarca valores superiores a los correspondientes al item del caso anterior; de esta manera, las reglas de este caso presentan


83

una utilidad un poco mas marcada. Entre las mismas se pueden observar dos reglas con antecedente “muy bajo” de volumen, 19 y 20, y una sola con volumen “muy alto”: 31; con lo cual esta última regla sería más destacable, ya que presenta menos alternativas de relaciones espaciales. También se observan los pares de reglas 49 y 50, 72 y 73, 81 y 82, con antecedentes de poder calorífico “bajo”, presión diferencial “baja”, y presión estática “baja”, respectivamente. Si a las reglas con antecedente de volumen “muy bajo” se agrega “presión diferencial baja” a su antecedente, las mismas aumentan en cantidad a 4 reglas: 249, 267, 295 y 316. En el caso de las dos últimas reglas, los valores de soporte y confianza de las mismas se mantienen iguales respecto a los casos del párrafo anterior; con lo cual se puede considerar que “presión diferencial baja” en estos casos no agrega información a la reglas. El mismo caso se puede nombrar con las reglas con antecedente de volumen “muy alto”, de las cuales 478, 493, 508 y 523 agregan “presión diferencial baja” a su antecedente. Para este caso, se observa la regla 523 que mantiene los mismos valores de soporte y confianza respecto a la regla 31 –la regla correspondiente sin incluir “presión diferencial baja” en su antecedente-. De este tipo de reglas que involucran valores altos de temperatura, otra regla que se puede señalar es la 120. La misma tiene como antecedentes el volumen y el poder calorífico, y los mismos se encuentran espacialmente a una distancia cercana; con lo cual el antecedente de esta regla se puede identificar como un valor bajo de energía transferido. Para las reglas que involucran valores bajos de presión, pudiendo identificar situaciones criticas en el transporte del gas, se encuentran varios casos. Con un item en el antecedente, se pueden destacar las reglas 10 y 11, con un valor “muy bajo” de volumen, y 53 y 54, con un valor de poder calorífico “medio”. Las mismas aportan un poco mas de conocimiento respecto de las que contienen los mismos atributos con otros valores, ya que estas últimas abarcan mas casos: las reglas con volumen “muy alto” en su antecedente se encuentra en 27, 28 y 29, y con un valor de poder calorífico “bajo” en 40, 41 y 42. En último lugar se encuentran las reglas con presión diferencial “baja” como antecedente, ya que las mismas abarcan 6 predicados espaciales, los cuales se encuentran en las reglas 57 a 62. Otro caso a señalar son las reglas 97 y 103. Las mismas, además de relacionar un valor “bajo” de volumen con uno “bajo” de presión estática, muestran un aumento en el valor del volumen transferido; siendo ambas relaciones espaciales entre las posiciones geográficas correspondientes, representadas con el mismo predicado espacial. Una última regla a destacar es la 330, la cual abarca en si misma los dos casos comentados en párrafos anteriores de “temperatura muy alta” y “presión baja” en el consecuente. Se observa que el conocimiento de la regla es el aportado por las reglas 20 y 10, con lo cual esta regla es un ejemplo de una manera resumida de presentar varios casos en una misma regla. Otra regla de este tipo es la 345, que abarca el conocimiento de las reglas 19 y 11. Para este caso también las reglas mostradas son aquellas en que se destacaba su utilidad de uso para el usuario, en base a los detalles aportados por el mismo respecto del dominio de aplicación actual de los datos. Al igual que en el caso anterior, es posible encontrar información útil en otras reglas; en base a un mejor conocimiento de uso, por parte del usuario, de los resultados provistos por la solución implementada, así como mediante el uso de aplicaciones de postprocesamiento de los resultados obtenidos.

6.1.2. Otras aplicaciones

Además de la aplicación analizada en la sección anterior, se pueden hallar otras aplicaciones variadas del modelo desarrollado.


84

En primer lugar, se puede tomar la aplicación del modelo binario de reglas de asociación, el análisis de la canasta de mercado ([2]), y extenderla para el trabajo actual, de manera similar a como se oriento la propuesta de [20], una de alternativas de modelos de reglas de asociación espacio-temporales nombrado en el capítulo 2. En el caso de aplicarse al modelo planteado en este trabajo, lo que se permitiría obtener serían relaciones espaciales entre los items comprados, de las que se podrían hallar determinadas tendencias geográficas de compra y/o adquisición de los servicios en análisis, representadas las mismas por las relaciones espaciales entre las posiciones geográficas donde se realizaron las compras. Además, las mismas no se mostrarían de manera estática, sino en los periodos temporales de aparición descubiertos. Otra aplicación posible sería sobre datos de mediciones del clima. Para este, caso se puede comentar la existencia de trabajos que han utilizado este tipo de datasets: [36], [15]. En general, en las fuentes de datos de estos casos, se tienen varias estaciones meteorológicas, ubicadas en diferentes posiciones geográficas, que pueden realizar mediciones de diversas variables climáticas en los mismos o diferentes instantes de tiempo: temperatura, humedad, presión atmosférica, nivel de precipitaciones, viento y otras [27]. Para este caso lo que se obtendría con el modelo serían diferentes relaciones entre los valores de las variables meteorológicas medidas, relacionadas espacialmente y ubicadas en diferentes intervalos de tiempo. Las reglas resultantes pueden ser analizadas para permitir obtener información respecto de aquellas que involucren determinados valores de variables críticos, que sean necesarios prever bajo diferentes situaciones. Por ejemplo, niveles de precipitaciones muy altos que puedan llegar a producir inundaciones, temperaturas altas junto a niveles de precipitaciones bajos que sean riesgos de incendios, niveles de temperatura bajos los que indicarían periodos de “olas polares”. De esta manera, se puede obtener conocimiento sobre las situaciones del entorno de cuando ocurren estos valores de las variables, sea geográficamente en relación con valores de otras variables meteorológicas, como temporalmente con los periodos de tiempo de ocurrencia de las mismas. También, se puede encontrar aplicación posible del modelo planteado dentro del área de la contaminación urbana. Existen varios proyectos que trabajan con esta temática. En la ciudad de Londres, por ejemplo, se comercializan diferentes dispositivos, que se ubican en general sobre los postes de luz, y miden varias variables de contaminación del aire: cantidad de monóxido de carbono, temperatura, humedad, velocidad del viento ([7], [32]). Algunos de estos dispositivos fueron desarrollados y utilizados en proyectos de investigación sobre la polución ambiental de la ciudad ([8]). Además, existen sitios de internet a traves de los cuales es posible consultar y observar, georeferenciados en mapas, valores de los niveles de varias sustancias contaminantes ([39]) y niveles de contaminación sonora ([9]). Dentro del ambiente local, la Dirección General de Control de la Calidad Ambiental del GCBA tiene un programa denominado ”Monitoreo Atmosférico en la Ciudad de Buenos Aires”. En el mismo se realizan diversas mediciones del nivel de contaminantes en el aire, debido a fuentes móviles y fijas, niveles de contaminación sonora, niveles de calidad de las zonas de agua dentro de los espacios de la ciudad y la zona ribereña del Río de la Plata [12]. Para este caso, las reglas de asociación espacio-temporales planteadas pueden ser útiles para obtener relación sobre las variables medidas en los diferentes tipos de contaminación (del aire, sonora, en espacios de agua) y la relación espacial entre los mismas. De esta manera, se pueden analizar los diferentes tipos de contaminaciones en conjunto, hayando periodos de tiempo comunes de ocurrencia de las mismas, así como posibles fuentes causantes de algunas o todas las problematicas analizadas, junto con las relaciones geográficas donde se producen estas relaciones entre variables. En este caso tiene importancia las relaciones geográficas ya que es probable que las diferentes fuentes de cada contaminación no se ubiquen en las mismas posiciones geográficas, con lo cual este esquema sería una manera adecuada de presentar las


85

relaciones entre las variables que representan a las mismas. Respecto al uso del tiempo, el mismo es conveniente para poder hallar reglas que involucren nuevos tipos de contaminación –contaminación de otro origen y/o la aparición de nuevas fuentes para tipos de contaminación reconocidas-, que no podrían hallarse si se tomara todo el periodo de tiempo en su conjunto.

6.2. Pruebas de performance

6.2.1. Tipos de Pruebas

Para poder estudiar la performance y escalabilidad de los algoritmos implementados, es conveniente realizar dos tipos de pruebas: • analizar los tiempos de ejecución en función del tamaño del dataset • analizar la cantidad de itemsets frecuentes descubiertos en función de los parámetros

umbrales En cada una de las pruebas a realizar se deben determinar las variables a ir incrementado o decrementando su valor, y las variables a mantener fijas. Para identificar estas variables se puede realizar un análisis de cuales son las involucradas en el tamaño del dataset y cuales las involucradas en los parámetros umbrales.

6.2.1.1.Variables involucradas en el tamaño del dataset

En el capítulo 4 se explico que podía identificarse dos datasets involucrados en el proceso de descubrimiento de las reglas de asociación espacio-temporales: un dataset base (B) y un dataset del modelo (D). Teniendo en cuenta estos datasets, pueden identificarse 3 variables que influyen en su tamaño: • la cantidad de timestamp existentes – T • la cantidad de sensores existentes – S (este valor fue nombrado en la sección 4.1.1.4

del capítulo 4 en base a las posiciones geográficas de estos sensores, como |GPD|) • la cantidad de items posibles - |I|. En caso de manejarse atributos continuos,

relacionado con esta variable se puede nombrar la cantidad de atributos del dataset (ATT).

Utilizando estas variables se pueden identificar los tamaños de los datasets correspondientes. Para el dataset base, el tamaño del mismo se encuentra dado por T*S. El tamaño de cada registro lo define la cantidad de items existentes en el mismo, siendo su valor máximo |I|. Si se trabaja con atributos discretizados, este valor se encuentra dado por la cantidad de atributos ATT. El tamaño del dataset del modelo se encuentra definido por |D| = T. El tamaño de las transacciones del mismo involucra a S y la cantidad de items existentes en cada uno de estos sensores para cada timestamp t. Si se trabaja con atributos discretizados, este valor se encuentra dado por S*ATT. En el caso de trabajar con atributos discretizados, como en los casos de ejemplo anteriormente explicados, los intervalos de discretización seleccionados no influyen en los tamaños de los datasets, sino en los items que componen las transacciones o registros de los mismos. En base a lo anterior, al realizar las pruebas en función del tamaño del dataset es conveniente considerar el dataset base; ya que es mas común obtener el mismo para el descubrimiento de


86

las reglas de asociación. De esta manera, las pruebas se pueden realizar en base a los valores de las dos variables que determinan su tamaño: T, la cantidad de timestamp, y S, la cantidad de sensores. Sin olvidar que esta última influye además en el tamaño de las transacciones del dataset del modelo D.

6.2.1.2.Variables involucradas en los parámetros umbrales

Considerando los parámetros dados al algoritmo implementado en Weka en la clase SpatioTemporalApriori, explicados en el capítulo anterior, se pueden identificar 3 parámetros umbrales. Esto se debe a que influyen en la cantidad de itemsets y/o reglas a ser descubiertos. Los mismos son: • σ - MS: umbral de soporte • τ - MTS: umbral de soporte temporal • θ - MC: umbral de confianza

Como el último influye en la obtención de las reglas una vez descubiertos los itemsets frecuentes, no es considerado para la pruebas. Entonces, para este caso las pruebas en función de los parámetros umbrales se pueden realizar en base a dos parámetros: σ y τ.

6.2.2. Pruebas realizadas

Las pruebas se realizaron sobre el dataset comentado en la sección 6.1.1, sobre transporte de gas. En la selección de los conjuntos de pruebas en base al mismo, se trato de que en cada uno de los instantes de tiempo existan valores registrados para todas las variables en todos los sensores seleccionados. De esta manera, se evitaron tamaños diferentes entre las transacciones del dataset que pudieran influir en las pruebas. Las pruebas realizadas fueron de cuatro tipos: • tiempo de descubrimiento en función de la cantidad de timestamps existentes en el

dataset • tiempo de descubrimiento en función de la cantidad de sensores existentes en el dataset • cantidad de itemset descubiertos en función del umbral de soporte • cantidad de itemset descubiertos en función del umbral de soporte temporal

Las pruebas realizadas fueron ejecutadas sobre un máquina con un procesador AMD Athlon™ 64 3000+ (1.81GHz), con una memoria RAM de 2GB. El sistema operativo fue MS Windows XP SP2. La versión de java fue la 5. La memoria de la jvm fue configurada a un máximo de 1,5 GB.

6.2.2.1.Tiempo en función de la cantidad de timestamps

Debido a que para el dataset del modelo cada transacción se corresponde a cada instante de tiempo del dataset, para esta prueba se fueron tomando diferente cantidad de transacciones de cada uno de los dataset seleccionados. Las mismas se tomaron contiguas, respecto al instante


87

de tiempo, y desde el principio del dataset. Se comenzaron con 150 transacciones, las que se fueron aumentando hasta llegar a 365. La cantidad de sensores seleccionados fue 6. Para la discretización de los atributos del dataset se utilizó el filtro Discretize, con un esquema de discretización de igual ancho y seleccionando la cantidad de intervalos de discretización para cada atributo del dataset. Se seleccionó este filtro de discretización ya que para la prueba actual la intención es mantener en cada punto de la curva el conjunto de items de cada dataset (I) lo más parecido posible. Utilizando este filtro, donde se determina la cantidad de intervalos a discretizar cada atributo del dataset, se asegura la misma cantidad de elementos de I en cada uno de los puntos de la curva. En la selección de la cantidad de intervalos de cada atributo primero se aplico un criterio similar al del caso de ejemplo de la sección 6.1.1.2 para el dataset de mayor tamaño -con 365 transacciones-. Luego se verifico en cada prueba de cada uno de los puntos de la curva que no apareciera una variación considerable en el tamaño de los intervalos de discretización respecto a los de las pruebas de los otros puntos de la curva; por ejemplo respecto a la aparición de intervalos sin elementos o con un porcentaje muy reducido respecto a las otras pruebas. La tabla 6.5 muestra los parámetros del algoritmo utilizados en las pruebas.

Debido a que las curvas obtenidas no presentaban una tendencia observable de manera simple, se corrieron tomando tres datasets diferentes para poder verificar el comportamiento del algoritmo para la prueba. Entre los diferentes datasets seleccionados lo que vario fueron los sensores o estaciones de medición seleccionadas y la cantidad de intervalos de discretización a elegir para cada atributo. El conjunto de sensores seleccionado se fue modificando para determinar si la tendencia observada, en la prueba realizada, no dependía del conjunto de valores aportados de manera particular por los sensores en el dataset actual. Debido a que se cambiaron los valores registrados, los posibles valores de cada atributo eran distintos. De esta manera, se seleccionaban intervalos de discretización mas adecuados con los mismos. La tabla 6.6 muestra los valores seleccionados para los datasets.

Parámetros SpatioTemporalApriori Parámetros

algoritmos Línea de comandos

Interfaz Gráfica Valores (para las tres

pruebas)


P1 component1LimitsAndLabels default

P

P2 component2LimitsAndLabels default σ MS minimumSupport 0.7 τ MTS minimunTemporalSupport 90 ∆t THU temporalHistogramUnit 20 TU temporalUnit default (DAY) θ MC minimumConfidence 0.8 I outputItemsets default (false) IL logItemsets true

Tabla 6.5. Parámetros utilizados en las pruebas de performance sobre tiempo en función de

la cantidad de timestamps


88

En la tabla 6.7 se muestras los resultados de los tiempos de ejecución de las pruebas realizadas. En las figuras 6.1, 6.2 y 6.3 se muestran los gráficos de los tiempos de ejecución en función de la cantidad de instantes de medición. Se debe tener en cuenta que el tiempo mostrado corresponde al tiempo total del algoritmo, dado por el tiempo en descubrir los itemsets frecuentes mas el tiempo en obtener las reglas de asociación espacio-temporales en base los mismos.

Prueba 1 Prueba 2 Prueba 3

Estaciones de

medición (6) B3390, C1100, C4080, N1200, N1470, P5100

B3280, C3120, N1360, N4020, P4210, R5220

C2720, C3240, N1160, N1390, P4170, S4510

Cantidad de intervalos discretización volume_9300_kcal 5 6 6

heating_value 3 4 4

diff_pressure 2 no utilizada (valores nulos) 6

pressure 2 5 5

temperature 4 7 8

16 22 29

Tabla 6.6. Valores seleccionados para los datasets de las pruebas de performance sobre

tiempo en función de la cantidad de timestamps

Prueba 1 Prueba 2 Prueba 3 cant.

time-

stamp

cant.

regis-

tros

time-

stamp

final

tiempo total (segs.)

tiempo

ST-

Apriori

tiempo

armado

reglas

tiempo

total

(segs.)

tiempo

ST-

Apriori

tiempo

armado

reglas

tiempo

total

(segs.)

tiempo

ST-

Apriori

tiempo

armado

reglas

150 900 30/05 223.953 220.328 3.61 34.687 34.547 0.14 62.515 61.875 0.64

175 1050 24/06 429.922 417.266 12.656 47.203 47.031 0.172 76.469 75.703 0.75

200 1200 19/07 516.36 501.11 15.25 54.75 54.547 0.203 150.125 148.469 1.656

225 1350 13/08 798.985 766.5 32.485 88.437 88.078 0.359 271.656 266.625 5.031

250 1500 07/09 1017.297 976.359 40.938 157.281 156.078 1.203 517.844 500.797 17.047

277 1662 04/10 1161.359 1119.671 41.688 186.672 185.391 1.281 590.922 573.797 17.125

305 1830 01/11 1397.703 1350.563 47.14 204.266 202.969 1.297 688.406 672.328 16.078

335 2010 01/12 2649.297 2502.594 146.703 280.094 277.328 2.766 655.234 639.359 15.875

365 2190 31/12 3168.687 2961.75 206.937 327.75 324.797 2.953 747.656 731.422 16.234

Tabla 6.7. Resultados de las pruebas de performance sobre tiempo en función de la cantidad de timestamps


89

223.953

429.922

516.36

798.985

1017.297

1161.359

1397.703

2649.297

3168.687

0

500

1000

1500

2000

2500

3000

3500

100 150 200 250 300 350 400

cantidad timestamp

tiempo total

Figura 6.1. Gráfico de resultados de la prueba de performance 1 sobre tiempo en función de


34.687

47.20354.75

88.437

157.281

186.672

204.266

280.094

327.75

0

50

100

150

200

250

300

350

100 150 200 250 300 350 400

cantidad timestamp

tiempo total



62.51576.469

150.125

271.656

517.844

590.922

688.406

655.234

747.656

0

100

200

300

400

500

600

700

800

100 150 200 250 300 350 400

cantidad timestamp

tiempo total




90

En los tres gráficos se puede observar una tendencia lineal, aunque con algunos desvíos en la misma, en ascenso y descenso, siendo en algunos casos más marcados que otros. Estos desvíos en las curvas se pueden deber al uso de datos experimentales en las pruebas, y la selección de los mismos; ya que al tomarse los datos de diferentes estaciones de medición los desvíos son de diferente tipo, tanto en cantidad como en intensidad. Además, hay que tener en cuenta que dentro de una prueba, si bien se trato de seleccionar un conjunto de itemsets I que sea lo mas parecido entre las diferentes ejecuciones de la misma, siempre aparecieron diferencias respecto al tamaño de los conjuntos de discretización, las que habrán influido en los resultados obtenidos. De esta manera, se puede señalar que los algoritmos implementados presentan un comportamiento lineal en función del tamaño del dataset, cuando este dataset aumenta en cantidad de timestamps. Se pueden comparar los resultados experimentales obtenidos, con el análisis de complejidad planteado en la sección 4.1.1.4, del capítulo 4. Teniendo en cuenta la expresión general de la complejidad del algoritmo STApriori, presentada en esa sección, los elementos |I| y |GPD| de la misma son constantes en esta prueba, ya que el primero se definió de manera fija en el filtro Discretize, y el segundo corresponde a las estaciones de medición seleccionadas al inicio de cada prueba. De esta manera la expresión queda lineal respecto a |D|. Este parámetro coincide con la cantidad de timestamps de cada paso de la prueba, como se comentó anteriormente, ya que cada transacción del dataset del modelo se encuentra asociada a un solo timestamp. Un detalle a tener en cuenta en esta comparación es que el análisis de complejidad se refiere al algoritmo STApriori y los gráficos muestran los tiempos totales, sumando el algoritmo STApriori con el algoritmo de armado de reglas. Mirando la tabla de resultados que muestra los tiempos totales y los de cada algoritmo en las pruebas, se observa que, dentro un punto de una prueba, el tiempo del algoritmo de armado de reglas es bastante pequeño respecto al tiempo de ejecución del algoritmo STApriori. Por lo tanto, se puede suponer que la influencia del tiempo de ejecución del algoritmo de armado de las reglas es lo suficientemente pequeña como para poder ser omitida en el análisis de complejidad del tiempo total.

6.2.2.2.Tiempo en función de la cantidad de sensores

Para este caso se tomo una cantidad fija de timestamps, y dentro de los mismos se fueron seleccionando los correspondientes registros cuyos sensores se encontraban dentro de los elegidos para cada punto de la prueba. El conjunto de sensores se hallaba compuesto inicialmente de 4 estaciones de medición, y los elementos del mismo fueron aumentando hasta llegar a 12. Los timestamps de los registros se tomaron contiguos desde el inicio del dataset hasta llegar a 10 meses; totalizando 304 transacciones para el dataset del modelo, las cuales aumentaban su tamaño para los diferentes conjuntos de sensores seleccionados. Para este caso, el filtro de discretización seleccionado también fue Discretize. El esquema de discretización fue el mismo de la prueba anterior, tratando de mantener los elementos del conjunto de items I sin variaciones considerables entre los diferentes puntos de la prueba. Aunque para este caso, el dataset de mayor tamaño sobre el cual se seleccionaron inicialmente la cantidad de intervalos de discretización fue el correspondiente a las 12 estaciones de medición. Luego los valores definidos se fueron verificando con el mismo criterio para los diferentes datasets, correspondientes a los conjuntos de sensores seleccionados. Debido a los altos valores de tiempos de ejecución obtenidos en la primera prueba se decidió realizar una segunda, restringiendo el tamaño del dataset y los parámetros definidos. En la misma, para el dataset se tomo una cantidad menor de timestamps, correspondiente a 9 meses.


91

De esta manera, el dataset del modelo para la segunda prueba contenía 273 transacciones. También se seleccionaron otros conjuntos de estaciones de medición, y se aumento la cantidad de intervalos de discretización seleccionados, aunque tratando de aplicar el mismo criterio que en la primera prueba para la determinación de los mismos. Respecto a los parámetros, se aumentaron los valores de los tres parámetros umbrales: soporte, soporte temporal y confianza. En las tablas 6.8 y 6.9 se muestran las estaciones de medición seleccionadas para cada prueba y la cantidad de intervalos de discretización determinados. En la tabla 6.10 se muestran los parámetros ingresados al algoritmo.

Cantidad de estaciones

de medición Prueba 1 Prueba 2

4 B3390, C4080, N1470, P5100 C3120, N1360, N2440, P4170 6 C1100, N1200 B3280, N4020 8 P5020, C2790 C3240, P4210

10 C2830, N1280 C2720, N1390 12 N2380, P5541 N1160, S4510

Tabla 6.8. Estaciones de medición seleccionadas para los datasets de las pruebas de

performance sobre tiempo en función de la cantidad de sensores

Variable Prueba 1 Prueba 2

volume_9300_kcal 5 6

heating_value 2 6

diff_pressure 2 7

pressure 3 7

temperature 4 8

16 34

Tabla 6.9. Cantidad de intervalos de discretización seleccionados para los datasets de las

pruebas de performance sobre tiempo en función de la cantidad de sensores

Parámetros SpatioTemporalApriori Valores Pará-

metros

algorit-

mos

Línea de comandos

Interfaz Gráfica Prueba 1 Prueba 2



P

P2 component2LimitsAndLabels default σ MS minimumSupport 0.8 0.85 τ MTS minimunTemporalSupport 100 110 ∆t THU temporalHistogramUnit 30 TU temporalUnit default (DAY) θ MC minimumConfidence 0.85 0.9 I outputItemsets default (false) IL logItemsets true

Tabla 6.10. Parámetros utilizados en las pruebas de performance sobre tiempo en función

de la cantidad de sensores


92

En la tabla 6.11 se muestras los resultados de los tiempos de ejecución de las pruebas realizadas. En las figuras 6.4 y 6.5 se muestran los gráficos de los tiempos en función de la cantidad de sensores seleccionada. Se debe tener en cuenta que el tiempo mostrado corresponde en este caso al tiempo en descubrir los itemsets frecuentes, dado por el algoritmo STApriori.

Para este caso se observa en las pruebas realizadas un comportamiento marcadamente creciente. Si bien el mismo no es conveniente, se debe considerar que el aumento del dataset base, provisto por el usuario, se da comúnmente agregando registros donde se aumente la cantidad de timestamps al mismo. En general, la cantidad de sensores es algo que no aumenta de la misma manera que la cantidad de timestamps. Este comportamiento es esperable en el modelo planteado, ya que el dataset de entrada al mismo (D) tiene sus transacciones identificadas solamente por timestamp. De esta manera, un incremento en la cantidad de sensores implica un aumento en el tamaño de las transacciones del dataset del modelo. Los resultados experimentales de estas pruebas también pueden ser comparados con el análisis de complejidad desarrollado anteriormente en el capítulo 4. Teniendo en cuenta la

Prueba 1 Prueba 2

cantidad

de

sensores

cantidad

de

registros

tiempo

STApriori

(segs.)

cantidad

de

registros

tiempo

STApriori

(segs.)

4 1216 27.828 1092 4.656

6 1824 456.469 1638 142.719

8 2432 3303.641 2184 1289.594

10 3040 21436.328 2730 7718.563

12 3648 135829.672 3276 24608.344

Tabla 6.11. Resultados obtenidos en las pruebas de performance sobre tiempo en función de

la cantidad de sensores

27.828 456.4693303.641

21436.328

135829.672

0

20000

40000

60000

80000

100000

120000

140000

160000

2 4 6 8 10 12 14

cantidad sensores

tiempo STApriori


la cantidad de sensores geográficos


93

expresión de complejidad general planteada, |I| se mantiene fijo durante la prueba, ya que la cantidad de intervalos de discretización –cuya suma para cada atributo determina este parámetro- fue definida al inicio de cada prueba, siendo este valor dado como entrada al filtro de discretización. Para el caso de |D|, como se señalo al inicio de esta sección, al estar asociada cada transacción del modelo con cada timestamp, este valor también se mantuvo fijo durante la prueba. En el caso de |GPD|, fue el parámetro de entrada que vario para cada punto de la prueba. De esta manera, el comportamiento teórico de esta prueba es el de un polinomio de grado 3. Esto permite confirmar los resultados experimentales, ya que las curvas presentadas se pueden ajustar por una de este tipo.

4.656 142.719

1289.594

7718.563

24608.344

0

5000

10000

15000

20000

25000

30000

2 4 6 8 10 12 14

cantidad sensores

tiempo STApriori


la cantidad de sensores geográficos



Interfaz Gráfica Valores



P

P2 component2LimitsAndLabels default τ MTS minimunTemporalSupport 80 ∆t THU temporalHistogramUnit 20 TU temporalUnit default (DAY) θ MC minimumConfidence 0.7 I outputItemsets default (false) IL logItemsets true

Tabla 6.12. Parámetros utilizados en la prueba de performance sobre cantidad de itemsets

frecuentes en función del umbral de soporte


94

6.2.2.3.Cantidad de itemsets en función del umbral de soporte

Para este caso el dataset seleccionado se mantuvo fijo entre los diferentes puntos de la prueba, y se fue variando, dentro de los parámetros del algoritmo STApriori, el umbral de soporte. Para el dataset se seleccionaron todos los timestamp correspondientes a un año, y cinco estaciones de medición, cuyos código fueron: B3390, C2830, N1280, N1470, P5541. De esta manera el dataset base contiene 1825 registros, y el dataset del modelo 365 transacciones. Considerando que en este caso el dataset no varía entre los diferentes puntos de la prueba, se selecciono como filtro de discretización ClusterDiscretize. El algoritmo de clustering definido





1 7.1422 5.5239 VOLUME_9300_KCAL_VL 2 37.4244 11.0626 VOLUME_9300_KCAL_L 3 884.9571 464.8428 VOLUME_9300_KCAL_ML 4 1730.5813 109.8163 VOLUME_9300_KCAL_MH 5 2029.8655 113.8877 VOLUME_9300_KCAL_H 6 2495.8951 197.5769 VOLUME_9300_KCAL_VH





1 37.5756 0.0469 HEATING_VALUE_VL 2 37.6376 0.1287 HEATING_VALUE_L 3 38.5659 0.0433 HEATING_VALUE_M 4 38.7334 0.5321 HEATING_VALUE_H 5 38.9562 0.0336 HEATING_VALUE_VH

Atributo diff_pressure




1 0.0005 0.0011 DIFF_PRESSURE_L 2 0.0418 0.0284 DIFF_PRESSURE_H

Atributo pressure




1 3.2503 3.4026 PRESSURE_L 2 20.4925 0.6026 PRESSURE_M 3 52.9591 1.6555 PRESSURE_H





1 15 0.0001 TEMPERATURE_VL 2 18.3603 4.6299 TEMPERATURE_L 3 24.1713 1.0437 TEMPERATURE_H 4 27.6769 3.1811 TEMPERATURE_VH

Tabla 6.13. Conjuntos de discretización de los atributos de la prueba de performance sobre

cantidad de itemsets frecuentes en función del umbral de soporte


95

para el mismo fue EM, con sus parámetros default de Weka. En la tabla 6.13 se muestra los conjuntos de discretización obtenidos con el mismo. El umbral de soporte se definió inicialmente en 0.8 y se fue disminuyendo su valor hasta 0.2. Los valores de los otros parámetros del algoritmo se muestran en la tabla 6.12. En la tabla 6.14 se muestran los resultados obtenidos, mientras que en la figura 6.6 se muestra la representación gráfica de los mismos.

Se observa para esta prueba que el algoritmo presenta un comportamiento marcadamente creciente. El mismo es el comportamiento esperado, ya que al disminuirse el umbral de soporte aumenta la cantidad de itemsets descubiertos. Además, en cada una de las iteraciones del algoritmo STApriori, al descubrirse una mayor cantidad de itemsets frecuentes, se genera una mayor cantidad de itemsets candidatos en la iteración siguiente, de los cuales una mayor cantidad serán frecuentes por haberse disminuido el umbral de soporte. Si se representa gráficamente el tiempo del algoritmo STApriori en función del umbral de soporte, se obtiene la figura 6.7. Se observa que en este caso el comportamiento también es marcadamente creciente, similar al del caso anterior. De esta manera, se puede señalar que existe una relación lineal entre la cantidad de itemsets frecuentes descubiertos y el tiempo en descubrir los mismos. La misma se confirma si se representan gráficamente los valores obtenidos de tiempo de ejecución en función de la cantidad de itemsets descubiertos, según como se muestra en la figura 6.8. El comportamiento mostrado en el gráfico de esta figura también es el esperado por el algoritmo, ya que en cada iteración se genera una mayor cantidad de itemsets candidatos, debido a la mayor cantidad de itemsets frecuentes de la etapa anterior, los cuales deben ser contabilizados para determinar si son frecuentes o no. De esta manera, la etapa que tiene un mayor costo temporal asociado dentro del algoritmo tiene una mayor duración debido a un aumento de los elementos que componen la entrada de la misma, aumentándose los tiempos de ejecución del algoritmo STApriori.

umbral soporte

(parámetro MS)

cantidad itemsets

frecuentes

tiempo STApriori

(segs.)

0.8 7740 253.125

0.6 18556 535.891

0.4 41832 1183.766

0.3 61366 1890.063

0.2 108362 3472.891

Tabla 6.14. Resultados obtenidos en la prueba de performance sobre cantidad de itemsets

frecuentes descubiertos en función del umbral de soporte


96

7740

18556

41832

61366

108362

0

20000

40000

60000

80000

100000

120000

0.10.20.30.40.50.60.70.80.9

umbral soporte

cantidad itemsets

Figura 6.6. Gráfico de resultados de prueba de performance sobre cantidad de itemsets

frecuentes en función del umbral de soporte

253.125

535.891

1183.766

1890.063

3472.891

0

500

1000

1500

2000

2500

3000

3500

4000

0.10.20.30.40.50.60.70.80.9

umbral soporte

tiempo STApriori

Figura 6.7. Tiempo de descubrimiento de itemsets frecuentes en función del umbral de

soporte, para resultados obtenidos en prueba de performance sobre cantidad de itemsets en

función del umbral de soporte

253.125

535.891

1183.766

1890.063

3472.891

0

500

1000

1500

2000

2500

3000

3500

4000

0 20000 40000 60000 80000 100000 120000

cantidad itemsets

tiempo STApriori

Figura 6.8. Tiempo de ejecución en función de la cantidad de itemsets descubiertos, para

resultados de prueba de performance sobre cantidad de itemsets en función del umbral de

soporte


97

6.2.2.4.Cantidad de itemsets en función del umbral de soporte temporal

Para este caso se mantuvo fijo entre los diferentes puntos de la prueba el dataset seleccionado, aumentándose, entre los parámetros del algoritmo STApriori, el umbral de soporte temporal. Debido a que para esta prueba, al igual que para la prueba anterior, el dataset tampoco vario entre los diferentes puntos de la misma, se decidió seleccionar el mismo dataset que el utilizado en la prueba anterior, incluyendo las mismas configuraciones de filtro de discretización aplicado. Teniendo en cuenta que la amplitud temporal del dataset es de 365 días, el umbral de soporte temporal se definió inicialmente en 300 días. Luego, su valor se fue disminuyendo hasta llegar a 60 días. Los valores de los otros parámetros del algoritmo se muestran en la tabla 6.15.

Los resultados obtenidos se muestran en la tabla 6.16. En la figura 6.9 se muestra el gráfico de los resultados obtenidos.

Se observa que para esta prueba el comportamiento del algoritmo es marcadamente creciente, siendo similar al de la prueba anterior. Este es el comportamiento esperado del algoritmo STApriori, ya que al disminuirse el umbral de soporte temporal se descubre una mayor cantidad de itemsets frecuentes, debido a que se permite que sea de menor tamaño los



Interfaz Gráfica Valores



P

P2 component2LimitsAndLabels default σ MS minimumSupport 0.5 ∆t THU temporalHistogramUnit 15 TU temporalUnit default (DAY) θ MC minimumConfidence 0.7 I outputItemsets default (false) IL logItemsets true

Tabla 6.15. Parámetros utilizados en la prueba de performance sobre cantidad de itemsets

frecuentes descubiertos en función del umbral de soporte temporal

umbral

soporte

temporal

(parámetro

MTS)

%

timestamp

dataset

tiempo

total (segs.)

tiempo

STApriori

tiempo

armado

reglas

cantidad

de

itemsets

cantidad

de

reglas

300 80 122.547 122.297 0.25 1514 15063

240 66 161.125 159.5 1.625 3169 51797

180 50 294.563 280.094 14.469 8037 219267

120 33 642.766 544.688 98.078 19210 646481

60 16 1419.64 1014.687 404.953 36169 1233886

Tabla 6.16. Resultados obtenidos de la prueba de performance sobre cantidad de itemsets

frecuentes descubiertos en función del umbral de soporte temporal


98

intervalos donde los itemsets son frecuentes. Luego, entre las iteraciones del algoritmo, el comportamiento ocurre de manera similar a lo explicado para la prueba anterior, respecto a que se van generando en cada iteración una mayor cantidad de itemsets candidatos. Para esta prueba además se decidió analizar en base a los resultados la cantidad de reglas obtenidas en función de los itemsets frecuentes descubiertos, comportamiento determinado por la implementación del algoritmo que extiende a Faster Algorithm ([3]), explicada en la sección 4.1.2 del capítulo 4. La figura 6.10 muestra el gráfico correspondiente a esta relación. Se observa experimentalmente un comportamiento marcadamente lineal de este algoritmo. Este comportamiento es compatible con el funcionamiento teórico del algoritmo, ya que este arma las reglas para cada uno de los itemsets frecuentes descubiertos en base a los items y predicados espaciales que componen el mismo, recorriendo una sola vez el conjunto de itemsets frecuentes.

1514

3169

8037

19210

36169

0

5000

10000

15000

20000

25000

30000

35000

40000

050100150200250300350

umbral soporte temporal

cantidad itemsets

Figura 6.9. Gráfico de resultados de prueba de performance sobre cantidad de itemsets

frecuentes en función del umbral de soporte temporal

15063

51797

219267

646481

1233886

0

200000

400000

600000

800000

1000000

1200000

1400000

0 5000 10000 15000 20000 25000 30000 35000 40000

cantidad itemsets

cantidad reglas

Figura 6.10. Cantidad de reglas obtenidas en función de la cantidad de itemsets frecuentes

descubiertos, para prueba de performance sobre cantidad de itemsets frecuentes en función

del umbral de soporte temporal


99

7. Conclusiones

En este trabajo se desarrolló un modelo de reglas de asociación espacio-temporales, que permite obtener las mismas desde bases de datos con transacciones que presentan componentes espaciales y temporales. En el armado de este modelo se tuvieron en cuenta las características de determinados modelos existentes para el descubrimiento de reglas de asociación temporales, reglas de asociación espaciales y reglas de asociación inter-transacciones, de forma de obtener un nuevo modelo que integre los conceptos de los distintos modelos seleccionados, de una manera adecuada para expresar los conocimientos, espacial y temporal, involucrados en las reglas. El conocimiento espacial se representa relacionando todos los elementos de la regla entre sí, respecto a un mismo elemento, sin restringirse la relación espacial, y utilizando la notación de predicados espaciales, de uso común en los modelos de reglas de asociación espaciales ([18], [33], y [24]). El conocimiento temporal se representa mediante intervalos de ocurrencia, los que dependen solamente de las características propias de los datos de entrada. Se desarrolló un algoritmo para el descubrimiento de las reglas de asociación espacio-temporales definidas por el modelo. El modelo desarrollado verifica, de manera extendida, la Propiedad de Monotonía de Apriori ([3]). De esta manera, el algoritmo para el descubrimiento de los itemsets frecuentes fue basado en el algoritmo Apriori. Para esto, al algoritmo Apriori se le incorporaron determinadas extensiones, las que pueden ser aplicadas también a otros algoritmos para el descubrimiento de itemsets frecuentes. En cuanto a las restricciones impuestas a las estructuras de las bases de datos sobre las cuales se descubren las reglas, se eligieron las más convencionales posibles. La intención en este caso fue que el modelo se aplique sobre diversas estructuras de fuentes de datos lo más directamente posible o con poco preprocesamiento. Para este último caso, se desarrollaron algoritmos adicionales de preprocesamiento, en base a las estructuras de datos planteadas y a características observadas en los datos durante las pruebas realizadas. Los algoritmos se implementaron en Java, como parte del sistema Weka ([44]). Respecto al algoritmo para el descubrimiento de las reglas, fue desarrollado de manera que pueda ser extendido con otros esquemas de representación de relaciones espaciales, así como otros esquemas de cálculo de las mismas que pudieran ser necesarios en otros datasets. El modelo propuesto presenta utilidad de uso en diversas áreas. En primer lugar, se aplicó la implementación desarrollada sobre datasets de ejemplo del área de transporte de gas, pudiendo encontrar diversos patrones de utilidad de uso. Asimismo, se han presentado otros tipos de datasets donde se encontró utilidad de uso del modelo para el análisis de los mismos. Se analizo la complejidad del algoritmo propuesto, llegando a una expresión que señala un comportamiento lineal del algoritmo en el caso más convencional de uso del modelo –el aumento de la cantidad de registros con el avance del tiempo-. Luego, se verifico este comportamiento mediante la realización de pruebas de performance en base a la implementación desarrollada, y utilizando datasets de uso real. Además, estas pruebas mostraron el funcionamiento de los parámetros umbrales del algoritmo, junto al comportamiento del algoritmo implementado para el armado de reglas.


100

7.1. Trabajo futuro

Como trabajo futuro, se pueden considerar tres alternativas de extensión de esta tesis. En primer lugar, se puede analizar la necesidad de mejoras de performance mediante el desarrollo de un nuevo algoritmo para el descubrimiento de itemsets frecuentes. Para el mismo, se pueden considerar mejoras respecto al esquema utilizado en el ciclo de verificación y contabilización del algoritmo actual presentado en esta tesis. Otra opción puede ser aplicar modificaciones similares a las realizadas sobre Apriori, en otros algoritmos para el descubrimiento de itemsets frecuentes más eficientes que este, como por ejemplo en FP-Growth ([16]). Por otro lado, se puede considerar extender el modelo para que sea aplicado sobre datasets compuestos por objetos móviles, similares a los utilizados en los trabajos [41] y [15]. En este caso, los items son registrados en diferentes posiciones geográficas e instantes de tiempo por objetos, que tienen características propias que los identifican y diferencian respecto a otros objetos. Se podría considerar, además de indicar la relación espacial entre las posiciones de los items registrados, señalar determinados valores en común de los atributos que representan las características de los objetos móviles que registraron los items. De esta manera, las reglas descubiertas mostrarían la asociación espacio-temporal entre items registrados por objetos con similares características. El modelo presentando mostraba todas las reglas descubiertas en base a los parámetros dados. Una última alternativa de trabajo futuro sería considerar el desarrollo de opciones de postprocesamiento de las reglas obtenidas, en base a características propias de las mismas, que puedan ser de ayuda al momento de necesitar obtener el conocimiento aportado por las reglas descubiertas. En este caso algunas opciones pueden ser: • agrupar las reglas que contienen los mismos items y diferentes relaciones espaciales.

Se pueden señalar las diferencias entre los conjuntos de relaciones espaciales, junto con los intervalos de ocurrencia de los mismos

• mostrar las diferentes reglas posibles agrupadas por un mismo conjunto de relaciones espaciales y/o bajo determinados intervalos de ocurrencia

• presentar las reglas en base a ciertas prioridades identificadas por características de las relaciones espaciales y/o intervalos de ocurrencia. Por ejemplo: “mostrar primero las reglas que abarcan relaciones espaciales de mayor distancia e intervalos de ocurrencia menores”. Se podría utilizar también como una alternativa de selección de reglas.


101

Bibliografía

[1] Adhikary J., et. al.. “Knowledge Discovery in Spatial Databases: Progress and Challenges”.

Proceedings of the SIGMOD Workshop on Research Issues on Data Mining and Knowledge

Discovery, Technical Report 96-08. Universidad de British Columbia. Vancouver, Canada. 1996.

[2] Agrawal, R., et. al.. “Mining Association Rules between Sets of Items in Large Databases”. Proceedings of the ACM SIGMOD Conference on Management of Data. Washington, Estados Unidos. Mayo/1993. págs. 207-216

[3] Agrawal, R., Srikant, R. “Fast Algorithms for Mining Association Rules”. Proceedings of the 20th Int. Conf. on Very Large Data Bases. Editorial Morgan Kaufmann. Santiago, Chile. Septiembre/1994. Version expandida: IBM Research Report RJ9839, Junio/1994

[4] Ale, J., Rossi, G.. “An Approach to Discovering Temporal Association Rules”. Proceedings of the 2000 ACM symposium on Applied Computing. Editorial ACM. Como, Italia. 2000. págs. 294-300

[5] Ale, J., Rossi, G.. “The Itemset’s Lifespan Approach to Discovering General Temporal Association Rules”. Proceedings of the Second Workshop on Temporal Data Mining in SIGKDD 2002, The

Eighth ACM SIGKDD International Conference on Knowledge Discovery and Data Mining. Edmonton, Canada. Julio/2002. págs. 1-10

[6] Chien, B., et. al.. “An Efficient Clustering Algorithm for Mining Fuzzy Quantitative Association Rules”. Proceedings of the Joint 9th IFSA World Congress and 20

th NAFIPS International

Conference. Vancouver, Canada. Julio/2001. págs. 1306-1311, volumen 3

[7] Croxford, B.. “Streebox Urban Pollution Monitor”. Internet: http://www.bartlett.ucl.ac.uk/web/ben/streetbox.htm. Acceso: 29/10/2007

[8] Croxford, B.. “Urban Pollution”. Internet : http://www.bartlett.ucl.ac.uk/web/ben/. Acceso : 29/10/2007

[9] Defra. “Noise mapping England”. Internet : http://www.noisemapping.org/Default.asp. Acceso: 29/10/2007

[10] Ester. M., et. Al.. “Algorithms and Applications for Spatial Data Mining”. Geographic Data Mining and Knowledge Discovery, Research Monographs in GIS. Editorial Taylor and Francis. Noviembre/2001.

[11] Frawley, W., et. al. “Knowledge Discovery in Databases: An Overview”. Knowledge Discovery in Databases. AAAI/MIT Press. Estados Unidos.1991. págs. 1-30. Reimpreso en AI Magazine, 1992, págs. 57-60

[12] Gcba. “Calidad ambiental. Laboratorio. Monitoreo atmosférico”. gobBsAs. Internet: http://www.buenosaires.gov.ar/areas/gob_control/aire/. Acceso: 29/10/2007

[13] “Home”. GeoTools. The open source Java GIS toolkit. Internet: http://geotools.codehaus.org/. Acceso: 20/06/2007

[14] Gidófalvi, G.. “Spatio-temporal Data Mining for Location-based Services (Industrial Ph.D. study proposal at Aalborg University)”. Dinamarca. 2004. Internet: http://www.cs.aau.dk/~gyg/. Acceso: 27/11/2005

[15] Gidófalvi, G., Bach Pedersen, T.. “Spatio–temporal Rule Mining: Issues and Techniques”. Proceedings of 7

th International Conference On Data Warehousing And Knowledge Discovery,

LNCS 3589. Editorial Springer-Verlag. Copenhague, Dinamarca. Agosto/2005. págs. 275-284

[16] Han, J., et. al.. “Mining Frequent Patterns without Candidate Generation”. Proceedings of the 2000


102

ACM SIGMOD International Conference on Management of Data. Editorial ACM Press. Dallas, Estados Unidos. 2000. págs. 1-12

[17] Harms, S., et. al.. “Efficient Rule Discovery in a Geo-spatial Decision Support System”. Proceedings of the 2002 Annual National Conference on Digital Government Research. Los Angeles, Estados Unidos. Mayo/2002. págs. 235-241

[18] Koperski, K., Han J., “Discovery of Spatial Association Rules in Geographic Information Databases”. Proceedings 4th Int. Symp. Advances in Spatial Databases. Editorial Springer-Verlag. Portland, Estados Unidos. Agosto/1995. págs. 47-66

[19] Lee, Ickjai. “Mining Multivariate Associations within GIS Environments”. Proceedings of the 17th International Conference on Innovations in Applied Artificial Intelligence. Editorial Springer-Verlag. Ottawa, Canada. Mayo/2004. págs. 1062-1071

[20] Lee, E., Chan, K.. “Discovering Association Patterns in Large Spatio-temporal Databases”. Proceedings of the 6

th IEEE International Conference on Data Mining – Workshops 2006. Hong

Kong, China. Diciembre/2006. págs. 349-354

[21] Li, D., Deogun, J.. “Spatio-Temporal Association Mining for Un-sampled Sites”. Proceedings of the 14

th International Symposium on Methodologies for Intelligent Systems, LNCS 2871. Editorial

Springer-Verlag. Maebashi, Japón. Octubre/2003. págs. 478-485

[22] Lu, H., et. al.. “Stock Movement Prediction And N-Dimensional Inter-Transaction Association Rules”. Proceedings of the ACM SIGMOD Workshop on Research Issues on Data Mining and

Knowledge Discovery. Seattle, Washington. Junio/1998. págs. 12:1-12:7

[23] Lu, H., et. al.. “Beyond Intra-Transaction Association Analysis: Mining Multi-Dimensional Inter-Transaction Association Rules”. ACM Transactions on Information Systems, Volume 18, Issue 4. Nueva York, Estados Unidos. Octubre/2000. págs. 423-454

[24] Malerba, D., et.al.. “Mining Spatial Association Rules in Census Data”. Proceedings of the Joint Conferences on "New Techniques and Technologies for Statistics" and "Exchange of Technology

and Know-how". 2001. págs. 541-550

[25] Mennis, J., Liu, J. W.. “Mining Association Rules in Spatio-Temporal Data”. Proceedings of the 7th International Conference on Geocomputation. Reino Unido. Séptiembre/2003

[26] Miller, R., Yang, Y.. “Association Rules over Interval Data”. Proceedings of the 1997 ACM

SIGMOD International Conference on Management of Data. Tucson, Estados Unidos. Mayo/1997. págs. 452-461

[27] Ministerio de Defensa. Secretaría de Planeamiento. “Servicio Meteorológico Nacional”. Internet: http://www.smn.gov.ar/. Acceso : 03/11/2007

[28] Özden, B., et. al.. “Cyclic Association Rules”. Proceedings of the 14th International Conference on Data Engineering. Orlando, Estados Unidos. Febrero/1998. págs. 412-421

[29] Rainsford, C., Roddick, J.. “Adding Temporal Semantics to Association Rules”. Proceedings of the Third European Conference on Principles of Data Mining and Knowledge Discovery. Editorial Springer-Verlag. Praga, Rep. Checa. Septiembre/1999. págs. 504-509

[30] Ramaswamy, S., et. al.. “On the Discovery of Interesting Patterns in Association Rules”. Proceedings of 24

th Int. Conf. Very Large Data Bases. Nueva York, Estados Unidos. Agosto/1998.

págs. 368-379

[31] Roddick, J.F., et. al. . “YABTSSTDMR - Yet Another Bibliography of Temporal, Spatial and Spatio-Temporal Data Mining Research”. Proceedings of the Temporal Data Mining Workshop in

7th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining. San

Francisco, Estados Unidos. Agosto/2001. págs. 167-175

[32] “Air Quality”. RouteSafe Ltd. Internet : http://www.routesafe.co.uk/products/airquality.html.


103

Acceso: 29/10/2007

[33] Salleb, A., Vrain, C.. “An Application of Association Rules Discovery to Geographic Information Systems”. Proceedings of Principles of Data Mining and Knowledge Discovery: 4

th European

Conference. Editorial Springer-Verlag. Lyon, Francia. Septiembre/2000. págs. 613-618

[34] Srikant, R., Agrawal, R.. “Mining Quantitative Association Rules in Large Relational Tables”. Proceedings of the 1996 ACM SIGMOD International Conference on Management of Data. Montreal, Canada. Junio/1996. págs. 1-12

[35] Su, Fenzhen, et. al.. “Geo-event association rule discovery model based on rough set with marine fishery application”. Proceedings of the 2004 IEEE International Geoscience and Remote Sensing Symposium. Estados Unidos. Septiembre/2004. págs. 1455-1458, volumen 2

[36] Tan, P., et. al.. “Finding Spatio-Temporal Patterns in Earth Science Data”. Proceedings of the Temporal Data Mining Workshop in 7

th ACM SIGKDD International Conference on Knowledge

Discovery and Data Mining. San Francisco, Estados Unidos. Agosto/2001.

[37] Tsoukatos, I., Gunopulos, D.. “Efficient Mining of Spatiotemporal Patterns”. Proceedings of the 7th International Symposium on Advances in Spatial and Temporal Databases, LNCS 2121. Editorial Springer-Verlag. California, Estados Unidos. Julio/2001. págs. 425-442

[38] Tung, A., et. al.. “Efficient Mining of Intertransaction Association Rules”. IEEE Transactions on Knowledge and Data Engineering, Vol. 15, No. 1. Piscataway, Estados Unidos. Enero/2003. págs. 43-56

[39] University of London. “The London Air Quality Network”. Internet: http://www.londonair.org.uk/london/asp/default.asp. Acceso: 29/10/2007

[40] Vannucci, M., Colla, V.. “Meaningful discretization of continuous features for association rules mining by means of a SOM”. Proceedings of the 12th European Symposium on Artificial Neural Networks. Brujas, Bélgica. Abril/2004. págs. 489-494

[41] Verhein, F., Chawla, S. “Mining Spatio-temporal Association Rules, Sources, Sinks, Stationary Regions and Thoroughfares in Object Mobility Databases”. Proceedings of the 11th International Conference on Database Systems for Advanced Applications, LNCS 3882. Singapur. Abril/2006. págs. 187-201

[42] Wang, W., et. al.. “TAR: Temporal Association Rules on Evolving Numerical Attributes”. Proceedings of the 17

th Intenational Conference on Data Engineerig. Editorial IEEE Computer

Society. Heidelberg, Alemania. Abril/2001. págs. 283-292

[43] “Geographic information system”. Wikipedia. Internet: http://en.wikipedia.org/wiki/GIS. Acceso: 01/07/2007

[44] Witten, I., Frank, E.. “Data Mining: Practical machine learning tools and techniques”, 2nd Edition. Editorial Morgan Kaufmann. San Francisco, Estados Unidos. 2005.


104

Apéndice A. Documentación de desarrollo

A.1. Requisitos del software

A.1.1. Casos de Uso

La figura A.1 muestra el diagrama de casos de uso del software desarrollado.

A continuación se especifican los casos de uso correspondientes al diagrama. CU_01 – Convertir componentes de posiciones geográficas Resumen Se permite la conversión de las componentes de las posiciones geográficas

del dataset de un formato de texto a uno numérico Actores � Analista del dominio: persona con conocimiento del dominio del

dataset sobre el cual se desea descubrir las reglas Precondiciones � Dataset seleccionado y conteniendo componentes de las posiciones

geográficas de tipo texto y con formato [+/-]DDºMM’SS’’, donde DD=grados, MM=minutos, SS= segundos. El signo delante señala el hemisferio y/o latitud, “-” corresponde a hemisferio O y latitud S.

Figura A.1. Diagrama de casos de uso del software desarrollado


105

Flujo principal 1. El sistema pide el ingreso de los parámetros del algoritmo de preprocesamiento: � índices de los atributos del dataset correspondientes a las componentes de las posiciones geográficas

2. El usuario ingresa los parámetros y selecciona procesar 3. El sistema realiza el procesamiento del dataset:

� para cada registro del mismo toma los valores de los atributos indicados y los convierte al formato numérico

4. El sistema devuelve el dataset procesado Excepciones � Paso 3: En el valor de un atributo, el formato no contiene los

símbolos correspondientes a los grados (º) o minutos (”). Se debe dar un mensaje de error informando que no se encontró el símbolo correspondiente.

Postcondiciones � Dataset procesado donde los atributos correspondientes a las componentes de las posiciones geográficas son numéricos, con el formato DD,dddd , en donde “DD” son los grados y “dddd” la parte decimal de los minutos y segundos respecto a estos últimos.

CU_02 - Discretizar atributos continuos Resumen Se permite discretizar los atributos continuos del dataset utilizando un

algoritmo de clustering Actores � Analista del dominio: persona con conocimiento del dominio del

dataset sobre el cual se desea descubrir las reglas Precondiciones � Dataset seleccionado y conteniendo un atributo numérico cuyo

dominio de valores sea continuo, o lo suficientemente amplio como para necesitar ser discretizado

Flujo principal 1. El sistema pide el ingreso de los parámetros del algoritmo de discretización: � índice del atributo a ser discretizado � algoritmo de clustering a ser utilizado, junto con los parámetros correspondientes al mismo


� obtiene los valores del atributo a ser discretizado � aplica el algoritmo de clustering sobre los mismos � el sistema arma un nuevo dataset asignando a cada valor del atributo seleccionado el cluster correspondiente

4. El sistema devuelve el nuevo dataset Postcondiciones � Dataset procesado con el atributo seleccionando conteniendo como

valores la identificación del cluster asignado Notas � El algoritmo de clustering a seleccionar se corresponde con los

disponibles en Weka � La identificación del cluster asignado será numérica. En caso de que el algoritmo de clustering provea características propias representativas de cada cluster descubierto, se utilizaran las mismas para identificar a los clusters asignados.


106

CU_03 - Convertir estructuras de datasets Resumen Se permite la conversión de un dataset con formato determinado (de uso

convencional) a un formato utilizado por el modelo de reglas de asociación espacio-temporales

Actores � Analista del dominio: persona con conocimiento del dominio del dataset sobre el cual se desea descubrir las reglas

Precondiciones � Dataset seleccionado y con el siguiente formato: un atributo conteniendo un instante de tiempo, dos atributos contiguos conteniendo los componentes de la posición geográfica, en formato numérico, y uno o mas atributos adicionales a los anteriores � El dataset se encuentra ordenado por el atributo temporal (el que contiene el instante de tiempo)

Flujo principal 1. El sistema pide el ingreso de los parámetros del algoritmo de conversión entre datasets: � índice del atributo temporal, conteniendo el instante de tiempo � índice del primer atributo de la posición geográfica (considera contiguos a los atributos de las componentes de la posición geográfica)


� para cada grupo de registros con igual instante de tiempo arma un nuevo registro en el dataset de salida con el instante de tiempo del grupo de registros y un dataset interno compuesto por los demás atributos de los registros. En este dataset interno los atributos de las componentes de las posiciones geográficas se ubican en las dos primeras posiciones, sin importar la ubicación en el registro original

4. El sistema devuelve el nuevo dataset Excepciones � Paso 3: los atributos indicados en los parámetros, no corresponden

con los tipos necesarios (fecha para el instante de tiempo y numérico para la posición geográfica). Se debe mostrar un mensaje de error informando cada caso particular.

Postcondiciones � Dataset procesado con el siguiente formato: el atributo temporal conteniendo el instante de tiempo, un dataset interno al registro actual cuyos valores se corresponden con los registros del dataset original para el instante de tiempo actual. El dataset interno tiene el siguiente formato: las dos primeras posiciones se corresponden con los atributos de las componentes de la posición geográfica, los demás son los restantes atributos del dataset en el orden original

CU_04 - Descubrir reglas de asociación espacio-temporales Resumen Permite realizar el descubrimiento de las reglas de asociación espacio-

temporales según el modelo planteado Actores � Analista del dominio: persona con conocimiento del dominio del

dataset sobre el cual se desea descubrir las reglas Precondiciones � Dataset seleccionado y con el formato dado luego de aplicar los

CU_01, CU_02 y CU_03: un atributo temporal y un dataset interno con los registros para cada valor del mismo. Dentro del dataset interno los dos primeros atributos corresponden a las componentes de la posición geográfica en formato numérico DD,dddd , y los demás son los


107

restantes atributos del dataset original, correspondientes a valores discretizados, categóricos o booleanos

Flujo principal 1. El sistema pide el ingreso de los parámetros del algoritmo para el descubrimiento de las reglas de asociación espacio-temporales: � umbral de soporte � umbral de soporte temporal � intervalo unidad de discretización � unidad temporal manejada para los dos parámetros anteriores � conjunto de predicados espaciales P: esquema de cálculo de predicados, límites de los intervalos de discretización de cada parámetro de los predicados espaciales, junto con sus etiquetas identificatorias (opcionales) � umbral de confianza � si se muestran los itemsets descubiertos en la salida del algoritmo

2. El usuario ingresa los parámetros y selecciona iniciar el descubrimiento 3. El sistema realiza el descubrimiento de las reglas del dataset:

� obtiene el conjunto de items posibles en base a los datos de los atributos provistos por el dataset � descubre el conjunto de itemsets frecuentes utilizando el algoritmo STApriori (secciones 4.1.1.1 y 4.1.1.2) � en base a los itemsets frecuentes descubiertos obtiene las reglas de asociación espacio-temporales, aplicando Faster Algorithm con las extensiones propias del modelo (sección 4.1.2)

4. El sistema devuelve el modelo descubierto para el dataset, en base a los parámetros dados, con los siguientes elementos: � especificación de parámetros dados al algoritmo � resumen de cantidad de itemsets y reglas frecuentes descubiertos, y tiempos de ejecución de los algoritmos para el descubrimiento de los mismos � itesmsets frecuentes: para cada tamaño cantidad, y, si corresponde con los parámetros ingresados, los itemsets descubiertos. Los itemsets se numeran dentro del conjunto de cada tamaño. En caso de que el itemset sea frecuente en subintervalos contenidos dentro de su lifespan, se agrega la información correspondiente al lifespan del mismo � reglas de asociación espacio-temporales descubiertas. Las mismas se presentan numeradas.

Postcondiciones � Se descubrieron todas las reglas de asociación espacio-temporales existentes en el dataset de acuerdo a los parámetros dados

Notas � El modelo de reglas de asociación espacio-temporales nombrado fue definido en el capítulo 3 de esta tesis. Los algoritmos correspondientes al mismo se encuentran en el capítulo 4 en las secciones señaladas

A.2. Diseños de clases


108

A.2.1. Algoritmos para el descubrimiento de reglas de asociación espacio-

temporales

La clase SpatioTemporalApriori es la encargada del descubrimiento de las reglas de asociación espacio-temporales. La misma aplica el algoritmo STApriori para el descubrimiento de los itemsets frecuentes y luego el algoritmo para el armado de las reglas en base a los mismos. Hereda de la clase abstracta weka.associations.Associator, provista por Weka ([44]) para el desarrollo de algoritmos de descubrimiento de reglas de asociación. Para el manejo de la representación de los itemsets espacio-temporales se propone la clase SpatioTemporalAprioriItemset, la cual hereda parte de su funcionalidad de weka.associations.ItemSet, provista por Weka. Para el manejo de las reglas a obtener en base a los itemsets espacio-temporales frecuentes se define la clase SpatioTemporalAssociationRule. Weka define la interfaz weka.core.OptionHandler, la cual especifica el comportamiento de elementos que procesan opciones. Esta interfaz es implementada por SpatioTemporalApriori para poder procesar los parámetros propios de los algoritmos. La figura A.2 muestra el diagrama de las clases nombradas. Unos de los parámetros definidos para el algoritmo STApriori es el conjunto de items I, sin embargo el mismo no se da como parámetro a la clase SpatioTemporalApriori. Esto se debe a que esta clase para determinar el conjunto de items del dataset utiliza la información provista por la clase weka.core.Attribute. Esta clase Attribute es instanciada por Weka al obtenerse dentro de la clase weka.core.Instances, la que mantiene al dataset seleccionado. Para permitir obtener una estructura de transacción compuesta por una colección de bitmap o arreglos “atributo-valor”, como se comentó en la sección 4.1.1.1, se manejan transacciones –representadas en la clase Instance de Weka- compuestas por dos tipos de atributos, las que son armadas por el filtro PropositionalToTemporalMultiSpatialInstance. El primer atributo es de tipo “date” y corresponde al instante de tiempo de la transacción. El segundo atributo es de tipo “relational” y permite mantener los items registrados en el instante de tiempo de la transacción actual. Además el valor de este tipo de atributo se implementa como un objeto de tipo Instances, con lo cual representa la colección de “posición-items” de la transacción actual. En este dataset interno los dos primeros atributos son de tipo “numeric” y representan a los componentes de la posición geográfica. Los restantes son los items registrados en la posición actual para el instante de tiempo de la transacción, y son de tipo “nominal”.


109

Respecto a la clase SpatioTemporalAprioriItemset, la estructura que utiliza la misma para representar los items que componen al itemset junto con los predicados espaciales que los relacionan se encuentra compuesta de 3 arreglos:

• m_items: heredado de ItemSet, representa solamente el item principal del itemset –explicado en la sección 3.2 del capítulo 3-. Debido a que los items son manejados como duplas atributo-valor, este arreglo tiene una longitud igual al número de atributos del dataset y almacena en la posición del atributo correspondiente al item principal el valor del mismo, completando las demás posiciones con -1. Respecto al

Figura A.2. Diagrama de clases principales para el descubrimiento de las reglas de asociación

espacio-temporales


110

valor almacenado lo que mantiene siempre es el índice del mismo según la definición del atributo, dada por la clase weka.core.Attribute.

• itemsRelated: mantiene los demás items relacionados respecto al item principal. Es un arreglo con n posiciones, siendo n el número de atributos del dataset. Cada posición puede contener un valor nulo o un arreglo dimensionable para representar varios items con igual atributo. El arreglo dimensionable se implementa utilizando la clase weka.core.FastVector provista por Weka. Cada posición dentro de cada uno de los arreglos dimensionables almacena el valor del atributo del item correspondiente, utilizándose en este caso también el índice dentro de la definición del atributo.

• predS: mantiene los predicados espaciales que relacionan los items de itemsRelated con respecto al item principal de m_items. Mantiene la misma estructura que itemsRelated pero en cada posición de cada arreglo dimensionable almacena el predicado correspondiente que relaciona las posiciones geográficas del item principal y el item de igual posición en itemsRelated. El valor que se almacena en realidad corresponde al índice del predicado dentro del conjunto de predicados del algoritmo, mantenidos en la clase PredicateSet –explicada más adelante-.

En la figura A.3 muestra un ejemplo de representación de un itemset espacio-temporal. En este caso, el itemset representado es: {volume_9300_kcal=(150-500](POS1),heating_value=(37-37,5](POS2),pressure=(15-85](POS3)} PredS= {DISTANCE_C-ORIENTATION_N(POS1,POS2), DISTANCE_L-ORIENTATION_SE(POS1,POS3)}

En la representación de esta figura se omite por simplicidad el hecho de que en realidad los valores almacenados corresponden a índices: del valor dado en la definición del atributo, para el caso de los items, y del predicado dentro del conjunto de predicados del algoritmo, mantenido por la clase PredicateSet, para el caso de los predicados espaciales que relacionan a los items respecto al item principal. Además, la clase SpatioTemporalAprioriItemset mantiene otros atributos que se actualizan durante la ejecución del algoritmo:

• m_counter: contador de transacciones que verifican el itemset -heredado de ItemSet- • totalTransactionsLifespan: contador de transacciones en el lifespan del itemset

Figura A.3. Ejemplo de representación de un itemset espacio-temporal


111

• totalAux: contador auxiliar. Se utiliza debido al cálculo del lifespan dinámicamente • positions: arreglo dimensionable con las posiciones geográficas donde se verifica el

itemset en cada transacción. Es utilizado usado para los itemsets de tamaño de k=1 • lifespan: representado como un arreglo de dos posiciones. Cada posición almacena las

fecha de inicio y finalización del intervalo. La misma se almacena de la manera en que Weka maneja los valores de los atributos de tipo “date” obtenidos desde un dataset: es de tipo double, con la cantidad de milisegundos de la fecha respecto a la fecha base de la clase java.util.Date de java.

• neededLifespan: lifespan “necesario” del itemset. Es el calculado como la condición necesaria que contiene al lifespan del itemset. Se utiliza en la poda temporal de los candidatos generados, explicada en la sección 4.1.1.1 del capítulo 4.

• frecuentLifespan: arreglo dimensionable con los subintervalos frecuentes. Cada uno de los mismos también es un arreglo de 2 posiciones, almacenando los valores extremos de la misma manera que lifespan

• frecuentLifespanSupport: arreglo dimensionable con el soporte en cada subintervalo frecuente, del atributo anterior

• temporalHistogram: histograma temporal del itemset. Mantiene contadores de la cantidad de instancias que verifican el itemset en cada intervalo ∆t, a lo largo del lifespan del mismo.

• datasetTemporalHistogram: histograma temporal del dataset. Mantiene contadores de la cantidad de instancias del dataset en cada intervalo ∆t, a lo largo del tiempo válido del mismo.

• temporalHistogramPosition: posición temporal –índice- del histograma temporal del itemset respecto al histograma temporal del dataset –el anterior-. Permite determinar en que posición del histograma del dataset se ubica el histograma del itemset, utilizándose junto con ambos histogramas en el descubrimiento de los subintervalos frecuentes contenidos dentro del lifespan, así como en cálculos de valores temporales respecto al inicio del dataset.

La clase SpatioTemporalAssociationRule abarca los siguientes elementos:

• itemset unión: itemset espacio-temporal que da origen a la regla, o sea, el itemset mediante el cual se genera la misma

• consecuente: calculado durante el algoritmo. Sería un SpatioTemporalAprioriItemset sin item principal, que siempre forma parte de la premisa, según el esquema de armado de reglas propuesto.

• premisa: se obtiene por diferencia entre los dos itemsets anteriores. Para obtener los datos de contabilización al momento de ser descubierto el itemset correspondiente a la premisa, se recupera el correspondiente itemset dentro del conjunto de itemsets frecuentes de tamaño correspondiente, mantenido por el algoritmo.

• intervalos frecuentes y soporte de la regla: son dos arreglos dimensionables conteniendo los intervalos frecuentes de la regla y el valor de soporte dentro de cada uno de los mismos. Los mismos se obtienen inicialmente de los valores del itemset unión. Posteriormente pueden eliminarse elementos de los mismos en caso de que la confianza calculada en el intervalo correspondiente no supere el umbral de confianza. De esta manera se evita eliminar valores del itemset unión, que puede ser utilizado posteriormente para generar otra regla, y también se mantiene los valores originales del mismo.


112

Además, esta clase contiene la funcionalidad necesaria para el cálculo de la confianza según como se estableció en el algoritmo del modelo, explicado en la sección 4.1.2 del capítulo 4. Para mantener información propia de la ejecución del algoritmo y/o del dataset, la clase SpatioTemporalApriori interactúa con otras clases. Para determinar las posibles relaciones espaciales mantiene un conjunto de predicados espaciales, manejado por la clase PredicateSet. Además, mantiene un histograma temporal del dataset, responsabilidad de la clase TemporalHistogram. A continuación se explican estas clases junto con otras relacionadas.

A.2.1.1.Componente Espacial

Las clases encargadas de la parte espacial del algoritmo tienen como funcionalidad principal el manejo de los predicados espaciales así como el cálculo de los mismos. Con la idea de poder manejar varios tipos de predicados espaciales a futuro, se definieron clases abstractas que tienen actualmente, como base, una implementación inicial:

• Predicate: representa un predicado espacial. Genéricamente contiene dos componentes –ya que se manejan relaciones espaciales de dos dimensiones-, con sus limites y etiquetas identificatorias, los cuales serán especializados de la manera que corresponda. La implementación inicial en uso es DistanceAnglePredicate, que representa un predicado espacial de tipo distancia y orientación.

• PredicateCalculator: es la clase encargada de calcular los componentes de los predicados espaciales dados dos puntos. Su implementación inicial en uso es DistanceAnglePredicateGeographicCalculator, que calcula para dos puntos con coordenadas geográficas la distancia entre los mismos y la orientación en grados del segmento conformado por los puntos geográficos. La implementación interna de esta clase utiliza la librería GeoTools ([13]), desarrollada para la manipulación de datos geoespaciales. La interfaz IGeographicCalculator, implementada por esta clase, señala que los cálculos de componentes son realizados para puntos geográficos –con componentes de longitud y latitud-.

Para poder manejar el conjunto de predicados espaciales que va a utilizarse durante la ejecución del algoritmo, se definió la clase PredicateSet. La misma tiene como responsabilidades:

• crear y mantener el conjunto de predicados espaciales del algoritmo conservando un ordenamiento entre los mismos. Permite acceder a los predicados con un único índice, para lo cual mantiene un arreglo de dos dimensiones “virtual”, conformado por los dos parámetros de los predicados. Para acceder a este arreglo se utiliza una función que mapea los índices a cada componente en un único índice. La idea de la misma es similar a la de la función de hash propuesta en [38]. La diferencia esta en que para este caso, en cambio, se almacenan todos los elementos. De esta manera, la función considera que las filas del arreglo de dos dimensiones “virtual” se encuentran una a continuación de la otra en un arreglo de una dimensión. Así para obtener los elementos del arreglo de dos dimensiones contabiliza el índice de la primera dimensión como el múltipla del índice por el de la segunda, para poder acceder a la fila correspondiente del arreglo, de donde se obtendrá el elemento correspondiente en base al índice de la segunda dimensión.

• determinar el predicado posible dado dos puntos. Para esto hace uso de una instancia de una clase que herede de PredicateCalculator.


113

La figura A.4muestra el diagrama de estas clases nombradas.

Los predicados anteriores son representados y calculados respecto a puntos. Para el manejo de estos puntos se definió la clase abstracta Point. La misma tiene como implementación en uso

Figura A.4 Diagrama de clases espaciales correspondientes al manejo de predicados


114

a la clase GeographicPoint, que representa un punto con coordenadas geográficas (longitud, latitud). La clase PointPair representa un par de puntos que puede ser comparado por igualdad en orden indistinto. La misma se utiliza en la generación de itemsets candidatos de tamaño k=2, para la poda sobre el conjunto de predicados posibles para cada par de 1-itemsets frecuentes formado, explicada en las secciones 4.1.1.1 y 4.1.1.2 del capítulo 4. La figura A.5muestra el diagrama de clases correspondiente a estas últimas clases descriptas.

A.2.1.2.Componente Temporal

La clase TemporalHistogram se definió para poder contabilizar la cantidad de transacciones del dataset en los intervalos determinados por la unidad de discretización ∆t, definida por el usuario. Estos valores son utilizados, por ejemplo, en el descubrimiento de los intervalos contenidos dentro del lifespan frecuente. La instancia de esta clase es mantenida por SpatioTemporalApriori, para el conjunto de datos sobre los cuales se descubren las reglas. Los componentes y funcionalidades que abarca la clase son:

• mantener los contadores de transacciones del conjunto de datos por cada intervalo determinado por la unidad de discretización ∆t

• mantener información del ancho temporal de cada intervalo (∆t) • mantiene internamente los extremos temporales del dataset • funcionalidad para determinar el intervalo correspondiente dado un instante de tiempo,

calculándolo en base a los datos propios mantenidos por la clase • funcionalidad para determinar los máximos y mínimo de un intervalo dado,

calculándolo en base a los datos propios mantenidos por la clase Las funcionalidades indicadas también son utilizadas por SpatioTemporalAprioriItemSet, quien hace la conversión para su propio histograma en base al atributo

Figura A.5 Diagrama de clases espaciales correspondientes al manejo de puntos


115

temporalHistogramPosition. Este atributo es necesario para el cálculo de valores temporales del itemset respecto al tiempo de inicio del dataset. La figura A.6 muestra el diagrama UML de la clase.

A.2.2. Algoritmos de preprocesamiento

En Weka los algoritmos para el preprocesamiento de los datos se denominan filtros, heredando de la clase abstracta weka.filters.Filter. Se define un filtro diferente para implementar cada uno de los algoritmos de preprocesamiento: • DegressToDecimalFormat: realiza la conversión de las componentes de las posiciones

geográficas de tipo texto a un tipo numérico. Corresponde al CU_01 • ClusterDiscretize: algoritmo para discretizar atributos continuos del dataset utilizando

un algoritmo de clustering. Corresponde al CU_02 • PropositionalToTemporalMultiSpatialInstance: algoritmo para conversión entre

estructuras de dataset, desde una estructura de uso mas convencional a la manejada por el modelo de reglas de asociación espacio-temporales. Corresponde al CU_03.

Todas las clases implementan la interfaz OptionHandler, para poder manejar los parámetros de los algoritmos correspondientes de preprocesamiento. También implementan weka.filters.UnsupervisedFilter, ya que, al ser algoritmos de tipo no supervisado, no necesitan para su funcionamiento la identificación de la clase de cada registro, mediante un atributo señalado para este fin. Además, las clase DegressToDecimalFormat implementa weka.filters.StreamableFilter ya que puede trabajar con un stream de instancias, es decir, puede procesar cada instancia o registro que le llega a su entrada sin necesidad de esperar hasta obtener todo el dataset, o determinada cantidad de registros para poder comenzar con su procesamiento. Respecto a la clase ClusterDiscretize, Weka provee el filtro weka.filters.unsupervised.attribute.Discretize como una alternativa de discretización, utilizando un esquema de igual ancho o igual frecuencia. Si bien en el capítulo 5 se comenta su uso como alternativa, el filtro es provisto por Weka y no entra en el alcance de lo desarrollado.

Figura A.6. Diagrama UML de la clase TemporalHistogram


116

La figura A.7 contiene el diagrama de clases correspondiente a los filtros desarrollados.

A.2.3. Paquetes involucrados

Respecto a la distribución de las clases en los paquetes, la misma es la siguiente: • para las clases de descubrimiento de las reglas de asociación espacio-temporales: el

paquete utilizado por Weka para las clases relacionadas con el descubrimiento de reglas de asociación es weka.associations. En este caso, al ser las reglas de tipo espacio-temporal, se decide ubicar las clases principales en un paquete dentro de este paquete, denominado weka.associations.spatiotemporal. Además, las clases nombradas correspondientes a las componentes espacial y temporal se dividen dentro de este paquete en weka.associations.spatiotemporal.predicates y weka.associations.spatiotemporal.temporal, respectivamente.

• para las clases correspondientes a los filtros: los mismos son filtros correspondientes a algoritmos de tipo no supervisados que se aplican sobre atributos. Si bien fueron desarrollados para el uso con el algoritmo, el mismo no es exclusivo y se podrían

Figura A.7. Diagrama de clases correspondiente a los filtros


117

utilizar de manera separada. De esta manera, se ubican en el mismo paquete de Weka para este tipo de filtros, denominado weka.filters.unsupervised.attribute.

En la figura A.8 se muestra el diagrama correspondiente a la distribución de los paquetes.

Figura A.8. Diagrama de paquetes para las clases desarrolladas


118

Apéndice B. Manual del Usuario

B.1. Instalación

Los requisitos necesarios para la instalación de la aplicación son: • java versión 5 o superior • sistema operativo Windows o Linux. Debido a que la aplicación se encuentra

desarrollada en java, puede funcionar en cualquier sistema operativo compatible con esta plataforma. Los sistemas operativos señalados son aquellos donde el paquete de instalación se encuentra configurado, y donde la aplicación ha sido probada.

El paquete de instalación consiste de un archivo zip de nombre “weka.STAR.zip”. Para instalarlo se debe descomprimir este archivo zip dentro de una ubicación donde se quiera tener instalada la aplicación. La estructura instalada contiene las dependencias y configuraciones necesarias para su funcionamiento. Esta estructura contiene la versión 3.5.6 de Weka. Para iniciar la aplicación en Windows se debe acceder al directorio donde se instalo la misma y ejecutar el archivo “star.bat”. En Linux también se debe acceder al directorio donde se instalo la aplicación, pero el archivo a ejecutar es “star.sh”. Si en el caso de utilizar la aplicación en Windows se quieren obtener datos de una base de datos MySQL, la aplicación debe ser iniciada ejecutando el archivo “star.mysql.bat”.

B.2. Uso

Los elementos fueron desarrollados para su uso con el Explorer de Weka. Para acceder al mismo, se debe ir al menú “Applications” y dentro del mismo a “Explorer”. La figura B.1 muestra la pantalla obtenida, correspondiente al Explorer de Weka.


119

Los componentes para el descubrimiento de las reglas de asociación espacio-temporales son: • algoritmo “SpatioTemporalApriori”: utilizado para el descubrimiento de las reglas de

asociación espacio-temporales en base a un dataset dado con una estructura determinada

• filtros: son algoritmos para el preprocesamiento del dataset sobre el cual se desea descubrir las reglas. Se pueden utilizar en el caso de que la estructura del dataset no sea la adecuada para el uso con el algoritmo del item anterior.

A continuación se explica el uso de cada uno de los componentes. Adicionalmente, se agregan observaciones en el caso en que sea necesario aplicar el proceso completo, utilizando todos los componentes, para el descubrimiento de las reglas de asociación espacio-temporales.

B.2.1. Filtros para el preprocesamiento de los datos

Para el uso de los filtros se parte de una estructura de datos compuesta por: • un atributo correspondiente al instante de tiempo • dos atributos correspondientes a las componentes de las posiciones geográficas • mas de un atributo adicionales correspondientes a los items registrados

A los filtros se accede desde la solapa “Preprocess” del Explorer de Weka (corresponde a la primera del mismo). En esta solapa se encuentra el botón “Choose", el cual al ser

Figura B.1. Pantalla correspondiente al Explorer de Weka


120

seleccionado muestra los filtros disponibles a ser utilizados, distribuidos en una estructura de árbol. Desde la misma solapa también se realiza la carga y almacenamiento de los datasets a ser analizados.

B.2.1.1.Conversión de las componentes de las posiciones geográficas

Este filtro se aplica cuando los atributos del dataset correspondientes a las componentes de las posiciones geográficas son de tipo texto, con formato [+/-]DDºMM’SS’’ o [+/-]DDºMM’SS, donde “DD”, “MM” y “SS” se corresponden con los grados, minutos y segundos respectivamente. El signo delante señala el hemisferio y/o latitud, con lo cual para indicar hemisferio O y/o latitud S se debe utilizar “-” delante. La figura B.2 muestra un dataset cargado cumpliendo esta característica. Se observa que los valores del atributo correspondiente a la longitud tienen el segundo formato señalado.

Lo que realiza el filtro es la conversión de estos atributos a números con el formato DD,dddd , en donde “DD” son los grados y “dddd” la parte decimal de los minutos y segundos respecto a estos últimos. El nombre del filtro es DegressToDecimalFormat, y se ubica dentro del árbol de selección en weka/filters/unsupervised/attribute, como se muestra en la pantalla de la figura B.3.

Figura B.2. Pantalla mostrando un dataset cargado con las condiciones para aplicar el filtro de

conversión de las componentes de las posiciones geográficas


121

Una vez seleccionado el filtro, se deben definir los parámetros del mismo, para el caso en que los valores por defecto no sirvan para su uso. Seleccionando sobre el nombre del filtro, se accede a la ventana de edición de los parámetros. Esta ventana también contiene información sobre el funcionamiento del filtro. Los parámetros a ser ingresados son los índices de los atributos con los componentes de las posiciones geográficas, separados por “,”. Luego de definirse los parámetros de uso del filtro, se debe iniciar el procesamiento seleccionando “Apply”. El dataset resultante contiene los atributos con los componentes de las posiciones geográficas de tipo numérico. En la figura B.4 se muestra la pantalla obtenida luego de aplicar el filtro. En esta pantalla se puede observar que el atributo correspondiente a longitud es de tipo numérico.

Figura B.3. Pantalla mostrando la ubicación del filtro DegressToDecimalFormat


122

B.2.1.2.Discretización de los atributos continuos mediante clustering

Este filtro se aplica cuando los atributos correspondientes a los items registrados tienen valores continuos. En la figura B.5 se muestra la pantalla con un dataset cargado que cumple esta condición. Se observa que el atributo “volume_9300_kcal” es de tipo numérico, conteniendo un conjunto de valores continuo. Este filtro permite la discretización de estos atributos, para obtener atributos discretos que puedan ser manejados como items por el algoritmo para el descubrimiento de las reglas de asociación espacio-temporales.

Figura B.4. Pantalla obtenida luego de aplicar el filtro de conversión de las componentes de las

posiciones geográficas


123

El enfoque utilizado por el filtro para la discretización de los atributos es la utilización de un algoritmo de clustering aplicado sobre los valores del atributo que se desea discretizar. El nombre del filtro es ClusterDiscretize, y se ubica dentro del árbol de selección en weka/filters/unsupervised/attribute. Una vez seleccionado el filtro, se deben definir los parámetros del mismo, para el caso en que los valores por defecto no sirvan para su uso. Seleccionando sobre el nombre del filtro, se accede a la ventana de edición de estos parámetros. Esta ventana también contiene información sobre el funcionamiento del filtro. Los parámetros a ser ingresados son el índice del atributo a ser discretizado y el algoritmo de clustering a utilizar para la discretización. También se definen los parámetros de este algoritmo de clustering. La figura B.6 muestra la pantalla de carga de los parámetros. En la misma se observa la definición de los parámetros propios del algoritmo de clustering seleccionado.


discretización de atributos mediante clustering


124

Luego de definirse los parámetros de uso del filtro, se debe iniciar el procesamiento seleccionando “Apply”. El dataset resultante contiene el atributo seleccionado discretizado en base al algoritmo de clustering definido en los parámetros. La identificación de los conjuntos de discretización obtenidos mediante el algoritmo de clustering se realiza mediante un valor numérico incrementado. Si el algoritmo de clustering seleccionado da como alternativa datos adicionales que representen a los clusters obtenidos que puedan ser utilizados para identificarlos, se utiliza esa información. Por ej., para el caso de weka.clusterers.EM, seleccionado en la figura B.6, se utiliza la media y el desvío estándar de la distribución normal que modeliza a cada cluster descubierto. La figura B.7 muestra la pantalla obtenida luego de aplicar el filtro. En esta pantalla se observa que el atributo “volume_9300_kcal” es de tipo nominal, conteniendo un conjunto de valores discretos dados por los conjuntos de discretización descubiertos por el algoritmo de clustering. Estos conjuntos de discretización se identifican por la media y el desvío estándar de la distribución normal que modeliza a los clusters correspondientes a los mismos.

Figura B.6. Pantalla de carga de los parámetros del filtro ClusterDiscretize


125

Debido a que el filtro se aplica sobre un solo atributo seleccionado, debe ser aplicado posteriormente de la misma manera sobre los restantes atributos que deban ser discretizados.

B.2.1.3.Discretización de los atributos continuos propuesta por Weka

Además del esquema de discretización propuesto en este software, Weka contiene un filtro de discretización incorporado, el que puede ser utilizado como alternativa para la discretización de los atributos continuos. Para este caso, el enfoque utilizado por el filtro es mediante el uso de esquemas de discretización en igual ancho, o en igual frecuencia. El nombre del filtro es Discretize, y también se ubica dentro del árbol de selección en weka/filters/unsupervised/attribute. Una vez seleccionado el filtro, se deben definir los parámetros del mismo, para el caso en que los valores por defecto no sirvan para su uso. Seleccionando sobre el nombre del filtro, se accede a la ventana de edición de estos parámetros. Esta ventana también contiene información sobre el funcionamiento del filtro. Los parámetros principales a ser ingresados son los índices de los atributos a ser discretizados, la cantidad de intervalos y el esquema de discretización utilizado. Información completa de los parámetros disponibles del filtro puede

Figura B.7. Pantalla obtenida luego de aplicar el filtro de discretización de atributos mediante

clustering


126

ser consultada también en la documentación javadoc de la clase provista por Weka. Esta documentación javadoc de las clases de Weka, correspondiente a la versión utilizada con la aplicación, se encuentra incluida dentro del instalador de esta última. Luego de definirse los parámetros de uso del filtro, se debe iniciar el procesamiento seleccionando “Apply”. El dataset resultante contiene los atributos seleccionados discretizados en base al esquema y demás parámetros ingresados. En este caso los intervalos de discretización se identifican con los extremos de los mismos. Además, la cantidad de intervalos obtenidos abarca todo el conjunto de valores posibles para cada atributo en el dataset, a diferencia del filtro desarrollado en este software que abarca para cada atributo todos los valores existentes en el dataset. La figura B.8 muestra la pantalla obtenida luego de aplicar el filtro para el atributo del mismo caso usado en el filtro anterior. Se observa que el atributo “volume_9300_kcal” es de tipo nominal, conteniendo un conjunto de valores discretos dados por los intervalos de discretización obtenidos por el filtro.

B.2.1.4.Conversión entre estructuras de datasets

El algoritmo para el descubrimiento de las reglas de asociación espacio-temporales requiere para su funcionamiento una estructura de dataset donde los valores registrados se ubican en registros agrupados por el instante de tiempo. En caso de tenerse un dataset donde los valores

Figura B.8. Pantalla obtenida luego de aplicar el filtro de discretización existente en Weka


127

registrados se agrupan por instante de tiempo y posición geográfica se puede aplicar este filtro para convertirlo en un dataset con la estructura necesaria para el descubrimiento de las reglas de asociación. La figura B.9 muestra una pantalla con un dataset cargado que cumple esta condición. Se observa que los 3 primeros atributos identifican, en cada registro, el instante de tiempo (atributo “timestamp”) y la posición geográfica (atributos “longitude” y “latitude”).

El filtro para su funcionamiento requiere que los registros se encuentren ordenados por el instante de tiempo. El nombre del filtro es PropositionalToTemporalMultiSpatialInstance, y se ubica dentro del árbol de selección en weka/filters/unsupervised/attribute. Una vez seleccionado el filtro, se deben definir los parámetros del mismo, para el caso en que los valores por defecto no sirvan para su uso. Seleccionando sobre el nombre del filtro, se accede a la ventana de edición de los parámetros. Esta ventana también contiene información sobre el funcionamiento del filtro. Los parámetros a ser ingresados son los índices del atributo correspondiente al instante de tiempo y del atributo correspondiente al primer componente de la posición (el filtro considera a ambos componentes contiguos). Luego de definirse los parámetros de uso de la clase, se debe iniciar el procesamiento seleccionando “Apply”. El dataset resultante contiene las transacciones necesarias para el descubrimiento de las reglas de asociación espacio-temporales. Estas transacciones contienen el instante de tiempo, y un atributo de tipo relacional. El contenido de este último atributo son los registros del dataset de entrada correspondientes al instante de tiempo de la transacción


conversión entre estructuras de datasets


128

actual. Además, para estos registros se omite el atributo del instante de tiempo (ya que se ubica en la transacción actual) y los atributos de los componentes de las posiciones se ubican primeros. En la figura B.10 se muestra la pantalla obtenida luego de aplicar el filtro. En esta pantalla se puede observar que el dataset se compone de dos atributos: “timestamp” (de tipo “Date”) y “spatial_items” (correspondiente a los items registrados como un atributo de tipo “Relational”).

Debido a que el dataset resultante se utilizará para el descubrimiento de las reglas de asociación espacio-temporales, los atributos del mismo se deben hallar discretizados y los componentes de las posiciones deben tener un formato numérico. En caso de que esto no ocurra, se deben aplicar previamente los filtros anteriormente mencionados.

B.2.2. Descubrimiento de las reglas de asociación espacio-temporales

Para el descubrimiento de las reglas de asociación espacio-temporales, el dataset utilizado debe tener la estructura dada por el filtro anterior, PropositionalToTemporalMultiSpatialInstance. Además, los atributos del dataset se deben hallar discretizados, y los componentes de la posición deben ser numéricos. De esta manera, también se deben aplicar previamente los dos filtros anteriores al último.

Figura B.10. Pantalla obtenida luego de aplicar el filtro de conversión entre estructuras de

datasets


129

Una vez obtenido el dataset con la estructura armada se debe pasar a la solapa “Associate” para acceder al algoritmo para el descubrimiento de las reglas de asociación espacio-temporales. El nombre de este algoritmo es SpatioTemporalApriori, y se ubica dentro del árbol de selección en weka/associations/spatiotemporal, como se muestra en la pantalla de la figura B.11. A este árbol se accede mediante el botón “Choose”.

A continuación se deben definir los parámetros del algoritmo, para el caso en que los valores por defecto no sirvan para su uso. Seleccionando sobre el nombre del algoritmo, se accede a la ventana de edición de los parámetros. Esta ventana también contiene información sobre el funcionamiento del algoritmo. Los parámetros a ser ingresados son: los umbrales de soporte, soporte temporal y confianza, el tamaño del intervalo unidad de discretización temporal para los histogramas manejados, la unidad temporal de este último (y del soporte temporal), el nombre de la clase que realiza el cálculo de los componentes de los predicados espaciales, los limites de los intervalos de discretización de los parámetros de los predicados espaciales (junto a sus etiquetas identificatorias), si los itemsets descubiertos se muestran a la salida del algoritmo, y si se realiza el log de los itemsets descubiertos (en notación interna para debug). En la figura B.12 se muestra la pantalla de carga de estos parámetros.

Figura B.11. Pantalla mostrando la ubicación del algoritmo SpatioTemporalApriori


130

Luego de definirse los parámetros de ejecución del algoritmo, se debe iniciar el descubrimiento de las reglas seleccionando “Start”. Al finalizar, la salida del algoritmo mostrará un reporte de las reglas descubiertas, dentro del panel “Associator output”. El mismo contiene: • “Parameters”: los parámetros de entrada dados al algoritmo, • “Total Summaries”: un resumen de la cantidad de itemsets frecuentes y reglas

descubiertos, junto con los tiempos de ejecución de los algoritmos para el descubrimiento de los mimos

• “Sets of frequent Itemsets Discovered”: los itemsets frecuentes descubiertos. Para cada tamaño se muestra la cantidad, y si corresponde con los parámetros, se muestran los itemsets

• “Spatio-Temporal Association Rules Discovered”: las reglas de asociación espacio-temporales descubiertas

En la figura B.13 se muestra la pantalla con el reporte de resultados obtenido utilizando el algoritmo.

Figura B.12. Pantalla de carga de los parámetros del algoritmo SpatioTemporalApriori


131

Los resultados obtenidos pueden ser guardados seleccionando, dentro del panel “Result list”, la corrida de ejecución deseada, y luego dentro del menú contextual, la opción “Save result buffer”. Además, sobre el directorio de ejecución de la aplicación se genera un archivo de log que muestra las distintas etapas del descubrimiento de las reglas, de acuerdo a la configuración del logger. El nombre del archivo generado es “STAR.[YYYYMMDDhhmmss].txt”, donde “[YYYYMMDDhhmmss]” contiene los elementos de la fecha y hora de ejecución del algoritmo. Esta misma salida se muestra también sobre la ventana de la consola que se abre junto con la aplicación. Si se seleccionó en los parámetros del algoritmo la generación de los archivos de log con los itemsets descubiertos, los mismos también se generan en la misma ubicación. Su nombre tiene el formato “[YYYYMMDDhhmmss]_L[k].txt”, ”, donde “[YYYYMMDDhhmmss]” contiene los elementos de la fecha y hora de la ejecución del algoritmo y “[k]” el tamaño de los itemsets del conjunto registrado en el archivo.

B.2.3. Manejo de datos

El dataset sobre el cual se realiza el descubrimiento de las reglas de asociación espacio-temporales se carga desde la solapa “Preprocess”, en la cual se aplican los filtros

Figura B.13. Pantalla con el reporte de resultados obtenido mediante el algoritmo para el

descubrimiento de las reglas de asociación espacio-temporales


132

mencionados. Esta solapa es provista por Weka. A continuación se comentan dos alternativas comunes para la carga del dataset, posibles de ser utilizadas con la aplicación desarrollada.

B.2.3.1.Obtención de datos desde un archivo

Para obtener los datos desde un archivo se debe seleccionar el botón “Open file…”. Se abre una ventana de dialogo para seleccionar el archivo conteniendo el dataset. Este dataset se debe hallar en algunos de los formatos aceptados por Weka. Entre los formatos posibles se encuentran arff (formato propuesto por Weka), csv y xrff (extensión xml de arff).

B.2.3.2.Obtención de datos desde una base de datos

Para obtener los datos desde una base de datos se debe seleccionar el botón “Open DB…”. A continuación se abre una ventana, como la mostrada en la figura B.14, para cargar los datos en base a consultas a la base. Para usar esta ventana, se debe tener previamente configurado el acceso a bases de datos en el archivo “DatabaseUtils.props”. El paquete de instalación de la aplicación viene configurado por defecto para acceder a una base de datos MS Access por ODBC, mediante un DSN de nombre “gasoductos”. El archivo con la configuración correspondiente se ubica en la raíz del directorio de instalación de la aplicación. Para poder acceder a una base de datos MySQL -que puede ser instalada localmente en un sistema operativo Linux- el paquete de instalación incluye una configuración correspondiente en el archivo “DatabaseUtils.props.mysql”. Con la configuración de este archivo se accede a una base de datos MySQL local de nombre “gasoductos”, con un usuario de nombre “guest_gasoductos”. Para poder configurar mediante un cambio simple el acceso a datos para cada motor de base de datos, el paquete de instalación incluye además un archivo de nombre “DatabaseUtils.props.odbc” con la configuración por defecto para acceder a la base de datos MS Access. De esta manera, para configurar el acceso con el motor de base de datos necesario, se debe simplemente renombrar -o copiar con otro nombre- el archivo correspondiente con el nombre “DatabaseUtils.props”. En esta ventana, que aparece al seleccionar en el botón mencionado, se debe completar la URL de acceso a la base de datos y a continuación seleccionar el botón “Connect”. Para el caso de la configuración por defecto del paquete de instalación se ingresa “jdbc:odbc:gasoductos”. En el panel “Query” se ingresa la consulta sql que permite obtener el dataset a ser procesado y luego se selecciona “Execute”. El panel “Result” muestra los 100 primeros registros obtenidos y el panel “Info” los datos de la ejecución de la consulta, que incluyen el total de filas. Si los valores son correctos se selecciona “OK” para obtener el dataset cargado en el panel de preprocesamiento.


133

B.3. Actualizaciones de Weka

Al instalarse el archivo comprimido de la aplicación en el directorio deseado, se obtiene la estructura de archivos con la configuración y dependencias necesarias para el funcionamiento de la aplicación. El contenido esta estructura se encuentra conformado por: • archivos jar de Weka. Corresponden a la versión 3.5.6. Los nombres de los mismos

son “weka.jar” y “weka-src.jar” (fuentes) • documentación javadoc de las clases de Weka, correspondientes a la versión señalada

en el punto anterior. El nombre del archivo es “weka-doc.zip” • archivos jar de las clases desarrolladas. Los nombres de los archivos son

“weka.associations.spatiotemporal.jar” y “weka.associations.spatiotemporal.src.jar” (fuentes)

• documentación javadoc de las clases desarrolladas. Se ubican en el archivo comprimido “weka.spatiotemporal.doc.zip”

• dependencias para el funcionamiento de las clases desarrolladas. Se ubican dentro del directorio “lib”. Corresponden a la librería GeoTools versión 2.2.0 y al driver jdbc de MySQL versión 5.1.5.

• archivos de configuración:

Figura B.14. Pantalla para obtención de datos en Weka mediante una base de datos


134

o GenericPropertiesCreator.props: configuración de clases a ser utilizadas dentro de Weka. Para cada tipo de clases a ser seleccionadas (filtros, clusterers, associators, etc.) se indican los paquetes de ubicación de las mismas

o DatabaseUtils.props: configuración del acceso a datos desde base de datos. Se encuentra configurado para una base de datos MS Access accediendo por ODBC, mediante un DSN de nombre “gasoductos”. También se encuentra el archivo “DatabaseUtils.props.mysql” con la configuración para el acceso a una base de datos MySQL local de nombre “gasoductos”, con un usuario de nombre “guest_gasoductos”. Ambos elementos (base de datos y usuario) pueden creados mediante los scripts sql contenidos en el material digital. La configuración para MS Access se encuentra también en el archivo “DatabaseUtils.props.odbc”, esto permite un cambio simple de la configuración del acceso a datos para cada motor de base de datos.

o logging.properties: configuración del logger de java. El nivel “STAR” se corresponde al utilizado por el algoritmo para el descubrimiento de las reglas de asociación espacio-temporales. Este nivel se encuentra configurado en “FINE”.

o LookAndFeel.props: configuración del tema de apariencia de las ventanas de la aplicación. Se encuentra configurado “Metal”.

• archivo para la ejecución de la aplicación. Carga las clases necesarias en el classpath y configura la memoria de uso, en 512 MB. Para el uso en Windows su nombre es “star.bat”, y para Linux “star.sh”. En caso de querer utilizarse la aplicación en Windows con MySQL, se debe utilizar el archivo “star.mysql.bat”. El mismo carga además en el classpath las clases correspondientes al driver jdbc para este motor de base de datos.

Debido al uso de jars separados para las clases de Weka y las desarrolladas, la estructura de la aplicación permite realizar la actualización a una nueva versión de Weka sin necesidad de rearmar los paquetes de clases. Para realizar esta actualización se deben reemplazar los jars actuales de Weka, “weka.jar” y “weka-src.jar”, y el archivo con la documentación javadoc de las clases, “weka-doc.zip”, con los de la nueva versión. En caso de que haya cambiado la estructura de paquetes de las clases de los algoritmos existentes en Weka, al arrancar la aplicación aparecerán en la consola mensajes de clases no encontradas. Para solucionar este problema, se debe actualizar la configuración de las clases a ser utilizadas: • se debe obtener el archivo de configuración de la nueva versión de Weka. Para esto

hay que extraer de “weka.jar” el archivo GenericPropertiesCreator.props, y reemplazar el existente en el directorio de instalación de la aplicación. Este archivo se ubica dentro del jar en weka/gui.

• se debe agregar a este archivo extraído la configuración de las clases desarrolladas para el descubrimiento de las reglas de asociación espacio-temporales, ya que se encuentran en un paquete separado. Para esto se deben modificar las líneas

# Lists the Associators-Packages I want to choose from weka.associations.Associator=\ weka.associations

, y reemplazarlas por # Lists the Associators-Packages I want to choose from weka.associations.Associator=\ weka.associations, \ weka.associations.spatiotemporal


135

Al arrancar la aplicación nuevamente, se utilizará la nueva versión de Weka. Además, la misma reconocerá las clases desarrolladas para el descubrimiento de las reglas de asociación espacio-temporales y los filtros de preprocesamiento asociados.

136

Apéndice C. Código Fuente

C.1. Paquete weka.associations.spatiotemporal

/* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.associations.spatiotemporal; import java.io.BufferedWriter; import java.io.FileWriter; import java.io.IOException; import java.io.PrintWriter; import java.text.SimpleDateFormat; import java.util.Date; import java.util.Enumeration; import java.util.Hashtable; import java.util.logging.Level; import weka.associations.spatiotemporal.predicates.PredicateSet; import weka.associations.spatiotemporal.temporal.TemporalHistogram; import weka.core.Capabilities; import weka.core.FastVector; import weka.core.Instances; import weka.core.Option; import weka.core.Utils; import weka.core.Capabilities.Capability; import weka.core.Debug.Clock; import weka.core.Debug.Log; import weka.experiment.Stats; /**  * Clase para el descubrimiento de reglas de asociacion espacio-temporales. * El algoritmo para el descubrimiento de los itemsets espacio-temporales frecuentes se denomina STApriori. * Se encuentra basado en el esquema del algoritmo Apriori. * Para el armado de las reglas se utiliza una extension de Faster Algorithm. * El esquema para el descubrimiento de las reglas, es el convencional del algoritmo: se muestran todas las * reglas descubiertas en base a los parametros dados. * * * * Referencias: ver documento de Tesis "Un Modelo de Reglas de Asociación Espacio-Temporales" * *

137

 *  * Parametros del algoritmo: * * <pre> -MS <umbral de soporte> * Valor minimo del umbral de soporte (default = 0.65)</pre> * * <pre> -MC <umbral de confianza> * Valor minimo del umbral de confianza de las reglas descubiertas (default = 0.8)</pre> * * <pre> -I * Indica si los itemsets descubiertos se muestran en la salida (default = false)</pre> * * <pre> -IL * Realiza el log en modo debug de los itemsets descubiertos (default = false)</pre> * * <pre> -MTS <umbral de soporte temporal> * Valor minimo para el umbral del soporte temporal (absoluto). (default=10)</pre> * * <pre> -THU <unidad histograma temporal> * Unidad de division del histograma temporal (absoluto) (default=5)</pre> * * <pre> -TU <unidad temporal dataset> * Unidad temporal manejada en el dataset (usada para los 4 parametros anteriores). * Valores: DAY (default)</pre> * * <pre> -SPC <nombre clase PredicateCalculator> * Nombre de la clase encargada del calculo de los componentes de los predicados espaciales. * Debe extender la clase weka.associations.spatiotemporal.predicates.PredicateCalculator. * (default "weka.associations.spatiotemporal.predicates.DistanceAnglePredicateGeographicCalculator")</pre> * * <pre> -SP1 <limite y etiquetas primer parametro comp. espaciales> * Valores de los limites (y etiquetas) de los intervalos del primer parametro de los componentes espaciales. * Notacion: LIM1[LAB1],LIM2[LAB2],...LIMn * Los valores se dan en orden creciente, salvo un par en caso de ser componente ciclico. * Ademas en este ultimo caso coinciden los extremos de la lista, para cerrar los valores del ciclo del componente * (default: "0[MC],200[C],500[MED],800[L],1200[ML],INF")</pre> * * <pre> -SP2 <limite y etiquetas segundo parametro comp. espaciales> * Valores de los limites (y etiquetas) de los intervalos del segundo parametro de los componentes espaciales. * Notacion: LIM1[LAB1],LIM2[LAB2],...LIMn . * Los valores se dan en orden creciente, salvo un par en caso de ser componente ciclico. * Ademas en este ultimo caso coinciden los extremos de la lista, para cerrar los valores del ciclo del componente * (default: "-157.5[SO],-112.5[S],-67.5[SE],-22.5[E],22.5[NE],67.5[N],112.5[NO],157.5[O],-157.5")</pre> *  * * @author Mariano Kohan ([email protected]) * @version 1.0 */ public class SpatioTemporalApriori extends weka.associations.Associator


138

implements weka.core.OptionHandler { /*valores de constantes para infinito*/ protected static final String POSITIVE_INFINITY_STRING = "INF"; protected static final String NEGATIVE_INFINITY_STRING = "-INF"; protected static final String ALL_VALUES_STRING = "ALL"; /*valores de constantes para unidad temporal*/ protected static final String DAY_TEMPORAL_UNIT_CONSTANT = "DAY"; protected static final int DAY_TEMPORAL_UNIT = 24*60*60*1000; //////atributos basicos de Apriori y Faster Algorithm ////// /** Umbral minimo de soporte */ protected double minimumSupport; /** Umbral minimo de confianza */ protected double minimumConfidence; /** Si se muestran los itemsets descubiertos en la salida */ protected boolean outputItemsets; /** Si se realiza log de los itemsets descubiertos, en modo debug */ protected boolean logItemsets; /** Dataset de transacciones del modelo */ protected Instances transactions; /** Conjunto de itemsets frecuentes L, union de los conjuntos de itemsets frecuentes de cada tamaño */ protected FastVector frequentItemsetsSets; /** Informacion de frequentItemsetsSets almacenada en hash tables, para un acceso mas eficiente */ protected FastVector frequentItemsetHashtables; /** Conjunto de todas las reglas de asociacion espacio-temporales descubiertas */ protected FastVector spatioTemporalAssociationRules; //////atributos para modelo espacio-temporal////// /** Nombre de la clase que calcula los predicados espaciales */ protected String predicateCalculatorString; /** Limites de componente 1 de los predicados espaciales*/ protected double[] component1Limits; /** Limites de componente 2 de los predicados espaciales*/ protected double[] component2Limits; /** Etiquetas de componente 1 de predicados espaciales*/ protected String[] component1Labels; /** Etiquetas de componente 2 de predicados espaciales*/ protected String[] component2Labels; /** Umbral minimo de soporte temporal*/ protected double minimumTemporalSupport; /** Unidad de medicion temporal*/ protected String temporalUnitString; /** Unidad de medicion temporal (equivalencia con milisegundos)*/ protected double temporalUnit; /** Unidad temporal de los histogramas */


139

protected double temporalHistogramUnit; /** Histograma temporal del algoritmo */ protected TemporalHistogram temporalHistogram; /** Clase que mantiene el conjunto de predicados espaciales*/ protected PredicateSet predicates; /** Logger del algoritmo*/ protected Log logger; /** Identificador de la corrida del algoritmo en ejecucion*/ /*uso para nomenclar archivos de log con los itemsets descubiertos*/ protected String executionIdentifier; /** Tiempo en descubrir los itemsets frecuentes (algoritmo STApriori)*/ protected String frequentItemsetsDiscoveredTime; /** Tiempo en descubrir las reglas de asociaction ST, una vez descubiertos los itemsets (extension Faster Algorithm)*/ protected String spatioTemporalAssociationRulesDiscoveredTime; /** * */ public SpatioTemporalApriori() throws Exception { resetOptions(); } /** * @return the minimumSupport */ public double getMinimumSupport() { return minimumSupport; } /** * @param minSupport the minimumSupport to set */ public void setMinimumSupport(double minSupport) { minimumSupport = minSupport; } /** * @return the minimumConfidence */ public double getMinimumConfidence() { return minimumConfidence; } /** * @param confidence the minimumConfidence to set */ public void setMinimumConfidence(double confidence) { minimumConfidence = confidence; } /** * @return the outputItemsets

140

*/ public boolean isOutputItemsets() { return outputItemsets; } /** * @param outItemsets the outputItemsets to set */ public void setOutputItemsets(boolean outItemsets) { outputItemsets = outItemsets; } /** * @return the logItemsets */ public boolean isLogItemsets() { return logItemsets; } /** * @param logItemsets the logItemsets to set */ public void setLogItemsets(boolean logItemsets) { this.logItemsets = logItemsets; } /** * @return */ public String getPredicateCalculator() { return this.predicateCalculatorString; } /** * @param predicateCalculator */ public void setPredicateCalculator(String predicateCalculator) { this.predicateCalculatorString = predicateCalculator; } /** * Retorna la descripcion de los limites y etiquetas de los intervalos para el componente 1 * de los predicados espaciales * @return */ public String getComponent1LimitsAndLabels() { String limits = ""; for (int i = 0; i < this.component1Limits.length; i++) { if (this.component1Limits[i] == Double.POSITIVE_INFINITY) limits += POSITIVE_INFINITY_STRING; else if (this.component1Limits[i] == Double.NEGATIVE_INFINITY) limits += NEGATIVE_INFINITY_STRING; else limits += Utils.doubleToString(this.component1Limits[i], 2); if (this.component1Labels.length > i) //labels tiene una posicion menos { if (this.component1Labels[i] != null)

141

limits += "["+this.component1Labels[i]+"]"; else limits += "["+this.component1Limits[i]+", "+this.component1Limits[i+1]+"]"; limits += ","; } } return limits; } /** * Setea los limites y etiquetas de los intervalos del componente 1 de los predicados espaciales * @param limitsAndLabels */ public void setComponent1LimitsAndLabels(String limitsAndLabels) { String[] limitsArray = limitsAndLabels.split(","); this.component1Limits = new double[limitsArray.length]; this.component1Labels = new String[(limitsArray.length - 1)]; String limitLabel; int labelPosition; for (int i = 0; i < limitsArray.length; i++) { limitLabel = limitsArray[i]; if (i == limitsArray.length - 1) { //la ultima posicion no tiene label if (limitLabel.equals(POSITIVE_INFINITY_STRING)) this.component1Limits[i] = Double.POSITIVE_INFINITY; else this.component1Limits[i] = Double.parseDouble(limitLabel); } else { labelPosition = limitLabel.indexOf("["); if (labelPosition == -1) { //formato limit this.component1Limits[i] = Double.parseDouble(limitLabel); this.component1Labels[i] = null; } else { //formato limit[label] this.component1Limits[i] = Double.parseDouble(limitLabel.substring(0,labelPosition)); this.component1Labels[i] = limitLabel.substring(labelPosition+1,limitLabel.length()-1); } } } } /** * Retorna la descripcion de los limites y etiquetas de los intervalos para el componente 2 * de los predicados espaciales * @return */ public String getComponent2LimitsAndLabels() { String limits = ""; for (int i = 0; i < this.component2Limits.length; i++) { if (this.component2Limits[i] == Double.POSITIVE_INFINITY) limits += POSITIVE_INFINITY_STRING;

142

else if (this.component2Limits[i] == Double.NEGATIVE_INFINITY) limits += NEGATIVE_INFINITY_STRING; else limits += Utils.doubleToString(this.component2Limits[i], 2); if (this.component2Labels.length > i) //labels tiene una posicion menos { if (this.component2Labels[i] != null) limits += "["+this.component2Labels[i]+"]"; else limits += "["+this.component2Limits[i]+", "+this.component2Limits[i+1]+"]"; limits += ","; } } return limits; } /** * Setea los limites y etiquetas de los intervalos del componente 2 de los predicados espaciales * @param limitsAndLabels */ public void setComponent2LimitsAndLabels(String limitsAndLabels) { String[] limitsArray = limitsAndLabels.split(","); this.component2Limits = new double[limitsArray.length]; this.component2Labels = new String[(limitsArray.length - 1)]; String limitLabel; int labelPosition; for (int i = 0; i < limitsArray.length; i++) { limitLabel = limitsArray[i]; if (i == limitsArray.length - 1) { //la ultima posicion no tiene label if (limitLabel.equals(POSITIVE_INFINITY_STRING)) this.component2Limits[i] = Double.POSITIVE_INFINITY; else this.component2Limits[i] = Double.parseDouble(limitLabel); } else { labelPosition = limitLabel.indexOf("["); if (labelPosition == -1) { //formato limit this.component2Limits[i] = Double.parseDouble(limitLabel); this.component2Labels[i] = null; } else { //formato limit[label] this.component2Limits[i] = Double.parseDouble(limitLabel.substring(0,labelPosition)); this.component2Labels[i] = limitLabel.substring(labelPosition+1,limitLabel.length()-1); } } } } /** * @return the minimumTemporalSupport */ public double getMinimunTemporalSupport() {

143

return minimumTemporalSupport; } /** * @param minTemporalSupport the minimumTemporalSupport to set */ public void setMinimunTemporalSupport(double minTemporalSupport) { this.minimumTemporalSupport = minTemporalSupport; } /** * @return the temporalUnitString */ public String getTemporalUnit() { return temporalUnitString; } /** * @param temporalUnitString the temporalUnitString to set */ public void setTemporalUnit(String temporalUnitString) { this.temporalUnitString = temporalUnitString; this.temporalUnit = DAY_TEMPORAL_UNIT; //default - por si el string no esta registrado como constante if (temporalUnitString.equals(DAY_TEMPORAL_UNIT_CONSTANT)) this.temporalUnit = DAY_TEMPORAL_UNIT; //otras constantes ... } /** * @return the temporalHistogramUnit */ public double getTemporalHistogramUnit() { return temporalHistogramUnit; } /** * @param temporalHistogramUnit the temporalHistogramUnit to set */ public void setTemporalHistogramUnit(double temporalHistogramUnit) { this.temporalHistogramUnit = temporalHistogramUnit; } /** * Retorna una enumeracion describiendo las opciones disponibles * * @return Enumeration con todas las opciones disponibles */ public Enumeration listOptions() { FastVector newVector = new FastVector(9); //option: descripcion, nombre, numero argumentos, uso newVector.addElement(new Option( "\tThe minimum support of a frequent itemset. (default = " + this.minimumSupport + ")", "MS", 1,"-MS <minimum support of a frequent itemset>")); newVector.addElement(new Option( "\tThe minimum confidence of a rule. (default = " + this.minimumConfidence + ")", "MC", 1, "-MC <minimum confidence of a rule>")); newVector.addElement(new Option( "\tIf set the itemsets found are also output. (default = " +

144

(this.outputItemsets ? "true" : "false" )+ ")", "I", 0, "-I")); newVector.addElement(new Option( "\tThe minimum temporal support of a frequent itemset (absolute). (default = "+this.minimumTemporalSupport+")", "MTS", 1,"-MTS <temporal support of a frequent itemset>")); newVector.addElement(new Option( "\tThe dataset's histogram temporal unit (absolute) (default = "+this.temporalHistogramUnit+")", "THU", 1,"-THU <constant for the temporal histogram unit>")); newVector.addElement(new Option( "\tThe dataset's temporal unit (used in last 2 options). (Values= DAY, ...) (default = "+this.temporalUnitString+")", "TU", 1,"-TU <constant for the temporal unit>")); newVector.addElement(new Option( "\tPredicate calculator class name used for calculate spatial predicate's components\n"+ "\t(default = "+this.predicateCalculatorString+")", "SPC", 1,"-SPC <predicate calculator class name>")); newVector.addElement(new Option( "\tLimits and labels for first parameter of spatial predicates.\n"+ "\t(default = " + this.getComponent1LimitsAndLabels() + " )", "SP1", 1,"-SP1 <limits and labels for spatial predicate's first parameter>")); newVector.addElement(new Option( "\tLimits and labels for second parameter of spatial predicates.\n"+ "\t(default = " + this.getComponent2LimitsAndLabels() + " )", "SP2", 1,"-SP2 <limits and labels for spatial predicate's second parameter>")); newVector.addElement(new Option( "\tIf set the itemsets found are also logged to files in debug mode. (default = " + (this.logItemsets ? "true" : "false" )+ ")", "IL", 0, "-IL")); return newVector.elements(); } /** * Resetea las opciones a sus valores default */ public void resetOptions() { this.setMinimumSupport(0.65); this.setMinimumConfidence(0.8); this.setOutputItemsets(false); this.setLogItemsets(false); this.setMinimunTemporalSupport(10.0); this.setTemporalHistogramUnit(5.0); this.setTemporalUnit(DAY_TEMPORAL_UNIT_CONSTANT); this.setPredicateCalculator("weka.associations.spatiotemporal.predicates.DistanceAnglePredicateGeographicCalculator"); this.setComponent1LimitsAndLabels("0[MC],200[C],500[MED],800[L],1200[ML],INF"); this.setComponent2LimitsAndLabels("-157.5[SO],-112.5[S],-67.5[SE],-22.5[E],22.5[NE],67.5[N],112.5[NO],157.5[O],-157.5"); } /** * Parsea una lista de opciones dada *  * Parametros del algoritmo: * * <pre> -MS <umbral de soporte> * Valor minimo del umbral de soporte (default = 0.65)</pre> *

145

* <pre> -MC <umbral de confianza> * Valor minimo del umbral de confianza de las reglas descubiertas (default = 0.8)</pre> * * <pre> -I * Indica si los itemsets descubiertos se muestran en la salida (default = false)</pre> * * <pre> -IL * Realiza el log en modo debug de los itemsets descubiertos (default = false)</pre> * * <pre> -MTS <umbral de soporte temporal> * Valor minimo para el umbral del soporte temporal (absoluto). (default=10)</pre> * * <pre> -THU <unidad histograma temporal> * Unidad de division del histograma temporal (absoluto) (default=5)</pre> * * <pre> -TU <unidad temporal dataset> * Unidad temporal manejada en el dataset (usada para los 4 parametros anteriores). * Valores: DAY (default)</pre> * * <pre> -SPC <nombre clase PredicateCalculator> * Nombre de la clase encargada del calculo de los componentes de los predicados espaciales. * Debe extender la clase weka.associations.spatiotemporal.predicates.PredicateCalculator. * (default "weka.associations.spatiotemporal.predicates.DistanceAnglePredicateGeographicCalculator")</pre> * * <pre> -SP1 <limite y etiquetas primer parametro comp. espaciales> * Valores de los limites (y etiquetas) de los intervalos del primer parametro de los componentes espaciales. * Notacion: LIM1[LAB1],LIM2[LAB2],...LIMn * Los valores se dan en orden creciente, salvo un par en caso de ser componente ciclico. * Ademas en este ultimo caso coinciden los extremos de la lista, para cerrar los valores del ciclo del componente * (default: "0[MC],200[C],500[MED],800[L],1200[ML],INF")</pre> * * <pre> -SP2 <limite y etiquetas segundo parametro comp. espaciales> * Valores de los limites (y etiquetas) de los intervalos del segundo parametro de los componentes espaciales. * Notacion: LIM1[LAB1],LIM2[LAB2],...LIMn . * Los valores se dan en orden creciente, salvo un par en caso de ser componente ciclico. * Ademas en este ultimo caso coinciden los extremos de la lista, para cerrar los valores del ciclo del componente * (default: "-157.5[SO],-112.5[S],-67.5[SE],-22.5[E],22.5[NE],67.5[N],112.5[NO],157.5[O],-157.5")</pre> *  * * @param options lista de opciones como arreglo de String * @throws Exception si una opcion no se encuentra soportada */ public void setOptions(String[] options) throws Exception { resetOptions(); String optionValue = Utils.getOption("MS", options); if (optionValue.length() > 0) this.setMinimumSupport(Double.parseDouble(optionValue)); optionValue = Utils.getOption("MC", options);

146

if (optionValue.length() > 0) this.setMinimumConfidence(Double.parseDouble(optionValue)); this.setOutputItemsets(Utils.getFlag('I', options)); this.setLogItemsets(Utils.getFlag("IL", options)); optionValue = Utils.getOption("MTS", options); if (optionValue.length() > 0) this.setMinimunTemporalSupport(Double.parseDouble(optionValue)); optionValue = Utils.getOption("THU", options); if (optionValue.length() > 0) this.setTemporalHistogramUnit(Double.parseDouble(optionValue)); optionValue = Utils.getOption("TU", options); if (optionValue.length() > 0) this.setTemporalUnit(optionValue); optionValue = Utils.getOption("SPC", options); if (optionValue.length() > 0) this.setPredicateCalculator(optionValue); optionValue = Utils.getOption("SP1", options); if (optionValue.length() > 0) this.setComponent1LimitsAndLabels(optionValue); optionValue = Utils.getOption("SP2", options); if (optionValue.length() > 0) this.setComponent2LimitsAndLabels(optionValue); } /** * Obtiene la configuracion actual de SpatioTemporalApriori * * @return arreglo de String, adecuando para ser pasado a {@link SpatioTemporalApriori#setOptions(String[])} */ public String [] getOptions() { String [] options = new String [18]; int current = 0; options[current++] = "-MS"; options[current++] = Double.toString(this.getMinimumSupport()); options[current++] = "-MC"; options[current++] = Double.toString(this.getMinimumConfidence()); if (this.isOutputItemsets()) options[current++] = "-I"; if (this.isLogItemsets()) options[current++] = "-IL"; options[current++] = "-MTS"; options[current++] = Double.toString(this.getMinimunTemporalSupport()); options[current++] = "-THU"; options[current++] = Double.toString(this.getTemporalHistogramUnit()); options[current++] = "-TU"; options[current++] = this.getTemporalUnit(); options[current++] = "-SPC"; options[current++] = this.getPredicateCalculator(); options[current++] = "-SP1"; options[current++] = this.getComponent1LimitsAndLabels(); options[current++] = "-SP2"; options[current++] = this.getComponent2LimitsAndLabels(); while (current < options.length) { options[current++] = ""; } return options; } /** * Retorna un string describiendo el Associator * * @return descripcion del Associator para ser


147

* mostrada en el explorer/experimenter gui */ public String globalInfo() { return "Implements the discovery of spatio-temporal association rules. The model is based on the ideas of "+ "the General Temporal Association Rules Model and the Inter-Transaction Association Rules applied to "+ "spatial attributes.\n"+ "The algorithm for the discovery of frequent itemsets is the STApriori Algorithm, "+ "based on the Apriori Algorithm. The rules are formed with an algorithm based on the Faster Algorithm "+ "(used with the Apriori Algorithm)."; } /** * Retorna el tip text para esta propiedad * * @return tip text de esta propiedad para ser * mostrada en el explorer/experimenter gui */ public String minimumSupportTipText() { return "Minimum support for a frequent itemset"; } /** * Retorna el tip text para esta propiedad * * @return tip text de esta propiedad para ser * mostrada en el explorer/experimenter gui */ public String minimumConfidenceTipText() { return "Minimum confidence for a rule"; } /** * Retorna el tip text para esta propiedad * * @return tip text de esta propiedad para ser * mostrada en el explorer/experimenter gui */ public String outputItemsetsTipText() { return "If the itemsets found are also shown"; } /** * Retorna el tip text para esta propiedad * * @return tip text de esta propiedad para ser * mostrada en el explorer/experimenter gui */ public String logItemsetsTipText() { return "If the itemsets found are also logged to files in debug mode"; } /** * Retorna el tip text para esta propiedad * * @return tip text de esta propiedad para ser * mostrada en el explorer/experimenter gui */ public String predicateCalculatorTipText()


148

{ return "Classname wich calculates predicate's components"; } /** * Retorna el tip text para esta propiedad * * @return tip text de esta propiedad para ser * mostrada en el explorer/experimenter gui */ public String component1LimitsAndLabelsTipText() { return "Limits (and labels) of the values for the first predicate's parameter"; } /** * Retorna el tip text para esta propiedad * * @return tip text de esta propiedad para ser * mostrada en el explorer/experimenter gui */ public String component2LimitsAndLabelsTipText() { return "Limits (and labels) of the values for the second predicate's parameter"; } /** * Retorna el tip text para esta propiedad * * @return tip text de esta propiedad para ser * mostrada en el explorer/experimenter gui */ public String minimunTemporalSupportTipText() { return "Minimum temporal support for a frequent itemset (absolute)"; } /** * Retorna el tip text para esta propiedad * * @return tip text de esta propiedad para ser * mostrada en el explorer/experimenter gui */ public String temporalUnitTipText() { return "Dataset's temporal unit (DAY, and others)"; } /** * Retorna el tip text para esta propiedad * * @return tip text de esta propiedad para ser * mostrada en el explorer/experimenter gui */ public String temporalHistogramUnitTipText() { return "Histogram temporal unit -\"delta t\"- (absolute)"; } /** * Retorna las Capabilities default del Associator * * @return capabilities del Associator * @see Capabilities */

149

public Capabilities getCapabilities() { Capabilities result = super.getCapabilities(); //esquema dataset: t+(posX,posY,att1=val1,....,attn=valn) // attributes - fecha + relacion con att=valor (nominal o binario) + posicion geografica (numerico) result.enable(Capability.DATE_ATTRIBUTES); result.enable(Capability.RELATIONAL_ATTRIBUTES); result.enable(Capability.NOMINAL_ATTRIBUTES); result.enable(Capability.BINARY_ATTRIBUTES); result.enable(Capability.NUMERIC_ATTRIBUTES); // class - los dataset vienen sin clase result.enable(Capability.NO_CLASS); return result; } /* (non-Javadoc) * @see java.lang.Object#toString() */ @Override public String toString() { StringBuffer text = new StringBuffer(); text.append("Spatio-Temporal Apriori\n=======================\n\n"); //parameters text.append("Parameters\n----------\n"); text.append("Minimum Support: ").append(this.minimumSupport).append("\n"); text.append("Minimum Temporal Support: ").append(this.minimumTemporalSupport); text.append(" "+this.getTemporalUnit()).append("\n"); text.append("Minimum Confidence: ").append(this.minimumConfidence).append("\n"); text.append("Temporal Histogram Unit: ").append(this.getTemporalHistogramUnit()) .append(" "+this.getTemporalUnit()).append("\n"); text.append("Spatial Predicate Calculator: ").append(this.getPredicateCalculator()).append("\n"); text.append("Spatial Predicates Parameters 1: ").append(this.getComponent1LimitsAndLabels()).append("\n"); text.append("Spatial Predicates Parameters 2: ").append(this.getComponent2LimitsAndLabels()).append("\n"); if (this.isOutputItemsets()) { text.append("Discovered Itemsets shown.\n"); } if (this.isLogItemsets()) { text.append("Discovered Itemsets reported.\n"); } //totals int totalSizeFrequentItemsets = 0; FastVector itemsets; for (int i = 0; i < this.frequentItemsetsSets.size(); i++) { itemsets = (FastVector) this.frequentItemsetsSets.elementAt(i); totalSizeFrequentItemsets += itemsets.size(); } text.append("\nTotal Summaries"); text.append("\n-----------------"); text.append("\nFrequent Itemsets Discovered: \n"); text.append("\tTotal: ").append(totalSizeFrequentItemsets)

150

.append(" - Time: ").append(this.frequentItemsetsDiscoveredTime); text.append("\nSpatio-Temporal Association Rules Discovered: \n"); text.append("\tTotal: ").append(this.spatioTemporalAssociationRules.size()) .append(" - Time: ").append(this.spatioTemporalAssociationRulesDiscoveredTime); //frequent itemsets text.append("\n\nSets of frequent Itemsets Discovered"); text.append("\n-----------------------------------\n"); for (int i = 0; i < this.frequentItemsetsSets.size(); i++) { itemsets = (FastVector) this.frequentItemsetsSets.elementAt(i); text.append("Size of frequent itemsets L("+(i+1)+"): ").append(itemsets.size()); if (this.isLogItemsets()) text.append(" - Report File: " + this.reportItemsetFileName(i+1)); text.append("\n"); if (this.isOutputItemsets()) { text.append("\n"); for (int j = 0; j < itemsets.size(); j++) { SpatioTemporalAprioriItemset itemset = (SpatioTemporalAprioriItemset) itemsets.elementAt(j); text.append((j+1)+"). ").append(itemset.toString(this.transactions)).append("\n"); } text.append("\n"); } } //spatio-temporal asocciation rules text.append("\nSpatio-Temporal Association Rules Discovered"); text.append("\n--------------------------------------------\n"); SpatioTemporalAssociationRule rule; for (int i = 0; i < this.spatioTemporalAssociationRules.size(); i++) { rule = (SpatioTemporalAssociationRule)this.spatioTemporalAssociationRules.elementAt(i); text.append((i+1)+"). ").append(rule.toString(this.transactions)).append("\n"); } return text.toString(); } /** * Inicializa parametros internos utilizados en el descubrimiento de * los itemsets espacio-temporales frecuentes */ private void initInternalParameters(Instances data) throws Exception { //general this.transactions = data; //por si se necesitan en varias iteraciones Date now = new Date(); SimpleDateFormat formatter = new SimpleDateFormat("yyyyMMddHHmmss"); this.executionIdentifier = formatter.format(now); this.logger = new Log("STAR."+this.executionIdentifier+".txt"); //espacial this.predicates = new PredicateSet(this.predicateCalculatorString, this.component1Limits, this.component2Limits, this.component1Labels, this.component2Labels); //temporal Stats temporalStats = data.attributeStats(0).numericStats; //maxTimestamp -> sumo 1 unidad temporal para tomar extremo superior incluido //temporalHistogramUnit por temporalUnit para dar valor en milisegundos

151

this.temporalHistogram = new TemporalHistogram(temporalStats.min, (temporalStats.max + this.temporalUnit), this.temporalUnit, this.temporalHistogramUnit); } /* (non-Javadoc) * @see weka.associations.Associator#buildAssociations(weka.core.Instances) */ @Override public void buildAssociations(Instances data) throws Exception { this.initInternalParameters(data); Clock clock = new Clock(); buildAllAssociations(); clock.stop(); this.logTimeMedition("buildAssociations()", clock.toString()); } /** * Obtiene todas las reglas de asociacion espacio-temporales en base a * los parametros definidos * @throws Exception */ protected void buildAllAssociations() throws Exception { Clock clock = new Clock(); this.findFrequentItemSets(); clock.stop(); this.frequentItemsetsDiscoveredTime = clock.toString(); int totalSizeFrequentItemsets = 0; FastVector itemsets; for (int i = 0; i < this.frequentItemsetsSets.size(); i++) { itemsets = (FastVector) this.frequentItemsetsSets.elementAt(i); totalSizeFrequentItemsets += itemsets.size(); } this.logTimeMedition("buildAllAssociations()", "findFrequentItemsets: "+ this.frequentItemsetsDiscoveredTime + " (" + totalSizeFrequentItemsets + ")"); clock.start(); this.findRulesFaster(); clock.stop(); this.spatioTemporalAssociationRulesDiscoveredTime = clock.toString(); this.logTimeMedition("buildAllAssociations()", "findRulesFaster: " + this.spatioTemporalAssociationRulesDiscoveredTime + " (" + this.spatioTemporalAssociationRules.size() + ")"); } /** * Devuelve el nombre del archivo que reporta los itemsets encontrados del tamaño dado * @param size * @return */ private String reportItemsetFileName(int size) { return (this.executionIdentifier + "_L" + size + ".txt"); } /** * Genera el archivo que reporta los itemsets del tamaño indicado durante la * ejecucion del algortimo * @param itemsets

152

* @param size */ private void reportItemsets(FastVector itemsets, int size) { String fileName = this.reportItemsetFileName(size); PrintWriter out; try { out = new PrintWriter(new BufferedWriter(new FileWriter(fileName))); } catch (IOException e) { this.logger.log(Level.WARNING, SpatioTemporalApriori.class.getSimpleName(), "reportItemsets(FastVector, int)", "Cannot create Itemsets report file " + fileName); return; } out.println("L(" + size + ") - size: " + itemsets.size()); out.println("----------------------------------------------------------------------------------"); for (int i = 0; i < itemsets.size(); i++) { out.print(itemsets.elementAt(i)); } out.close(); } /** * Descubre todos los itemsets frecuentes para el conjunto de transacciones dado * (algoritmo STApriori) * * @throws Exception */ protected void findFrequentItemSets() throws Exception { FastVector kMinusOneSets, kSets; Hashtable hashtable; int k = 1; Clock clock = new Clock(); this.frequentItemsetsSets = new FastVector(); this.frequentItemsetHashtables = new FastVector(); kSets = SpatioTemporalAprioriItemset.singletons(transactions,this.predicates,this.temporalHistogram); clock.stop(); this.logTimeMedition("findFrequentItemSets()","singletons : " + clock.toString()); clock.start(); SpatioTemporalAprioriItemset.upDateCounters(kSets,transactions,this.temporalHistogram); clock.stop(); this.logTimeMedition("findFrequentItemSets()","updateCounters ("+kSets.size()+") - k = "+ k +": " + clock.toString()); clock.start(); //el soporte debe ser relativo //el temporal absoluto en milisegundos, se le resta una unidad para considerar intervalos inclusivos


153

double absoluteTemporalSupport = (this.minimumTemporalSupport - 1) * this.temporalUnit; kSets = SpatioTemporalAprioriItemset.verifyFrecuentItemSet(kSets, this.minimumSupport, absoluteTemporalSupport); clock.stop(); this.logTimeMedition("findFrequentItemSets()","verifyFrecuentItemSet - k = "+ k + " (" + kSets.size() + "): " + clock.toString()); if (this.isLogItemsets()) this.reportItemsets(kSets, k); if (kSets.size() == 0) return; do { frequentItemsetsSets.addElement(kSets); kMinusOneSets = kSets; clock.start(); kSets = SpatioTemporalAprioriItemset.mergeAllItemSets(kMinusOneSets, k, absoluteTemporalSupport); clock.stop(); this.logTimeMedition("findFrequentItemSets()","mergeAllItemSets ("+kMinusOneSets.size()+") - k = "+ k + " (" + kSets.size() + "): " + clock.toString()); hashtable = SpatioTemporalAprioriItemset.getHashtable(kMinusOneSets, kMinusOneSets.size()); frequentItemsetHashtables.addElement(hashtable); //para k=1 la hashtable se va a utilizar en la generacion de las reglas if (k > 1) //para k=1 no es necesario realizar poda porque el itemset se formo con componentes frecuentes { clock.start(); kSets = SpatioTemporalAprioriItemset.pruneItemSets(kSets, hashtable, absoluteTemporalSupport); clock.stop(); this.logTimeMedition("findFrequentItemSets()","pruneItemSets - k = "+ (k+1) +": " + clock.toString()); } clock.start(); SpatioTemporalAprioriItemset.upDateCounters(kSets, transactions); clock.stop(); this.logTimeMedition("findFrequentItemSets()","updateCounters ("+kSets.size()+") - k = "+ (k+1) +": " + clock.toString()); clock.start(); kSets = SpatioTemporalAprioriItemset.verifyFrecuentItemSet(kSets, this.minimumSupport, absoluteTemporalSupport); clock.stop(); this.logTimeMedition("findFrequentItemSets()","verifyFrecuentItemSet - k = "+ (k+1) + " (" + kSets.size() + "): " + clock.toString()); k++; if ( (this.isLogItemsets()) && (kSets.size() > 0)) this.reportItemsets(kSets, k); } while (kSets.size() > 0); } /** * Obtiene todas las reglas de asociacion espacio-temporales en base a * los itemsets frecuentes descubiertos

154

* (extension de Faster Algorithm) * * @throws Exception */ protected void findRulesFaster() throws Exception { this.spatioTemporalAssociationRules = new FastVector(); for (int j = 1; j < frequentItemsetsSets.size(); j++) { FastVector currentItemSets = (FastVector)frequentItemsetsSets.elementAt(j); Enumeration enumItemSets = currentItemSets.elements(); while (enumItemSets.hasMoreElements()) { SpatioTemporalAprioriItemset currentItemSet = (SpatioTemporalAprioriItemset)enumItemSets.nextElement(); spatioTemporalAssociationRules.appendElements(currentItemSet.generateRules(j + 1, frequentItemsetHashtables, minimumConfidence)); } } } /** * Loggea el tiempo medido con el metodo y mensaje dados para la clase actual * @param methodName * @param message */ protected void logTimeMedition(String methodName, String message) { this.logger.log(Level.FINE, this.getClass().getSimpleName(), methodName, message); } /** * Metodo Main * * @param args opciones de linea de comandos */ public static void main(String[] args) { try { runAssociator(new SpatioTemporalApriori(), args); } catch (Exception e) { e.printStackTrace(); } } } /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.


155

*/ package weka.associations.spatiotemporal; import java.beans.Expression; import java.util.Arrays; import java.util.Enumeration; import java.util.Hashtable; import weka.associations.ItemSet; import weka.associations.spatiotemporal.predicates.Point; import weka.associations.spatiotemporal.predicates.PointPair; import weka.associations.spatiotemporal.predicates.Predicate; import weka.associations.spatiotemporal.predicates.PredicateSet; import weka.associations.spatiotemporal.temporal.TemporalHistogram; import weka.core.FastVector; import weka.core.Instance; import weka.core.Instances; import weka.core.Utils; /** * Permite el manejo de un itemset espacio-temporal. * Se utiliza dentro del algoritmo de la clase SpatioTemporalApriori, utilizado para el * descubrimiento de las reglas de asociacion espacio-temporales. * * @author Mariano Kohan ([email protected]) * */ public class SpatioTemporalAprioriItemset extends ItemSet { protected static int MAX_GEOGRAPHIC_DIM = 2; //nro. dimensiones de valores geograficos protected static double NULL_TEMP = -1.0; //valor temporal para no representar valor //m_items pasa a almacenar el primer item que compone el STItemset (principal) /** * Items que conforman el itemset y se encuentran relacionados * con respecto al item principal */ protected FastVector[] itemsRelated=null; /** * Predicados espaciales que relacionan a las posiciones de los items anteriores * con respecto a la del item principal */ protected FastVector[] predS=null; //m_totalTransactions almacena la cantidad de transacciones del dataset (se mantiene por compatibilidad) //m_counter almacena la cuenta de la cantidad de transacciones donde se verifica // el itemset dentro del lifespan del mismo /** * Cantidad de transacciones dentro del lifespan */ protected int totalTransactionsLifespan; /** * Contador auxiliar al atributo anterior * para el calculo del lifespan dinamicamente */


156

protected int totalAux; /** * Posiciones geograficas dentro de cada transaccion * donde se verifica el 1-itemsets (k=1) */ //Uso para poda de C2 en base a predicados segun elementos de L1 protected FastVector positions; /** * Lifespan del itemset (extremos min y max) */ protected double[] lifespan = null; /** * Lifespan "necesario" del itemset (extremos min y max) * (lifespan del itemset se encuentra contenido o es igual a su lifespan necesario) */ //utilizado en poda temporal de candidatos generados protected double[] neededLifespan = null; /** * Lifespan frecuente del itemset - lista ("conjunto") de intervalos * maximales contenidos dentro del lifespan donde el itemset espacio-temporal es frecuente */ //cada intervalo se almacena como double[2] (de la misma manera que el lifespan) protected FastVector frequentLifespan = null; /** * Soporte para cada uno de los subintervalos maximales que componen el lifespan frecuente */ protected FastVector frequentLifespanSupport; /** * Histograma con contadores de cantidad de transacciones que verifican * el itemset dentro de pequeños intervalos deltaT */ protected FastVector temporalHistogram = null; /** * Indice de posicion del histograma temporal del itemset respecto al * histograma temporal del dataset */ protected int temporalHistogramPosition; /** * Conjunto de predicados de la instancia del algoritmo en ejecucion */ protected PredicateSet predicateSet = null; /** * Histograma temporal del dataset */ protected TemporalHistogram datasetTemporalHistogram; /** * Constructor con compatibilidad padres * * @param totalTransactions */ public SpatioTemporalAprioriItemset(int totalTransactions) { super(totalTransactions);

157

this.lifespan = null; this.m_counter = 0; this.totalTransactionsLifespan = 0; this.totalAux = 0; } /** * Constructor que crea un itemset * Inicializa la estructura interna del itemset * * @param totalTransaction * @param maxk cantidad de atributos manejados por el itemset * @param predicateSet conjunto de predicados espaciales del algoritmo * @param datasetTemporalHistogram histograma temporal del dataset */ public SpatioTemporalAprioriItemset(int totalTransaction, int maxk, PredicateSet predicateSet, TemporalHistogram datasetTemporalHistogram) { this(totalTransaction); this.m_items = new int[maxk]; for (int k = 0; k < this.m_items.length; k++) { this.m_items[k]=-1; } //m_itemsRel, m_PredS ==null => k=1 y PredS={} this.predicateSet = predicateSet; this.datasetTemporalHistogram = datasetTemporalHistogram; //para cualquier k el lifespan y el histograma temporal se van a armar de manera dinámica this.lifespan = new double[]{NULL_TEMP, NULL_TEMP}; //sin lifespan this.temporalHistogram = new FastVector(); } /** * Constructor que crea un itemset de tamaño 1 * Inicializa la estructura interna del itemset * * @param totalTransaction * @param maxk cantidad de atributos manejados por el itemset * @param indexAttribute indice del atributo con valor inicial * @param indexValue indice del valor asignado al atributo anterior * @param predicateSet conjunto de predicados espaciales del algoritmo * @param datasetTemporalHistogram histograma temporal del dataset */ public SpatioTemporalAprioriItemset(int totalTransaction, int maxk, int indexAttribute, int indexValue, PredicateSet predicateSet, TemporalHistogram datasetTemporalHistogram) { this(totalTransaction, maxk, predicateSet, datasetTemporalHistogram); this.m_items[indexAttribute] = indexValue; } /** * @return the lifespan */ public double[] getLifespan() { return lifespan; } /** * @return the positions

158

*/ public FastVector getPositions() { return positions; } /** * Retorna el conjunto de predicados utilizado por el itemset en * la instancia de ejecucion actual del algoritmo * * @return the predicateSet */ public PredicateSet getPredicateSet() { return predicateSet; } /** * Retorna la cantidad de atributos del itemset * * @return */ protected int getNumberAttributes() { return this.m_items.length; } /** * Devuelve la cantidad de items relacionados, respecto al principal, * que forman parte del itemset * * @return */ public int getNumerRelatedItems() { int num = 0; if (this.itemsRelated == null) return num; for (int i = 0; i < this.itemsRelated.length; i++) { if (this.itemsRelated[i] != null) num += this.itemsRelated[i].size(); } return num; } /* (non-Javadoc) * @see java.lang.Object#toString() */ @Override public String toString() { StringBuffer text = new StringBuffer(); text.append("{"); if ( this.getPrincipalItemIndex() == -1) text.append("*"); else text.append(this.getPrincipalItemIndex()).append(" = ").append(this.m_items[this.getPrincipalItemIndex()]); if (this.itemsRelated != null) { FastVector relateds, predicates; for (int i = 0; i < this.itemsRelated.length; i++) { relateds = (FastVector) this.itemsRelated[i]; if (relateds != null) {

159

predicates = (FastVector) this.predS[i]; for (int j = 0; j < relateds.size(); j++) { text.append(" , ").append(i + " = ").append(relateds.elementAt(j)).append(" (" + predicates.elementAt(j) + ")"); } } } } text.append("} \n "); if (this.lifespan != null) text.append(" |--["+new java.util.Date((new Double(this.lifespan[0])).longValue())+"; "). append(new java.util.Date((new Double(this.lifespan[1])).longValue()) +"]"); if (this.temporalSupport() != Double.NaN) text.append("(|| = "+String.format("%.6f",this.temporalSupport())+")\n"); if (this.lifespanSupport() != Double.POSITIVE_INFINITY) text.append(" |--[ "+ this.m_counter + "/" + this.totalTransactionsLifespan + " ] ("+String.format("%.6f",this.lifespanSupport())+") \n"); if (this.haveFrequentLifespan()) { text.append(" |--{"); double[] interval; for (int i = 0; i < this.frequentLifespan.size(); i++) { interval = (double[])this.frequentLifespan.elementAt(i); text.append("["+new java.util.Date((new Double(interval[0])).longValue())+"; ") .append(new java.util.Date((new Double(interval[1])).longValue()) +"] , "); } text.delete(text.lastIndexOf(", "), text.length()); text.append("}"); text.append("\n |--{"); for (int i = 0; i < this.frequentLifespanSupport.size(); i++) { text.append(((Double)this.frequentLifespanSupport.elementAt(i)).toString() + ", "); } text.delete(text.lastIndexOf(", "), text.length()); text.append("}\n"); } return text.toString(); } /** * Obtiene una representacion textual del itemset espacio-temporal * para ser mostrada al usuario dentro de las reglas descubiertas * (solo items junto con sus variables de posicion) * * @param instances instancias sobre las se va a representar el itemset * (tienen informacion sobre los valores de discretizacion de los atributos) * @param pos posicion inicial de numeracion de las variables de posicion de los items relacionados * (el principal siempre es 1 => > 1) * @return */ public String itemsToString(Instances instances,int pos) { StringBuffer text = new StringBuffer(); Integer itemValue; //Se supone el atributo 1 son los datos espaciales para un t

160

Instances spatialInstances = instances.attribute(1).relation(); int pcpalPos = this.getPrincipalItemIndex(); if (pcpalPos != -1) { text.append(spatialInstances.attribute(pcpalPos+MAX_GEOGRAPHIC_DIM).name()); text.append(" = "); text.append(spatialInstances.attribute(pcpalPos+MAX_GEOGRAPHIC_DIM).value(this.m_items[pcpalPos])); text.append("(POS1), "); } if (this.itemsRelated != null) //los primeros atributos son los componentes de la posicion for (int i = MAX_GEOGRAPHIC_DIM; i < spatialInstances.numAttributes(); i++) { if (this.itemsRelated[i-MAX_GEOGRAPHIC_DIM] != null) { for (int j = 0; j < this.itemsRelated[i-MAX_GEOGRAPHIC_DIM].size(); j++) { itemValue = (Integer)this.itemsRelated[i-MAX_GEOGRAPHIC_DIM].elementAt(j); text.append(spatialInstances.attribute(i).name()); text.append(" = "); text.append(spatialInstances.attribute(i).value(itemValue.intValue())); text.append("(POS"+pos+"), "); pos++; } } } text.delete(text.lastIndexOf(", "), text.length()); return text.toString(); } /** * Obtiene una representacion textual del itemset espacio-temporal * para ser mostrada al usuario dentro de las reglas descubiertas * (solo items junto con sus variables de posicion) * Comienza a numerar las variables de posicion de los items relacionados desde 2 * (el principal siempre se numera en 1) * * @param instances instancias sobre las se va a representar el itemset * (tienen informacion sobre los valores de discretizacion de los atributos) */ public String itemsToString(Instances instances) { return this.itemsToString(instances, 2); } /* (non-Javadoc) * @see weka.associations.ItemSet#toString(weka.core.Instances) */ @Override public String toString(Instances instances) { StringBuffer text = new StringBuffer(); text.append("{ ").append(this.itemsToString(instances)).append(" }\n"); text.append("\t[ { ").append(this.getPredSString()).append(" } ; "); if (this.haveFrequentLifespan()) { text.append(this.getFrequentLifeSpanString());

161

} else { text.append(this.getLifeSpanString()); } text.append(" ]\n\t[ "); if (this.haveFrequentLifespan()) { text.append(this.supportInFrequentLifespanString()); } else { text.append(Utils.doubleToString(this.lifespanSupport(),4)); } text.append(" ]"); if (this.haveFrequentLifespan()) { text.append("\n\t( lifespan = ").append(this.getLifeSpanString()) .append(" - [ ").append(Utils.doubleToString(this.lifespanSupport(),4)).append(" ] )"); } return text.append("\n").toString(); } /** * Obtiene una representacion textual del conjunto de predicados de un itemset (PredS) * para ser mostrada al usuario dentro de las reglas descubiertas * (hace referencia a las variables de posicion (propias de cada item)=> usar con itemsets * premisa o consecuente) * * @param pos posicion inicial de numeracion de las variables de posicion de los items relacionados * (el principal siempre es 1 => > 1) * @return */ public String getPredSString(int pos) { StringBuffer text = new StringBuffer(); Integer predicateIndex; if (this.predS != null) { for (int i = 0; i < this.predS.length; i++) { if (this.predS[i] != null) { for (int j = 0; j < this.predS[i].size(); j++) { predicateIndex = (Integer)this.predS[i].elementAt(j); text.append(this.predicateSet.getPredicate(predicateIndex.intValue())); text.append("(POS1,POS"+pos+"), "); pos++; } } } text.delete(text.lastIndexOf(", "), text.length()); } return text.toString(); } /** * Obtiene una representacion textual del conjunto de predicados de un itemset (PredS) * para ser mostrada al usuario dentro de las reglas descubiertas

162

* (hace referencia a las variables de posicion (propias de cada item)=> usar con itemsets * premisa o consecuente) * La posicion inicial de las variables de posicion de los items relacionados se toma en 2 * * @return */ public String getPredSString() { return this.getPredSString(2); } /** * Obtiene una descripcion textual del lifespan del itemset * para ser mostrada al usuario dentro de las reglas de asociacion descubiertas * (deberia usarse con un itemset union que represente a la regla) * * @return */ public String getLifeSpanString() { StringBuffer text = new StringBuffer(); text.append("["); text.append(new java.util.Date((new Double(this.lifespan[0])).longValue())); text.append("; "); text.append(new java.util.Date((new Double(this.lifespan[1])).longValue())); text.append("]"); return text.toString(); } /** * Obtiene una descripcion textual del lifespan frecuente del itemset * * @return */ public String getFrequentLifeSpanString() { FastVector frecuentLifespan = this.frequentLifespan; StringBuffer text = new StringBuffer(); double[] interval; text.append("{ "); for (int i = 0; i < frecuentLifespan.size(); i++) { interval = (double[])frecuentLifespan.elementAt(i); text.append("["); text.append(new java.util.Date((new Double(interval[0])).longValue())); text.append("; "); text.append(new java.util.Date((new Double(interval[1])).longValue())); text.append("], "); } text.delete(text.lastIndexOf(", "), text.length()); text.append(" }"); return text.toString(); } /** * Devuelve una representacion en string del soporte del itemset * en su lifespan frecuente * * @return */ public String supportInFrequentLifespanString() { FastVector support = this.frequentLifespanSupport;

163

StringBuffer text = new StringBuffer(); text.append("{ "); for (int i = 0; i < support.size(); i++) { text.append(Utils.doubleToString(((Double)support.elementAt(i)).doubleValue(),4)).append(", "); } text.delete(text.lastIndexOf(", "), text.length()); text.append(" }"); return text.toString(); } /** * Indica si el itemset es de tamaño k=1 * * @return */ public boolean isOneItemSet() { if ( (this.itemsRelated == null) && (this.predS == null)) { return true; } return false; } /** * Indica si el itemset se encuentra contenido dentro del dataset * (fue verificado en alguna transaccion) * * @return */ public boolean containedInDataset() { if (this.lifespan[0] > 0) return true; return false; } /** * Devuelve el indice del item principal del itemset (el primero) * * @return */ private int getPrincipalItemIndex() { //sup.: siempre va a existir unicamente un solo item en m_items for (int i = 0; i < m_items.length; i++) { if (m_items[i] != -1) return i; } return -1; } /** * Indica si el lifespan del itemset incluye el timestamp dado * * @param timestamp * @return */ public boolean lifespanInclude(double timestamp) { if ( (this.lifespan[0] <= timestamp) && (timestamp <= this.lifespan[1])) return true; return false;

164

} /** * Indica si el itemset se verifica en la transaccion * "Sobreescribiria" ItemSet#containedBy(Instance) al caso espacio-temporal * (se cambio el concepto a verifica en el modelo) * * @param instance * @return */ public boolean verifiedBy(Instance instance) { boolean verify=false; Instances spatialInstances = instance.relationalValue(1); Instance spatialInstance = null; if (this.isOneItemSet()) { //existe un itemset en la transaccion igual al item actual (el unico componente del itemset) for (int i = 0; i < spatialInstances.numInstances(); i++) { boolean verifyItem = false; spatialInstance = spatialInstances.instance(i); if (m_items[this.getPrincipalItemIndex()] == spatialInstance.value(MAX_GEOGRAPHIC_DIM + this.getPrincipalItemIndex())) { return true; } verify = verifyItem; } } else { //No verifico mas que la transaccion se encuentre dentro del lifespan del itemset //ya que la misma no tiene determinado su lifespan de antemano, debido a que el //mismo no se puede calcular previamente sino que se arma de forma dinamica //exite un item en la transaccion igual al item principal //para los demas items: existe en la transaccion y //entre la posicion del item pcpal. y el item actual (dentro de la transaccion) //se verifica el predicado entre ambos (definido en el itemset) FastVector principalPositions = new FastVector(); Point principalPosition = null; String pointClassName = this.getPredicateSet().getPredicateCalculator().getPointClassName(); Class pointClass = null; try { pointClass = Class.forName(pointClassName); } catch (ClassNotFoundException e) { System.out.println("Point class not found: "+pointClassName); } for (int i = 0; i < spatialInstances.numInstances(); i++) { spatialInstance = spatialInstances.instance(i); if (m_items[this.getPrincipalItemIndex()] == spatialInstance.value(this.getPrincipalItemIndex() + MAX_GEOGRAPHIC_DIM)) { Expression expression = new Expression(pointClass,"new", new Object[] { spatialInstance.value(0), spatialInstance.value(1) });

165

try { expression.execute(); principalPositions.addElement(expression.getValue()); } catch (Exception e) { System.out.println("Exception during Point instanstiation: "); e.printStackTrace(); } } } //para cada posicion principal veo si existe item relacionado y posicion destino que cumpla predicado principals: for (int pos = 0; pos < principalPositions.size(); pos++) { verify = true; principalPosition = (Point)principalPositions.elementAt(pos); Point destinationPosition = null; relateds: for (int i = 0; i < this.itemsRelated.length; i++) { if (this.itemsRelated[i] != null) { for (int j = 0; j < itemsRelated[i].size(); j++) { boolean verifyItem = false; for (int k = 0; k < spatialInstances.numInstances(); k++) { spatialInstance = spatialInstances.instance(k); if (((Integer)itemsRelated[i].elementAt(j)).doubleValue() == spatialInstance.value(i + MAX_GEOGRAPHIC_DIM)) { //verificar predicado Expression expression = new Expression(pointClass,"new", new Object[] { spatialInstance.value(0), spatialInstance.value(1) }); try { expression.execute(); destinationPosition = (Point)expression.getValue(); } catch (Exception e) { System.out.println("Exception during Point instanstiation: "); e.printStackTrace(); } Predicate predicate = this.getPredicateSet().getPredicate( ((Integer)this.predS[i].elementAt(j)).intValue()); if (predicate.evaluate(principalPosition, destinationPosition)) { verifyItem = true; break; } } } if (!verifyItem) { verify =false; break relateds;

166

} } } } if (verify) break; } } return verify; } /** * Para un 1-itemset, actualiza los valores en el vector de positions, anexando los elementos nuevos * (encuentra las posiciones donde se verifica el itemset para la transaccion actual) * Supone que el itemset ya se verifica en (alguna posicion de) la misma * * @param instance * @return */ protected void updateInstancePositions(Instance instance) { if (!this.isOneItemSet()) { return; } if (this.positions == null) { this.positions = new FastVector(); } //recorre instances espaciales: si verifica => agregar posicion p/resultado Instances spatialInstances = instance.relationalValue(1); Instance spatialInstance = null; String pointClassName = this.getPredicateSet().getPredicateCalculator().getPointClassName(); Class pointClass = null; try { pointClass = Class.forName(pointClassName); } catch (ClassNotFoundException e) { System.out.println("Point class not found: "+pointClassName); } for (int i = 0; i < spatialInstances.numInstances(); i++) { spatialInstance = spatialInstances.instance(i); if (m_items[this.getPrincipalItemIndex()] == spatialInstance.value(MAX_GEOGRAPHIC_DIM + this.getPrincipalItemIndex())) { Expression expression = new Expression(pointClass,"new", new Object[] { spatialInstance.value(0), spatialInstance.value(1) }); try { expression.execute(); if ( this.positions.indexOf(expression.getValue()) == -1 ) { positions.addElement(expression.getValue()); } } catch (Exception e) { System.out.println("Exception during Point instanstiation: "); e.printStackTrace(); }

167

} } } /** * Actualiza el histograma temporal (de manera dinamica) para el caso que el itemset * se verifica en la transaccion * * @param instance */ private void updateTemporalHistogram(Instance instance) { int intervalPosition = datasetTemporalHistogram.getTemporalPosition(instance.value(0)); Integer counter; if (this.temporalHistogram.size() == 0) { this.temporalHistogramPosition = intervalPosition; } intervalPosition -= this.temporalHistogramPosition; if (intervalPosition < this.temporalHistogram.size()) { counter = (Integer) this.temporalHistogram.elementAt(intervalPosition); this.temporalHistogram.setElementAt(new Integer(counter.intValue() + 1), intervalPosition); } else //posible para todo k (armado de histograma de manera dinamica) { while (this.temporalHistogram.size() < intervalPosition) { counter = new Integer(0); this.temporalHistogram.addElement(counter); } counter = new Integer(1); this.temporalHistogram.addElement(counter); } } /* * Contabilizacion del itemset * (non-Javadoc) * @see weka.associations.ItemSet#upDateCounter(weka.core.Instance) */ public void upDateCounter(Instance instance) { if (this.verifiedBy(instance)) { this.m_counter++; if (this.lifespan[0] == NULL_TEMP) { this.lifespan[0] = instance.value(0); this.lifespan[1] = instance.value(0); } if (instance.value(0) > this.lifespan[1]) //para todo k { this.lifespan[1] = instance.value(0); this.totalTransactionsLifespan += this.totalAux; this.totalAux = 0; } if (this.isOneItemSet()) { this.updateInstancePositions(instance); } this.updateTemporalHistogram(instance); }

168

if (this.lifespanInclude(instance.value(0))) //cualquier k, cuando se verifica el //itemset en la transaccion incremento directamente el total de transacciones en el lifespan { this.totalTransactionsLifespan++; //sino no se incrementan nunca //y evito ciclo posterior } else //cualquier k, cuando no se verifica el itemset en la transaccion //incremento el contador auxiliar por si verifica a futuro { if (this.containedInDataset()) { this.totalAux++; } } } /** * Descubre el lifespan frecuente del itemset, si tiene * (conjunto de subintervalos maximales frecuentes contenidos dentro del lifespan) * Corresponde a la funcion a-posteriori * * @param minSupport * @param minTemporalSupport */ public void discoverFrequentLifespan(double minSupport, double minTemporalSupport) { int initialIntervalIndex = 0, lastIntervalIndex; double countSum, transactionsSum; double support, temporalSupport; int initialPosition, lastPosition; int intervalsNumber = this.temporalHistogram.size(); while (initialIntervalIndex < intervalsNumber) { lastIntervalIndex = 0; countSum = 0; for (int i = initialIntervalIndex; i < intervalsNumber; i++) countSum += ((Integer)this.temporalHistogram.elementAt(i)).intValue(); transactionsSum = 0; for (int i = (initialIntervalIndex + this.temporalHistogramPosition) ; i < ( intervalsNumber + this.temporalHistogramPosition ) ; i++) transactionsSum += datasetTemporalHistogram.getTransactionsNumber(i); support = countSum / transactionsSum; //lastIntervalIndex = 0 => extremo del lifespan => debo tomar hasta el punto de corte y no todo el intervalo //obs.: si solo consideraria el corte para el histograma del dataset solamente, deberia determinar si el //ultimo intervalo del histograma del itemset es el mismo que el ultimo intervalo del histograma del dataset //Para el caso de considerar el corte del histograma del itemset esto no trae problema if (initialIntervalIndex == 0) { //tambien es el extremo inicial => resta de extremos temporalSupport = this.temporalSupport(); } else { //solo considero el extremo en el ultimo intervalo temporalSupport = (intervalsNumber - initialIntervalIndex - 1) * datasetTemporalHistogram.getIntervalWidthUnit();

169

temporalSupport += this.lifespan[1] - datasetTemporalHistogram.getIntervalMinimum(intervalsNumber - 1 + this.temporalHistogramPosition); } while ((support < minSupport) && (temporalSupport >= minTemporalSupport) ) { lastIntervalIndex++; countSum -= ((Integer)this.temporalHistogram.elementAt (intervalsNumber - lastIntervalIndex)).intValue(); transactionsSum -= datasetTemporalHistogram.getTransactionsNumber( intervalsNumber - lastIntervalIndex + this.temporalHistogramPosition); support = countSum / transactionsSum; if (initialIntervalIndex == 0) { //considero extremo en el primer intervalo temporalSupport = (intervalsNumber - lastIntervalIndex - 1) * datasetTemporalHistogram.getIntervalWidthUnit(); temporalSupport += datasetTemporalHistogram.getIntervalMaximum(this.temporalHistogramPosition) - this.lifespan[0]; } else { //sin problema de extremos temporalSupport = (intervalsNumber - lastIntervalIndex - initialIntervalIndex) * datasetTemporalHistogram.getIntervalWidthUnit(); //resto una unidad temporal porque asi se esta considerando el umbral del soporte temporal temporalSupport -= this.datasetTemporalHistogram.getTemporalUnit(); } } if (temporalSupport >= minTemporalSupport) { initialPosition = initialIntervalIndex; initialIntervalIndex = intervalsNumber - lastIntervalIndex; lastPosition = initialIntervalIndex - 1 ; if (this.frequentLifespan == null) { this.frequentLifespan = new FastVector(); this.frequentLifespanSupport = new FastVector(); } double minSubinterval; double maxSubinterval; //limito el extremo del subintervalo segun si estoy en el delta t inicial if (initialPosition == 0) { minSubinterval = this.lifespan[0]; } else { minSubinterval = datasetTemporalHistogram.getIntervalMinimum(initialPosition + this.temporalHistogramPosition); } //limito el extremo del subintervalo segun si estoy en el delta t final if (lastPosition == intervalsNumber - 1) { maxSubinterval = this.lifespan[1]; } else {

170

maxSubinterval = datasetTemporalHistogram.getIntervalMaximum(lastPosition + this.temporalHistogramPosition); } this.frequentLifespan.addElement( new double[]{ minSubinterval, maxSubinterval} ); this.frequentLifespanSupport.addElement(new Double(support)); } else initialIntervalIndex++; } } /** * Devuelve el soporte del itemset en su lifespan (relativo) * * @return */ public double lifespanSupport() { if (this.m_counter == 0) return 0.0; if (this.totalTransactionsLifespan == 0) return Double.POSITIVE_INFINITY; return ((double)this.m_counter/(double)this.totalTransactionsLifespan); } /** * Devuelve la estimacion del soporte en el intervalo dado, * en base a informacion de los histogramas temporales * * @param interval * @return */ public double estimateIntervalSupport(double[] interval) { int initialPosition = this.datasetTemporalHistogram.getTemporalPosition(interval[0]); int lastPosition = this.datasetTemporalHistogram.getTemporalPosition(interval[1]); double transactionsSum = 0.0; for (int i = initialPosition; i <= lastPosition; i++) { transactionsSum += this.datasetTemporalHistogram.getTransactionsNumber(i); } initialPosition -= this.temporalHistogramPosition; lastPosition -= this.temporalHistogramPosition; double countSum = 0.0; for (int i = initialPosition; i <= lastPosition; i++) { countSum += ((Integer)this.temporalHistogram.elementAt(i)).doubleValue(); } return (countSum/transactionsSum); } /** * Devuelve el soporte temporal de un itemset en milisegundos (absoluto) * * @return */ public double temporalSupport() { if ( (this.lifespan == null) || (this.lifespan[0] < 0) ) return Double.NaN;

171

//no sumo 1 porque la diferencia es en milisegundos return (this.lifespan[1] - this.lifespan[0]); } /** * Retorna la interseccion del lifespan del itemset actual con el del itemset dado * * @param itemset * @return */ public double[] mergeLifespan(SpatioTemporalAprioriItemset itemset) { double[] compLifespan = itemset.getLifespan(); double[] newLifespan = new double[2]; if (compLifespan[0] > this.lifespan[0]) newLifespan[0] = compLifespan[0]; else newLifespan[0] = this.lifespan[0]; if (compLifespan[1] < this.lifespan[1]) newLifespan[1] = compLifespan[1]; else newLifespan[1] = this.lifespan[1]; return newLifespan; } /** * Devuelve el soporte temporal de un itemset de acuerdo a su lifespan necesario, * en milisegundos (absoluto) * * @return */ public double neededLifespanTemporalSupport() { if ( (this.neededLifespan == null) || (this.neededLifespan[0] < 0) ) return Double.NaN; //no sumo 1 porque la diferencia es en milisegundos return (this.neededLifespan[1] - this.neededLifespan[0]); } /** * Indica si el itemset tiene subintervalos maximales frecuentes * (lifespan frecuente) * * @return */ public boolean haveFrequentLifespan() { if ( (this.frequentLifespan == null) || ( (this.frequentLifespan != null) && (this.frequentLifespan.size() == 0) ) ) return false; else return true; } /** * Indica si el itemset tiene el mismo item principal con el itemset dado * (Sup. el itemset principal se encuentra seteado) * * @param comp * @return */ public boolean samePrincipalItem(SpatioTemporalAprioriItemset comp) {

172

int[] compItem = comp.m_items; if ( this.m_items.length != compItem.length) return false; for (int i = 0; i < this.m_items.length; i++) { if ( this.m_items[i] != compItem[i]) return false; } return true; } /** * Indica si el itemset tiene los mismos items relacionados, respecto * al item principal, que el itemset dado * * @param comp * @return */ public boolean sameRelatedItems(SpatioTemporalAprioriItemset comp) { FastVector[] compRelatedItems = comp.itemsRelated; if ( ( (this.itemsRelated == null) && (compRelatedItems != null) ) || ( (this.itemsRelated != null) && (compRelatedItems == null) ) ) return false; if (this.itemsRelated == null) //los dos son null return true; if (this.itemsRelated.length != compRelatedItems.length) return false; for (int i = 0; i < this.itemsRelated.length; i++) { //semi-pache: para verificaciones de subitemsets -> elimino elementos pero no seteo los vectores en null // .: si tamaño = 0 => casi lo mismo que sea null (en esencia no existen items relacionados para ese atributo) if ( ( (this.itemsRelated[i] == null) && (compRelatedItems[i] != null && compRelatedItems[i].size() > 0) ) || ( (this.itemsRelated[i] != null && this.itemsRelated[i].size() == 0) && (compRelatedItems[i] != null && compRelatedItems[i].size() > 0) ) ) return false; if ( ( (compRelatedItems[i] == null) && (this.itemsRelated[i] != null && this.itemsRelated[i].size() > 0) ) || ( (compRelatedItems[i] != null && compRelatedItems[i].size() == 0) && (this.itemsRelated[i] != null && this.itemsRelated[i].size() > 0) ) ) return false; if ( (this.itemsRelated[i] != null) && (this.itemsRelated[i].size() > 0) ) { if ( this.itemsRelated[i].size() != compRelatedItems[i].size()) return false; for (int j = 0; j < this.itemsRelated[i].size(); j++) { if (!((Integer)this.itemsRelated[i].elementAt(j)).equals(compRelatedItems[i].elementAt(j))) return false; } } } return true; } /** * Indica si el itemset tiene los mismos predicados de relacion (PredS) que el itemset dado *

173

* @param comp * @return */ public boolean samePredS(SpatioTemporalAprioriItemset comp) { FastVector[] compPredS = comp.predS; if ( ( (this.predS == null) && (compPredS != null) ) || ( (this.predS != null) && (compPredS == null) ) ) return false; if (this.predS == null) //los dos son null return true; if (this.predS.length != compPredS.length) return false; for (int i = 0; i < this.predS.length; i++) { //semi-pache: para verificaciones de subitemsets -> elimino elementos pero no seteo los vectores en null // .: si tamaño = 0 => casi lo mismo que sea null (en esencia no existen items relacionados para ese atributo) // (se llama desde dentro la poda cuando se llama a kMinusOne.get(itemset), que termina llamamando al equals() if ( ( (this.predS[i] == null) && (compPredS[i] != null && compPredS[i].size() > 0) ) || ( (this.predS[i] != null && this.predS[i].size() == 0) && (compPredS[i] != null && compPredS[i].size() > 0) ) ) return false; if ( ( (compPredS[i] == null) && (this.predS[i] != null && this.predS[i].size() > 0) ) || ( (compPredS[i] != null && compPredS[i].size() == 0) && (this.predS[i] != null && this.predS[i].size() > 0) ) ) return false; if ( (this.predS[i] != null) && (this.predS[i].size() > 0) ) { if ( this.predS[i].size() != compPredS[i].size()) return false; for (int j = 0; j < this.predS[i].size(); j++) { if (!((Integer)this.predS[i].elementAt(j)).equals(compPredS[i].elementAt(j))) return false; } } } return true; } /* (non-Javadoc) * @see weka.associations.ItemSet#equals(java.lang.Object) */ @Override public boolean equals(Object itemSet) { if (itemSet == null) return false; if (!(itemSet instanceof SpatioTemporalAprioriItemset )) return super.equals(itemSet); if (!this.samePrincipalItem((SpatioTemporalAprioriItemset)itemSet)) return false; if (!this.sameRelatedItems((SpatioTemporalAprioriItemset)itemSet)) return false; if (!this.samePredS((SpatioTemporalAprioriItemset)itemSet)) return false; return true; }

174

/** * Indica si el itemset no se encuentra contenido dentro del conjunto de itemsets dado * Verifica la no contencion en base a los items del itemsets solamente * * @param itemsetSet * @return */ public boolean notContained(Hashtable itemsetSet) { //no frecuente: no existe algun itemset (k-1) con solo los items del mismo Enumeration itemsetsEnumeration = itemsetSet.keys(); SpatioTemporalAprioriItemset itemset; while (itemsetsEnumeration.hasMoreElements()) { itemset = (SpatioTemporalAprioriItemset)itemsetsEnumeration.nextElement(); if ( (this.samePrincipalItem(itemset)) && (this.sameRelatedItems(itemset))) { return false; } } return true; } /** * Devuelve la resta del itemset actual con el dado * * @param operator2 itemset de tipo consecuente * (sin itemset principal, ni contadores) contenido en el itemset actual * @return itemset resultante de la resta, sin contadores seteados */ public SpatioTemporalAprioriItemset substract(SpatioTemporalAprioriItemset operator2) { SpatioTemporalAprioriItemset sustracted = new SpatioTemporalAprioriItemset(this.m_totalTransactions, 1,this.predicateSet,this.datasetTemporalHistogram); sustracted.m_items = this.m_items.clone(); sustracted.itemsRelated = new FastVector[this.itemsRelated.length]; sustracted.predS = new FastVector[this.predS.length]; FastVector itemsRelated; boolean relatedNotSustracted = false; int pos = -1; for (int i = 0; i < this.itemsRelated.length; i++) { itemsRelated = this.itemsRelated[i]; if (itemsRelated != null) { for (int j = 0; j < itemsRelated.size(); j++) { if ( operator2.itemsRelated[i] != null ) pos = operator2.itemsRelated[i].indexOf(itemsRelated.elementAt(j)); //la combinacion de att=valor (predicado) siempre es unica dentro de un STItemset if ( (operator2.itemsRelated[i] == null) || (pos == -1) || ( (!((Integer)this.predS[i].elementAt(j)).equals(operator2.predS[i].elementAt(pos))) ) )

175

{ if (sustracted.itemsRelated[i] == null) sustracted.itemsRelated[i] = new FastVector(); if (sustracted.predS[i] == null) sustracted.predS[i] = new FastVector(); sustracted.itemsRelated[i].addElement(itemsRelated.elementAt(j)); sustracted.predS[i].addElement(this.predS[i].elementAt(j)); relatedNotSustracted = true; } } } } if (!relatedNotSustracted) { sustracted.itemsRelated = null; sustracted.predS = null; } return sustracted; } /** * Genera todas las reglas para un itemset con el nivel de confianza dado * * @param size tamaño del itemset sobre el cual generar las reglas * @param hashTables conjuntos de itemsets espacio-temporales frecuentes descubiertos * @param minConfidence umbral de confianza * @return */ public FastVector generateRules(int size, FastVector hashTables, double minConfidence) throws Exception { Hashtable premises = (Hashtable)hashTables.elementAt(size - 2); //empieza desde cero y tengo un itemset menos FastVector relatedItems; FastVector rules = new FastVector(); FastVector consequences = new FastVector(); //auxiliar para reglas posteriores SpatioTemporalAprioriItemset consequence; SpatioTemporalAssociationRule rule; for (int i = 0; i < this.itemsRelated.length; i++) { relatedItems = this.itemsRelated[i]; if (relatedItems != null) { for (int j = 0; j < relatedItems.size(); j++) { consequence = new SpatioTemporalAprioriItemset(this.m_totalTransactions, this.m_items.length, this.predicateSet, this.datasetTemporalHistogram); consequence.itemsRelated = new FastVector[this.getNumberAttributes()]; consequence.itemsRelated[i] = new FastVector(); consequence.itemsRelated[i].addElement(relatedItems.elementAt(j)); consequence.predS = new FastVector[this.getNumberAttributes()]; consequence.predS[i] = new FastVector(); consequence.predS[i].addElement(this.predS[i].elementAt(j)); consequence.lifespan = new double[] {NULL_TEMP, NULL_TEMP}; rule = new SpatioTemporalAssociationRule(this, consequence, premises); if (!(rule.pruneByConfidence(minConfidence))) { rules.addElement(rule); consequences.addElement(consequence);

176

} } } } rules.appendElements(SpatioTemporalAssociationRule.generateNotUnaryConsequenceRules(1, consequences, this, size, hashTables, minConfidence)); return rules; } //////////metodos de clase/////////// //forman parte de los algoritmos para el descubrimiento de los itemsets frecuentes //y las reglas de asociacion espacio-temporales /** * Genera el conjunto de itemsets candidatos espacio-temporales de tamaño 1. * El conjunto de items posibles ( I ) se obtiene en base * a la informacion del header de Instances * * @param instances * @param predicateSet conjunto de predicados para instanciar los SpatioTemporalAprioriItemsets * @param datasetTemporalHistogram histograma temporal del algoritmo (se actualiza si es necesario) * @return * @throws Exception */ public static FastVector singletons(Instances instances, PredicateSet predicateSet, TemporalHistogram datasetTemporalHistogram) throws Exception { FastVector candidates1 = new FastVector(); //c pertence a C1 => c={i}, para todo i perteneciente a I // PredSc = {} //Se supone el atributo 1 son los datos espaciales para un t Instances spatialInstances = instances.attribute(1).relation(); SpatioTemporalAprioriItemset itemset; //los primeros atributos son los componentes de la posicion for (int i = MAX_GEOGRAPHIC_DIM; i < spatialInstances.numAttributes(); i++) { for (int j = 0; j < spatialInstances.attribute(i).numValues(); j++) { itemset = new SpatioTemporalAprioriItemset(instances.numInstances(), spatialInstances.numAttributes() - MAX_GEOGRAPHIC_DIM, i - MAX_GEOGRAPHIC_DIM,j, predicateSet, datasetTemporalHistogram); candidates1.addElement(itemset); } } return candidates1; } /** * Actualiza los contadores de los itemsets para un conjuntos de instancias * * @param itemSets conjunto de itemsets a ser actualizados * @param instances instancias utilizadas para actualizar los contadores */ public static void upDateCounters(FastVector itemSets, Instances instances) {

177

SpatioTemporalAprioriItemset.upDateCounters(itemSets, instances, null); } /** * Actualiza los contadores de los itemsets para un conjuntos de instancias * Tambien actualiza el histograma temporal del algoritmo, si es necesario * * @param itemSets conjunto de itemsets a ser actualizados * @param instances instancias utilizadas para actualizar los contadores * @param temporalHistogram histograma temporal del algoritmo (se actualiza si es necesario) */ public static void upDateCounters(FastVector itemSets, Instances instances, TemporalHistogram temporalHistogram) { boolean updateHistogram = true; if (temporalHistogram == null) updateHistogram = false; else if (temporalHistogram.updated()) updateHistogram = false; Instance instance; if (itemSets.size() > 0) for (int i = 0; i < instances.numInstances(); i++) { Enumeration enu = itemSets.elements(); instance = instances.instance(i); while (enu.hasMoreElements()) ((SpatioTemporalAprioriItemset)enu.nextElement()).upDateCounter(instance); if (updateHistogram) temporalHistogram.incrementTransactionsNumber(temporalHistogram.getTemporalPosition(instance.value(0))); } } /** * Se devuelve una estructura que permita acceder a los items de manera mas directa que * el recorrido secuencial. Actualmente es una tabla de los itemsets hasheada por los * mismos como clave * * @param itemSets conjunto de itemsets para completar la estructura * @param initialSize tamaño inicial de la misma * @return estructura generada (Hashtable) */ public static Hashtable getHashtable(FastVector itemSets, int initialSize) { Hashtable hashtable = new Hashtable(initialSize); for (int i = 0; i < itemSets.size(); i++) { ItemSet current = (ItemSet)itemSets.elementAt(i); hashtable.put(current, current); } return hashtable; } /** * Obtiene del conjunto de itemsets candidatos los frecuentes * * @param candidates itemsets candidatos contabilizados * @param minSupport umbral de soporte (sigma)

178

* @param minTemporalSupport umbral de soporte temporal (thau) * @return */ public static FastVector verifyFrecuentItemSet(FastVector candidates, double minSupport, double minTemporalSupport) { FastVector frecuents = new FastVector(candidates.size()); SpatioTemporalAprioriItemset candidate; for (int i = 0; i < candidates.size(); i++) { candidate = (SpatioTemporalAprioriItemset)candidates.elementAt(i); if (candidate.temporalSupport() >= minTemporalSupport) { if (candidate.lifespanSupport() >= minSupport) { frecuents.addElement(candidate); } else { candidate.discoverFrequentLifespan(minSupport, minTemporalSupport); if (candidate.haveFrequentLifespan()) frecuents.addElement(candidate); } } //si el lifespan no pasa el umbral de soporte temporal, //los subintervalos dentro del mismo tampoco lo van a pasar //(quedan fuera de las condiciones de evaluacion) } return frecuents; } /** * Genera candidatos a partir de 1-itemsets frecuentes * (funcion stapriori-gen_Initial: paso de junta + paso de poda * (temporal y segun posiciones geograficas)) * * @param itemSets conjunto de itemset frecuentes de tamaño 1 - L1 * @param minTemporalSupport umbral de soporte temporal * @return */ protected static FastVector mergeAllOneItemSets(FastVector itemSets, double minTemporalSupport) throws Exception { FastVector candidates = new FastVector(); SpatioTemporalAprioriItemset candidate = null; int k; FastVector[] itemsRelated; for (int i = 0; i < itemSets.size(); i++) { SpatioTemporalAprioriItemset first = (SpatioTemporalAprioriItemset)itemSets.elementAt(i); for (int j = i+1; j < itemSets.size(); j++) { SpatioTemporalAprioriItemset second = (SpatioTemporalAprioriItemset)itemSets.elementAt(j); itemsRelated = new FastVector[first.getNumberAttributes()]; k=0; while (k < first.m_items.length) {

179

//solo copio el valor del segundo item, si existe (no crear posiciones vacias) // para que quede como item relacionado //el primero se toma del primer item itemset, al final al armar el candidato //obs.: relaciono tomo los items, ya que por el orden dado al conjunto (y //la manera en que se genero) second va a ser siempre menor a first if (second.m_items[k] != -1) { //guardo como item a relacionar itemsRelated[k] = new FastVector(); itemsRelated[k].addElement(new Integer(second.m_items[k])); break; } k++; } //poda temporal con el par formado double[] neededLifespan = first.mergeLifespan(second); //no sumo 1 porque la diferencia es en milisegundos double neededLifespanTemporalSupport = neededLifespan[1] - neededLifespan[0]; if (neededLifespanTemporalSupport >= minTemporalSupport) { //veo las posiciones de cada items para determinar P' FastVector pointPairs = new FastVector(); PointPair pointPair; for (int indexF = 0; indexF < first.positions.size(); indexF++) { for (int indexS = 0; indexS < second.positions.size(); indexS++) { if ( !(first.positions.elementAt(indexF). equals(second.positions.elementAt(indexS))) ) { pointPair = new PointPair((Point)first.positions.elementAt(indexF), (Point)second.positions.elementAt(indexS)); if (!pointPairs.contains(pointPair)) { pointPairs.addElement(pointPair); } } } } FastVector pPrime = new FastVector(); //predicados para candidatos k=2 int newPredicateIndex; for (int p = 0; p < pointPairs.size(); p++) { pointPair = (PointPair) pointPairs.elementAt(p); newPredicateIndex = first.predicateSet.calculatePredicate(pointPair.getPoint1(), pointPair.getPoint2()); if (!pPrime.contains(newPredicateIndex)) pPrime.addElement(newPredicateIndex); } //se ordena pPrime según predicateSet Object[] sortedpPrime = pPrime.toArray(); Arrays.sort(sortedpPrime); //para cada elemento de pPrime ordenado armar candidato y agregar for (int index = 0; index < sortedpPrime.length; index++)

180

{ Integer predicateIndex = (Integer) sortedpPrime[index]; candidate = new SpatioTemporalAprioriItemset(first.m_totalTransactions, first.getNumberAttributes(), first.predicateSet, first.datasetTemporalHistogram); candidate.m_items = first.m_items.clone(); //OJO con la duplicacion de referencias candidate.itemsRelated = new FastVector[itemsRelated.length]; for (int c = 0; c < itemsRelated.length; c++) { if (itemsRelated[c] != null) candidate.itemsRelated[c] = (FastVector)itemsRelated[c].copy(); } candidate.predS = new FastVector[first.getNumberAttributes()]; candidate.predS[k] = new FastVector(); candidate.predS[k].addElement(new Integer(predicateIndex)); candidate.neededLifespan = neededLifespan; candidates.addElement(candidate); } } } } return candidates; } /** * Genera candidatos a partir de itemsets frecuentes de tamaño k >= 2 * (Paso de Junta de stapriori-gen_High) * * @param itemSets conjunto de itemsets frecuentes * @param size tamaño de correspondiente a estos itemsets (k-1) - empezando desde 1 * @return */ protected static FastVector mergeAllKItemSets(FastVector itemSets, int size) { FastVector candidates = new FastVector(); SpatioTemporalAprioriItemset candidate = null; int k, numFound,r; for (int i = 0; i < itemSets.size(); i++) { SpatioTemporalAprioriItemset first = (SpatioTemporalAprioriItemset)itemSets.elementAt(i); out: for (int j = i+1; j < itemSets.size(); j++) { SpatioTemporalAprioriItemset second = (SpatioTemporalAprioriItemset)itemSets.elementAt(j); if (!(first.samePrincipalItem(second))) { break; } else { r=-1; candidate = new SpatioTemporalAprioriItemset(first.m_totalTransactions, 1, first.predicateSet, first.datasetTemporalHistogram); //seteo m_items igual, e inicializo related y PredS candidate.m_items = first.m_items.clone(); candidate.itemsRelated = new FastVector[first.m_items.length];

181

candidate.predS = new FastVector[first.m_items.length]; //busco 'size' elementos en itemsRelated y PredS en comun //entre los itemsets frecuentes que formaran al candidato //y los copio a este ultimo numFound = 1; k = 0; //uno menos porque el primer item ya es igual found: while (numFound < (size - 1)) { //cond corte: tener null, tamaño distinto if ( (first.itemsRelated[k] == null) && (second.itemsRelated[k] == null)) { k++; } else { if ( ( (first.itemsRelated[k] != null ) && (second.itemsRelated[k] == null) ) || ( (first.itemsRelated[k] == null ) && (second.itemsRelated[k] != null) )) //el segundo caso en realidad no ocurriria nunca { break out; } else { //si quedan por encontrar n y long de primero > n => la de segundo minimo n //sino si long. de primero <=n => la de segundo debe ser igual if (first.itemsRelated[k].size() > (size - numFound - 1)) { if ( second.itemsRelated[k].size() < (size - numFound - 1) ) break out; } else { if ( first.itemsRelated[k].size() != second.itemsRelated[k].size() ) { break out; } } //si son iguales los elementos ve van a ubicar en la misma //posicion porque todos fueron armados ordenadamente de la misma manera for (r = 0; r < first.itemsRelated[k].size(); r++) { if ( ( ((Integer)first.itemsRelated[k].elementAt(r)).equals((Integer)second.itemsRelated[k].elementAt(r)) ) && ( ((Integer)first.predS[k].elementAt(r)).equals((Integer)second.predS[k].elementAt(r)) ) ) { if (candidate.itemsRelated[k] == null) candidate.itemsRelated[k] = new FastVector(); if (candidate.predS[k] == null) candidate.predS[k] = new FastVector();

182

//en este caso no hay problema referencias duplicadas con los elementos de itemsRelated y predS ya //que son de tipo Integer, de esta manera son valores que no se modifican candidate.itemsRelated[k].addElement(first.itemsRelated[k].elementAt(r)); candidate.predS[k].addElement(first.predS[k].elementAt(r)); numFound++; if (numFound == (size -1)) { r++; break found; } } else break out; } k++; } } } //El siguiente atributo // puede tener valor -> distinto: la condicion de menor se da por el orden de los itemsets // |-> igual: deberia ser predicado distinto //No tengo los predicados en orden debido a que no tengo definidos todos; //igualmente esta condicion no es necesaria ser verificada: // -generacion en k=2 asegura que los elementos del par son distintos // -en la generacion de k > 2 los elementos se encuentran ordenados y sin elementos repetidos // ya que los candidatos conteniendo los mismos fueron eliminados en algun paso de poda //asigno los siguientes elementos en el mismo atributo if (r >= 0) { while (r < first.itemsRelated[k].size()) { candidate.itemsRelated[k].addElement(first.itemsRelated[k].elementAt(r)); candidate.predS[k].addElement(first.predS[k].elementAt(r)); if (second.itemsRelated[k].size() > r) { candidate.itemsRelated[k].addElement(second.itemsRelated[k].elementAt(r)); candidate.predS[k].addElement(second.predS[k].elementAt(r)); } r++; } k++; } while (k < first.itemsRelated.length) { if (first.itemsRelated[k] != null) { candidate.itemsRelated[k] = (FastVector)first.itemsRelated[k].copy(); candidate.predS[k] = (FastVector)first.predS[k].copy(); //otros valores para el mismo atributo //o el mismo valor con distinto predicado -> no va a ser frecuente nunca porque en k=2 no lo

183

// permito (directamente no son generados) => no va a existir subconjunto frecuente if (second.itemsRelated[k] != null) { for (int indexS = 0; indexS < second.itemsRelated[k].size(); indexS++) { candidate.itemsRelated[k].addElement(second.itemsRelated[k].elementAt(indexS)); candidate.predS[k].addElement(second.predS[k].elementAt(indexS)); } } } else { if (second.itemsRelated[k] != null) { candidate.itemsRelated[k] = (FastVector)second.itemsRelated[k].copy(); candidate.predS[k] = (FastVector)second.predS[k].copy(); } } k++; } if (k == first.itemsRelated.length) { candidate.m_counter = 0; candidate.neededLifespan = first.mergeLifespan(second); candidates.addElement(candidate); } } } } return candidates; } /** * Genera candidatos de tamaño k a partir de itemsets * frecuentes de tamaño k-1 * * @param itemSets conjunto de (k-1)-itemsets frecuentes * @param size valor de (k-1) - empezando desde 1 * @param minTemporalSupport umbral de soporte temporal * //se utiliza solo para k=1 (paso de junta + poda en uno ) * @return conjunto de k-itemsets candidatos generados */ //se mantiene el metodo para simplificar la llamada dentro del ciclo de //descubrimiento de itemsets public static FastVector mergeAllItemSets(FastVector itemSets, int size, double minTemporalSupport) throws Exception { if (size == 1) { return SpatioTemporalAprioriItemset.mergeAllOneItemSets(itemSets, minTemporalSupport); } else { return SpatioTemporalAprioriItemset.mergeAllKItemSets(itemSets, size); } } /**

184

* Realiza la poda del conjunto de k-itemsets candidatos * (Paso de Poda de stapriori-gen_High) * * @param toPrune conjunto de k-itemsets candidatos a ser podados * @param kMinusOne conjunto de (k-1)-itemsets frecuentes, utilizados para la poda * @param minTemporalSupport umbral de soporte temporal * @return conjunto de k-itemsets candidatos podado */ public static FastVector pruneItemSets(FastVector toPrune, Hashtable kMinusOne, double minTemporalSupport) { FastVector notPruned = new FastVector(toPrune.size()); SpatioTemporalAprioriItemset itemset, subItemset;; FastVector attItems; Integer auxItem, auxPredicate; int j; boolean prune = false; for (int i = 0; i < toPrune.size(); i++) { itemset = (SpatioTemporalAprioriItemset)toPrune.elementAt(i); if (itemset.neededLifespanTemporalSupport() >= minTemporalSupport) { prune = false; itItemSet: for (j = 0; j < itemset.itemsRelated.length; j++) { //verifico poda de cada subitem que incluya al item principal attItems = itemset.itemsRelated[j]; if (attItems != null) { for (int k = 0; k < attItems.size(); k++) { auxItem = (Integer)attItems.elementAt(k); attItems.removeElementAt(k); auxPredicate = (Integer)itemset.predS[j].elementAt(k); itemset.predS[j].removeElementAt(k); if (kMinusOne.get(itemset) == null) { attItems.insertElementAt(auxItem, k); itemset.predS[j].insertElementAt(auxPredicate, k); prune = true; break itItemSet; } else { attItems.insertElementAt(auxItem, k); itemset.predS[j].insertElementAt(auxPredicate, k); } } } } if (!prune) { //verifico poda de subitem sin el item principal attItems = null; for (j = 0; j < itemset.itemsRelated.length; j++) { attItems = itemset.itemsRelated[j]; if (attItems != null) break; } auxItem = (Integer)attItems.elementAt(0); subItemset = new SpatioTemporalAprioriItemset(itemset.m_totalTransactions, itemset.m_items.length, j, auxItem.intValue(), itemset.predicateSet, itemset.datasetTemporalHistogram);


185

attItems.removeElementAt(0); subItemset.itemsRelated = itemset.itemsRelated; if (subItemset.notContained(kMinusOne)) { attItems.insertElementAt(auxItem, 0); //el itemset se puede podar (== no forma parte de los "no podados") } else { attItems.insertElementAt(auxItem, 0); notPruned.addElement(itemset); } } } } return notPruned; } } /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.associations.spatiotemporal; import java.util.Hashtable; import weka.core.FastVector; import weka.core.Instances; import weka.core.Utils; /** * Representa la regla de asociacion espacio-temporal * Se utiliza dentro del algoritmo de la clase SpatioTemporalApriori, utilizado para el * descubrimiento de las reglas de asociacion espacio-temporales. * * @author Mariano Kohan ([email protected]) * */ public class SpatioTemporalAssociationRule { public enum PremiseSupportEstimation {UNIFORM_TEMPORAL_DISTRIBUTION, HISTOGRAM } /** Itemset espacio-temporal sobre el cual se genera la regla */ protected SpatioTemporalAprioriItemset unionItemset; /** Iemset espacio-temporal correspondiente a la premisa de la regla */ protected SpatioTemporalAprioriItemset premise; /** Itemset espacio-temporal correspondiente al consecuente de la regla */

186

//es un itemset incompleto: no tiene item pcpal., ni variables de contabilizacion //ya que fue generado a partir del unionItemset y premise protected SpatioTemporalAprioriItemset consequence; /** Soporte de la regla en cada uno de sus intervalos frecuentes */ //inicialmente = al soporte del itemset union, pero pueden eliminarse elementos al //podar según confianza - metodo pruneByConfidence(double minConfidence) protected FastVector support; /** Intervalos frecuentes de la regla */ //igual al lifespan o lifespan frecuente del itemset union, inicialmente //Pueden eliminarse elementos al podar segun // confianza - metodo pruneByConfidence(double minConfidence) protected FastVector frequentIntervals; /** Indica como se realiza la estimacion del soporte de la premisa */ protected PremiseSupportEstimation premiseSupportEstimation;; /** * Constructor de la regla * * @param unionItemset * @param consequence * @param premises */ public SpatioTemporalAssociationRule(SpatioTemporalAprioriItemset unionItemset, SpatioTemporalAprioriItemset consequence, Hashtable premises) { this.unionItemset = unionItemset; this.consequence = consequence; this.premise = (SpatioTemporalAprioriItemset)premises.get(unionItemset.substract(consequence)); this.setFrequentIntervalsAndSupport(); } /** * Setea los valores iniciales de los intervalos frecuentes y soporte de la regla */ private void setFrequentIntervalsAndSupport() { FastVector support; FastVector frecuentIntervals; if (this.unionItemset.haveFrequentLifespan()) { support = new FastVector(this.unionItemset.frequentLifespanSupport.size()); frecuentIntervals = new FastVector(this.unionItemset.frequentLifespan.size()); for (int i = 0; i < this.unionItemset.frequentLifespanSupport.size(); i++) { support.addElement((Double)this.unionItemset.frequentLifespanSupport.elementAt(i)); frecuentIntervals.addElement(((double[])this.unionItemset.frequentLifespan.elementAt(i)).clone()); } this.premiseSupportEstimation = PremiseSupportEstimation.HISTOGRAM; } else { support = new FastVector(1);

187

support.addElement(this.unionItemset.lifespanSupport()); frecuentIntervals = new FastVector(1); frecuentIntervals.addElement(this.unionItemset.lifespan.clone()); this.premiseSupportEstimation = PremiseSupportEstimation.UNIFORM_TEMPORAL_DISTRIBUTION; } this.frequentIntervals = frecuentIntervals; this.support = support; } /** * Retorna el soporte de la regla * {sup(XUY,[t,t']) / [t,t'] pertence a intervalos frecuentes de la regla} * * @return */ public FastVector getSupport() { return this.support; } /** * Retorna el valor de confianza de la regla * {conf(XUY,[t,t']) / [t,t'] pertence intervalos frecuentes de la regla)} * calculo de confianza es segun intervalo frecuente del itemset que conforma la regla: * - si el itemset de la regla es frecuente en su lifespan: estimacion del soporte de la * premisa en el lifespan de la regla suponiendo distribucion temporal uniforme, segun * intervalo frecuente de la premisa: * -lifespan: = el soporte en el lifespan de la misma (sup. distribucion temporal uniforme * dentro del lifespan) * -subintervalos maximales frecuentes: al menos un intervalo va a solapar por modelo (pdad. * Apriori) => = soporte en ese intervalo que solapa al lifespan del itemset que * conforma la regla (sup. distribucion temporal uniforme aproximada en entorno * subintervalo, por restricciones de armado del histograma temporal) * - si el itemset de la regla es frecuente en subintervalos maximales: estimacion del soporte de * la premisa usando el histograma temporal de la misma * * @return */ public double[] confidence() { if (this.premise == null) return new double[] {-1.0}; FastVector support = this.getSupport(); double[] confidence = new double[support.size()]; double premiseSupport = 0; FastVector frequentIntervals = this.getFrequentIntervals(); if (this.premiseSupportEstimation == PremiseSupportEstimation.UNIFORM_TEMPORAL_DISTRIBUTION) { for (int i = 0; i < support.size(); i++) { if (this.premise.haveFrequentLifespan()) { double[] interval = null; double[] ruleLifespan = (double[])frequentIntervals.elementAt(0); int j;

188

boolean solapedIntervalExists = false; for (j = 0; j < this.premise.frequentLifespan.size(); j++) { interval = (double[])this.premise.frequentLifespan.elementAt(j); if ( ( (interval[0] <= ruleLifespan[0]) && (ruleLifespan[0]< interval[1]) ) || ( (interval[0] < ruleLifespan[1]) && (ruleLifespan[1] <= interval[1]) ) || ( (ruleLifespan[0] < interval[0]) && (interval[0] < ruleLifespan[1]) ) ) { solapedIntervalExists = true; break; } } //por modelo no deberia no hallarse un intervalo que no solape => tiro excepcion //para registrar el caso if (!solapedIntervalExists) throw new RuntimeException("Premise without estimable frequent subinterval!"); premiseSupport = ((Double)this.premise.frequentLifespanSupport.elementAt(j)).doubleValue(); } else { premiseSupport = this.premise.lifespanSupport(); } confidence[i] = ((Double)support.elementAt(i)).doubleValue()/premiseSupport; } } else { for (int i = 0; i < support.size(); i++) { premiseSupport = this.premise.estimateIntervalSupport((double[])frequentIntervals.elementAt(i)); confidence[i] = ((Double)support.elementAt(i)).doubleValue()/premiseSupport; } } return confidence; } /** * Devuelve los intervalos frecuentes de la regla (lifespan o lifespan frecuente) * * @return */ public FastVector getFrequentIntervals() { return this.frequentIntervals; } /** * Devuelve un string con la representacion de los intervalos frecuentes de la regla * * @return */ public String getFrequentIntervalsString() { FastVector frecuentIntervals = this.getFrequentIntervals(); StringBuffer text = new StringBuffer();

189

double[] interval; text.append("{ "); for (int i = 0; i < frecuentIntervals.size(); i++) { interval = (double[])frecuentIntervals.elementAt(i); text.append("["); text.append(new java.util.Date((new Double(interval[0])).longValue())); text.append("; "); text.append(new java.util.Date((new Double(interval[1])).longValue())); text.append("], "); } text.delete(text.lastIndexOf(", "), text.length()); text.append(" }"); return text.toString(); } /** * Devuelve una representacion en string del soporte de la regla * * @return */ public String supportString() { FastVector support = this.getSupport(); StringBuffer text = new StringBuffer(); text.append("{ "); for (int i = 0; i < support.size(); i++) { text.append(Utils.doubleToString(((Double)support.elementAt(i)).doubleValue(),4)).append(", "); } text.delete(text.lastIndexOf(", "), text.length()); text.append(" }"); return text.toString(); } /** * Devuelve una representacion en string de la confianza de la regla * * @return */ public String confidenceString() { double[] confidence = this.confidence(); StringBuffer text = new StringBuffer(); text.append("{ "); for (int i = 0; i < confidence.length; i++) { text.append(Utils.doubleToString(confidence[i],4)).append(", "); } text.delete(text.lastIndexOf(", "), text.length()); text.append(" }"); return text.toString(); } /* (non-Javadoc) * @see java.lang.Object#toString() */ @Override public String toString() { //caso debug: valores internos StringBuffer rule = new StringBuffer(); rule.append(this.unionItemset); rule.append("\t").append(this.premise).append("\t ||==> ").append(this.consequence);

190

rule.append("\\--{"); if (this.frequentIntervals.size() > 0) { double[] interval; for (int i = 0; i < this.frequentIntervals.size(); i++) { interval = (double[])this.frequentIntervals.elementAt(i); rule.append("["+new java.util.Date((new Double(interval[0])).longValue())+"; ") .append(new java.util.Date((new Double(interval[1])).longValue()) +"] , "); } rule.delete(rule.lastIndexOf(", "), rule.length()-1); rule.append("}\n"); rule.append("\\--{"); for (int i = 0; i < this.support.size(); i++) { rule.append(((Double)this.support.elementAt(i)).toString() + ", "); } rule.delete(rule.lastIndexOf(", "), rule.length()-1); } rule.append("}\n"); return rule.toString(); } /** * Devuelve una representacion textual de la regla para ser mostrada al usuario * * @param instances instancias sobre las se va a representar la regla * (tienen informacion sobre los valores de discretizacion de los atributos de * los itemsets que la conforman) * @return */ public String toString(Instances instances) { StringBuffer text = new StringBuffer(); text.append(this.premise.itemsToString(instances)); text.append(" ===> "); text.append(this.consequence.itemsToString(instances, this.premise.getNumerRelatedItems()+2)); text.append("\n\t"); text.append("[ "); text.append("{ "); if (!this.premise.isOneItemSet()) { //muestro PredS de la premisa cuando no es vacio text.append(this.premise.getPredSString()+", "); } text.append(this.consequence.getPredSString(this.premise.getNumerRelatedItems()+2)+" }"); text.append("; "); text.append(this.getFrequentIntervalsString()); text.append(" ] \n\t"); text.append("[ ").append(this.supportString()); text.append("; ").append(this.confidenceString()).append(" ] \n\t"); return text.toString(); } /** * Poda intervalos frecuente de la regla segun el umbral de confianza dado * * @param minConfidence umbral confianza * @return si la regla es podada o no (no quedan intervalos sin podar) */ public boolean pruneByConfidence(double minConfidence) { double[] confidence = this.confidence();

191

boolean prune = false; FastVector prunedElements = new FastVector(confidence.length); for (int i = (confidence.length - 1); i >= 0; i--) { if (confidence[i] < minConfidence) { prune = true; prunedElements.addElement(new Integer(i)); } } if (prune) { int pos; for (int j = 0; j < prunedElements.size(); j++) { pos = (Integer)prunedElements.elementAt(j); this.frequentIntervals.removeElementAt(pos); this.support.removeElementAt(pos); } if (this.frequentIntervals.size() > 0) prune = false; } return prune; } //////////metodo de clase/////////// //forma parte del algoritmo para el descubrimiento de las reglas de asociacion espacio-temporales /** * Genera las reglas de consecuente con tamaño mayor a uno, según el umbral de confianza dado * * @param consequentSize tamaño de los consecuente sobre los cuales generar las reglas * @param consequences consecuentes de tamaño consequentSize de las reglas ya generadas * @param itemset sobre el cual generar las reglas * @param size tamaño del itemset sobre el cual generar las reglas * @param hashTables conjuntos de itemsets espacio-temporales frecuentes descubiertos * @param minConfidence umbral confianza (para la poda de las reglas) * @return */ public static FastVector generateNotUnaryConsequenceRules(int consequentSize, FastVector consequences, SpatioTemporalAprioriItemset itemset, int size, FastVector hashTables, double minConfidence) throws Exception { FastVector rules = new FastVector(); if ( (consequences.size() == 0) || (size <= consequentSize + 1) ) return rules; Hashtable premises = (Hashtable)hashTables.elementAt(size - consequentSize - 2); //empieza desde cero, tengo un itemset menos y el tamaño es el actual //llamo directamente al merge para k > 1, ya que no es necesario validar el soporte temporal // (y por lo tanto el valor del mismo no se encuentra disponible) FastVector newConsequences = SpatioTemporalAprioriItemset.mergeAllKItemSets(consequences, consequentSize+1); //se cuenta uno mas por el item principal FastVector consequencesNotPruned = new FastVector(); SpatioTemporalAprioriItemset consequence;

192

SpatioTemporalAssociationRule rule; for (int i = 0; i < newConsequences.size(); i++) { consequence = (SpatioTemporalAprioriItemset) newConsequences.elementAt(i); rule = new SpatioTemporalAssociationRule(itemset, consequence, premises); if (!(rule.pruneByConfidence(minConfidence))) { rules.addElement(rule); consequencesNotPruned.addElement(consequence); } } rules.appendElements(generateNotUnaryConsequenceRules(consequentSize + 1, consequencesNotPruned, itemset, size, hashTables, minConfidence)); return rules; } }

C.2. Paquete weka.associations.spatiotemporal.predicates

/* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.associations.spatiotemporal.predicates; /** * Representa un punto geografico generico * * @author Mariano Kohan ([email protected]) * */ public abstract class Point { //los elementos de un punto varian según el tipo del mismo } /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software


193

* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.associations.spatiotemporal.predicates; /** * Representa un punto en coordenadas geograficas * * @author Mariano Kohan ([email protected]) * */ public class GeographicPoint extends Point { /** longitud geografica del punto */ protected double longitude; /** latitud geografica del punto */ protected double latitude; /** * Constructor del punto geografico en base a sus componentes * * @param longitude * @param latitude */ public GeographicPoint(double longitude, double latitude) { this.longitude = longitude; this.latitude = latitude; } /** * Devuelve la latitud geografica del punto * * @return */ public double getLatitude() { return latitude; } /** * Setea la latitud geografica del punto * * @param latitude */ public void setLatitude(double latitude) { this.latitude = latitude; } /** * Devuelve la longitud geografica del punto * * @return */ public double getLongitude() { return longitude; } /** * Setea la longitud geografica del punto * * @param longitude */ public void setLongitude(double longitude) {


194

this.longitude = longitude; } /* (non-Javadoc) * @see java.lang.Object#equals(java.lang.Object) */ @Override public boolean equals(Object obj) { if (!(obj instanceof GeographicPoint)) return super.equals(obj); GeographicPoint comp = (GeographicPoint)obj; if ( (this.latitude == comp.latitude) && (this.longitude == comp.longitude) ) return true; else return false; } /* (non-Javadoc) * @see java.lang.Object#toString() */ @Override public String toString() { return ("("+this.longitude+"; "+this.latitude+")"); } } /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.associations.spatiotemporal.predicates; /** * Representa un punto en coordenadas proyectadas en el plano (x,y) * * @author Mariano Kohan ([email protected]) * */ public class ProjectedPoint extends Point { /** coordenada horizontal del punto en el plano */ protected double x; /** coordenada vertical del punto en el plano */ protected double y; /** * Constructor del punto proyectado en base a sus componentes * * @param x * @param y */


195

public ProjectedPoint(double x, double y) { this.x = x; this.y = y; } /** * Devuelve la coordenada horizontal del punto en el plano * * @return */ public double getX() { return x; } /** * Setea la coordenada horizontal del punto en el plano * * @param x */ public void setX(double x) { this.x = x; } /** * Devuelve la coordenada vertical del punto en el plano * * @return */ public double getY() { return y; } /** * Setea la coordenada vertical del punto en el plano * * @param y */ public void setY(double y) { this.y = y; } /* (non-Javadoc) * @see java.lang.Object#equals(java.lang.Object) */ @Override public boolean equals(Object obj) { if (!(obj instanceof ProjectedPoint)) return super.equals(obj); ProjectedPoint comp = (ProjectedPoint)obj; if ( (this.y == comp.y) && (this.x == comp.x) ) return true; else return false; } /* (non-Javadoc) * @see java.lang.Object#toString() */ @Override public String toString()


196

{ return ("("+this.x+"; "+this.y+")"); } } /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.associations.spatiotemporal.predicates; /** * Par de puntos * Mantiene el orden en los puntos seteados, pero permite comparar la igualdad * en orden indistinto (como si fuera un conjunto de puntos con 2 elementos) * * @author Mariano Kohan ([email protected]) * */ public class PointPair { /** Primer punto del par */ protected Point point1; /** Segundo punto del par */ protected Point point2; /** * Constructor del par de puntos * * @param point1 * @param point2 */ public PointPair(Point point1, Point point2) { this.point1 = point1; this.point2 = point2; } /** * Devuelve el primer punto del par * * @return the point1 */ public Point getPoint1() { return point1; } /** * Devuelve el segundo punto del par * * @return the point2 */ public Point getPoint2()


197

{ return point2; } /* Se compara la igualdad en orden indistinto * (non-Javadoc) * @see java.lang.Object#equals(java.lang.Object) */ @Override public boolean equals(Object obj) { if (!(obj instanceof PointPair)) return false; PointPair pairComp = (PointPair)obj; if ( (this.point1.equals(pairComp.getPoint1()) && this.point2.equals(pairComp.getPoint2()) ) || (this.point1.equals(pairComp.getPoint2()) && this.point2.equals(pairComp.getPoint1()) ) ) return true; return false; } /* (non-Javadoc) * @see java.lang.Object#toString() */ @Override public String toString() { return "( "+this.point1+" , "+this.point2+ ")"; } } /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.associations.spatiotemporal.predicates; /** * Predicado generico de dos parametros * * @author Mariano Kohan ([email protected]) * */ public abstract class Predicate { /** * Indican los parametros del predicado que son ciclicos */ //Nec. redefinir el caso correspondiente en la clases que heredan -> a traves de constructor //Las constantes son agregadas para informacion del PredicateSet protected static boolean PARAMETER_1_CICLIC = false; protected static boolean PARAMETER_2_CICLIC = false;


198

//Nec. redefinir el caso correspondiente en la clases que heredan -> a traves de constructor /** Indica si el primer parametro es ciclico */ protected boolean parameter1Ciclic = PARAMETER_1_CICLIC; /** Indica si el segundo parametro es ciclico */ protected boolean parameter2Ciclic = PARAMETER_2_CICLIC; /** Valor minimo del primer parametro */ protected double minParameter1; /** Valor maximo del primer parametro */ protected double maxParameter1; /** Valor minimo del segundo parametro */ protected double minParameter2; /** Valor maximo del segundo parametro */ protected double maxParameter2; /** PredicateCalculator utilizado para evaluar el predicado*/ protected PredicateCalculator calculator; /**Etiqueta identificatoria del primer parametro*/ protected String parameter1Label; /**Etiqueta identificatoria del segundo parametro*/ protected String parameter2Label; /** * Constructor wrapper para instanciar por reflection * * @param minParameter1 * @param maxParameter1 * @param minParameter2 * @param maxParameter2 * @param calculator */ public Predicate(double minParameter1, double maxParameter1, double minParameter2, double maxParameter2, PredicateCalculator calculator) { this.initialization(minParameter1, maxParameter1, minParameter2, maxParameter2, calculator); } /** * Constructor wraper para instanciar por reflection * * @param minParameter1 * @param maxParameter1 * @param minParameter2 * @param maxParameter2 * @param calculator */ public Predicate(Double minParameter1, Double maxParameter1, Double minParameter2, Double maxParameter2, PredicateCalculator calculator) { this(minParameter1.doubleValue(), maxParameter1.doubleValue(), minParameter2.doubleValue(), maxParameter2.doubleValue(),calculator); } /** * Constructor para ser usado por clases hijas para poder setear


199

* los parametros que son ciclicos * * @param minParameter1 * @param maxParameter1 * @param minParameter2 * @param maxParameter2 * @param calculator * @param parameter1Ciclic * @param parameter2Ciclic */ protected Predicate(double minParameter1, double maxParameter1, double minParameter2, double maxParameter2, PredicateCalculator calculator, boolean parameter1Ciclic, boolean parameter2Ciclic) { this.parameter1Ciclic = parameter1Ciclic; this.parameter2Ciclic = parameter2Ciclic; this.initialization(minParameter1, maxParameter1, minParameter2, maxParameter2, calculator); } /** * Constructor para ser usado por clases hijas para poder setear * los parametros que son ciclicos y las etiquetas identificatorias de los mismos * * @param minParameter1 * @param maxParameter1 * @param minParameter2 * @param maxParameter2 * @param calculator * @param parameter1Ciclic * @param parameter2Ciclic * @param parameter1Label * @param parameter2Label */ protected Predicate(double minParameter1, double maxParameter1, double minParameter2, double maxParameter2, PredicateCalculator calculator, boolean parameter1Ciclic, boolean parameter2Ciclic, String parameter1Label, String parameter2Label) { this.parameter1Ciclic = parameter1Ciclic; this.parameter2Ciclic = parameter2Ciclic; this.initialization(minParameter1, maxParameter1, minParameter2, maxParameter2, calculator); this.parameter1Label = parameter1Label; this.parameter2Label = parameter2Label; } /** * Inicializa los extremos de los parametros y el * PredicateCalculator utilizado * * @param minParameter1 * @param maxParameter1 * @param minParameter2 * @param maxParameter2 * @param calculator */ private void initialization(double minParameter1, double maxParameter1, double minParameter2, double maxParameter2, PredicateCalculator calculator) { //obs.: aca solo valido orden en los predicados para los parametros no ciclicos


200

if ( (!this.isParameter1Ciclic()) && (minParameter1 > maxParameter1) ) { throw new IllegalArgumentException("Error in predicate limits: "+ minParameter1 + " - " + maxParameter1); } if ( (!this.isParameter2Ciclic()) && (minParameter2 > maxParameter2) ) { throw new IllegalArgumentException("Error in predicate limits: "+ minParameter2 + " - " + maxParameter2); } this.minParameter1 = minParameter1; this.maxParameter1 = maxParameter1; this.minParameter2 = minParameter2; this.maxParameter2 = maxParameter2; this.calculator = calculator; } /** * @return */ public double getMaxParameter1() { return maxParameter1; } /** * @return */ public double getMaxParameter2() { return maxParameter2; } /** * @return */ public double getMinParameter1() { return minParameter1; } /** * @return */ public double getMinParameter2() { return minParameter2; } /** * @param maxParameter1 */ protected void setMaxParameter1(double maxParameter1) { this.maxParameter1 = maxParameter1; } /** * @param maxParameter2 */ protected void setMaxParameter2(double maxParameter2) { this.maxParameter2 = maxParameter2; }


201

/** * @param minParameter1 */ protected void setMinParameter1(double minParameter1) { this.minParameter1 = minParameter1; } /** * @param minParameter2 */ protected void setMinParameter2(double minParameter2) { this.minParameter2 = minParameter2; } /** * Devuelve el nombre del primer parametro del predicado * * @return */ public abstract String getParameter1Name(); /** * Devuelve el nombre del segundo parametro del predicado * * @return */ public abstract String getParameter2Name(); /** * Retorna una descripcion del rango de valores para el parametro 1 * Las clases hijas pueden extender el metodo para una presentacion * final mas favorable * * @return */ public String getParameter1ValueDescription() { String parameter1 = this.parameter1Label; if (parameter1 == null) { parameter1 = "[" + String.format("%.6f",this.minParameter1) + "," + String.format("%.6f",this.maxParameter1) + "]"; } return parameter1; } /** * Retorna una descripcion del rango de valores del parametro 2 * Las clases hijas pueden extender el metodo para una presentacion * final mas favorable * * @return */ public String getParameter2ValueDescription() { String parameter2 = this.parameter2Label; if (parameter2 == null) { parameter2 = "[" + String.format("%.6f",this.minParameter2) + "," + String.format("%.6f",this.maxParameter2) + "]"; } return parameter2; } /**

202

* Evalua el predicado. * Los intervalos del mismo se toman cerrados en el minimo (salvo caso de infinito) * y abierto en el maximo * * @param origin punto origen para evaluar el predicado * @param destination punto destino para evaluar el predicado * @return si el predicado se verifica entre los puntos dados */ public boolean evaluate(Point origin, Point destination) { this.calculator.setOriginPoint(origin); this.calculator.setDestinationPoint(destination); if ( (this.evaluateComponent1(this.calculator.getComponent1())) && (this.evaluateComponent2(this.calculator.getComponent2())) ) { return true; } return false; } /** * @return */ public PredicateCalculator getPredicateCalculator() { return this.calculator; } /** * @return the parameter1Ciclic */ public boolean isParameter1Ciclic() { return parameter1Ciclic; } /** * @return the parameter2Ciclic */ public boolean isParameter2Ciclic() { return parameter2Ciclic; } /** * Determina si el valor del componente dado se encuentra dentro * del correspondiente intervalo definido por el predicado * para el primer componente * * @param componentValue * @return */ private boolean evaluateComponent1(double componentValue) { if (this.isParameter1Ciclic()) { if (this.minParameter1 <= this.maxParameter1) { // valor en [minParameter1, maxParameter1) if ( (componentValue >= this.minParameter1) && (componentValue < this.maxParameter1) ) return true; } else {

203

//valor en [minParameter1, MAXCOMP1) U [MINCOMP1, maxParameter1) if ( ( (componentValue >= this.minParameter1) && (componentValue < this.getPredicateCalculator().getMaxValueComponent1() ) ) || ( (componentValue >= this.getPredicateCalculator().getMinValueComponent1()) && (componentValue < this.maxParameter1) ) ) return true; } } else { // valor en [minParameter1, maxParameter1) if ( (componentValue >= this.minParameter1) && (componentValue < this.maxParameter1) ) return true; } return false; } /** * Determina si el valor del componente dado se encuentra dentro * del correspondiente intervalo definido por el predicado * para el segundo componente * * @param componentValue * @return */ private boolean evaluateComponent2(double componentValue) { if (this.isParameter2Ciclic()) { if (this.minParameter2 <= this.maxParameter2) { // valor en [minParameter2, maxParameter2) if ( (componentValue >= this.minParameter2) && (componentValue < this.maxParameter2) ) return true; } else { //valor en [minParameter2, MAXCOMP2) U [MINCOMP2, maxParameter2) if ( ( (componentValue >= this.minParameter2) && (componentValue < this.getPredicateCalculator().getMaxValueComponent2() ) ) || ( (componentValue >= this.getPredicateCalculator().getMinValueComponent2()) && (componentValue < this.maxParameter2) ) ) return true; } } else { // valor en [minParameter2, maxParameter2) if ( (componentValue >= this.minParameter2) && (componentValue < this.maxParameter2) ) return true; } return false; } /* (non-Javadoc) * @see java.lang.Object#toString() */ @Override public String toString() {


204

String representantion = this.getParameter1Name() + "_" + this.getParameter1ValueDescription() + "-" + this.getParameter2Name() + "_" + this.getParameter2ValueDescription(); return representantion; } } /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.associations.spatiotemporal.predicates; /** * Predicado de tipo distancia y orientacion * * @author Mariano Kohan ([email protected]) * */ public class DistanceAnglePredicate extends Predicate { //distancia - no ciclico protected static boolean PARAMETER_1_CICLIC = false; //orientacion - ciclico protected static boolean PARAMETER_2_CICLIC = true; /** * @param minParameter1 * @param maxParameter1 * @param minParameter2 * @param maxParameter2 * @param calculator */ public DistanceAnglePredicate(double minParameter1, double maxParameter1, double minParameter2, double maxParameter2, PredicateCalculator calculator) { //distancia no ciclico - orientacion ciclico super(minParameter1, maxParameter1, minParameter2, maxParameter2, calculator,PARAMETER_1_CICLIC,PARAMETER_2_CICLIC); } /** * @param minParameter1 * @param maxParameter1 * @param minParameter2 * @param maxParameter2 * @param calculator * @param parameter1Label * @param parameter2Label */ public DistanceAnglePredicate(double minParameter1, double maxParameter1, double minParameter2, double maxParameter2, PredicateCalculator calculator,


205

String parameter1Label, String parameter2Label) { //distancia no ciclico - orientacion ciclico super(minParameter1, maxParameter1, minParameter2, maxParameter2, calculator,PARAMETER_1_CICLIC,PARAMETER_2_CICLIC,parameter1Label,parameter2Label); } /* (non-Javadoc) * @see weka.associations.spatiotemporal.predicates.Predicate#getParameter1Name() */ @Override public String getParameter1Name() { return "DISTANCE"; } /* (non-Javadoc) * @see weka.associations.spatiotemporal.predicates.Predicate#getParameter2Name() */ @Override public String getParameter2Name() { return "ORIENTATION"; } /** * Pruebas en la evaluacion de predicados en base a valores conocidos y calculados * externamente * * @param args */ public static void main(String[] args) { /* Caso de ejemplo: Jujuy ((-65.3;-24.18)) y Viedma ((-63;-40.8)) (ambas (log,lat)) Distancia: 1859.16 km - Orientacion: -80º (aprox.) */ Point origin = new GeographicPoint(-65.3,-24.18); Point destination = new GeographicPoint(-63,-40.8); //Point destination = new GeographicPoint(-73,-22.8); //800km, al O aprox. //obs.: los intervalos van en orden lineal (menor a mayor) DistanceAnglePredicate predicateValid = new DistanceAnglePredicate(1500,Double.POSITIVE_INFINITY, -112.5,-67.5, new DistanceAnglePredicateGeographicCalculator()); System.out.println("predicadoValid? "+predicateValid.evaluate(origin, destination)); DistanceAnglePredicate predicateInValid = null; predicateInValid = new DistanceAnglePredicate(500,1500, -112.5,-67.5, new DistanceAnglePredicateGeographicCalculator()); System.out.println("predicadoInValid? "+predicateInValid.evaluate(origin, destination)); predicateInValid = new DistanceAnglePredicate(900,2000, -80.5,-40, new DistanceAnglePredicateGeographicCalculator()); System.out.println("predicadoInValid? "+predicateInValid.evaluate(origin, destination)); predicateInValid = new DistanceAnglePredicate(2000,2200, -20,20,


206

new DistanceAnglePredicateGeographicCalculator()); System.out.println("predicadoInValid? "+predicateInValid.evaluate(origin, destination)); predicateInValid = new DistanceAnglePredicate(0,2200, 160,-157.5, new DistanceAnglePredicateGeographicCalculator()); System.out.println("predicadoInValid? "+predicateInValid.evaluate(origin, destination)); } } /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.associations.spatiotemporal.predicates; /** * Se encarga del calculo de los componentes * de los predicados espaciales * * @author Mariano Kohan ([email protected]) * */ public abstract class PredicateCalculator { /** Minimo valor de la primer componente de los predicados a calcular */ protected double minValueComponent1=Double.NaN; /** Maximo valor de la primer componente de los predicados a calcular */ protected double maxValueComponent1=Double.NaN; /** Minimo valor de la segunda componente de los predicados a calcular */ protected double minValueComponent2=Double.NaN; /** Maximo valor de la segunda componente de los predicados a calcular */ protected double maxValueComponent2=Double.NaN; /** Punto origen a considerar en el calculo de las componentes */ protected Point originPoint; /** Punto destino a considerar en el calculo de las componentes */ protected Point destinationPoint; protected double component1=Double.NaN; protected double component2=Double.NaN; protected String predicateClassName; /** * Constructor * */ public PredicateCalculator()


207

{ this.originPoint = null; this.destinationPoint = null; } /** * Constructor con puntos a considerar en el calculo de las componentes * * @param originPoint * @param destinationPoint */ public PredicateCalculator(Point originPoint, Point destinationPoint) { this.setOriginPoint(originPoint); this.setDestinationPoint(destinationPoint); } /** * @param point */ public void setOriginPoint(Point point) { if (point == null) { throw new NullPointerException("Origin point must be not null"); } this.originPoint = point; if (this.destinationPoint != null) { calculateComponents(); } } /** * @param point */ public void setDestinationPoint(Point point) { if (point == null) { throw new NullPointerException("Destination point must be not null"); } this.destinationPoint = point; if (this.originPoint != null) { calculateComponents(); } } /** * Devuelve el valor del componente 1 del predicado calculado * * @return */ public double getComponent1() { return this.component1; } /** * Devuelve el valor del componente 2 del predicado calculado * * @return */ public double getComponent2() { return this.component2;


208

} /** * Calcula el valor de los componentes del predicado y los setea al mismo * Supone ambos puntos no null * * @return */ public abstract void calculateComponents(); /** * Devuelve el nombre de la clase de predicado, de tipo Predicate, * para la cual se realizan los calculos * * @return the predicateClassName */ public String getPredicateClassName() { return predicateClassName; } /** * @return the maxValueComponent1 */ public double getMaxValueComponent1() { return maxValueComponent1; } /** * @return the maxValueComponent2 */ public double getMaxValueComponent2() { return maxValueComponent2; } /** * @return the minValueComponent1 */ public double getMinValueComponent1() { return minValueComponent1; } /** * @return the minValueComponent2 */ public double getMinValueComponent2() { return minValueComponent2; } /** * Devuelve el nombre de la clase punto, de tipo Point, para la cual se realizan los calculos * * @return */ public abstract String getPointClassName(); } /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or


209

* (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.associations.spatiotemporal.predicates; /** * Define el comportamiento de un PredicateCalculator que realiza * los calculos en base a puntos geograficos * * @author Mariano Kohan ([email protected]) * */ public interface IGeographicCalculator { public static String POINT_CLASS_NAME = "weka.associations.spatiotemporal.predicates.GeographicPoint"; } /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.associations.spatiotemporal.predicates; /** * Define el comportamiento de un PredicateCalculator que realiza * los calculos en base a puntos proyectados * * @author Mariano Kohan ([email protected]) * */ public interface IProjectedCalculator { public static String POINT_CLASS_NAME = "weka.associations.spatiotemporal.predicates.ProjectedPoint"; } /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. *


210

* You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.associations.spatiotemporal.predicates; import org.geotools.referencing.GeodeticCalculator; /** * Calcula los componentes de un predicado de tipo distancia y orientacion * en base a puntos definidos segun coordenadas geograficas * La distancia se mide km * La orientacion se mide en grados respecto al semi-eje horizontal positivo, * tomando el sentido antihorario positivo * * @author Mariano Kohan ([email protected]) * */ public class DistanceAnglePredicateGeographicCalculator extends PredicateCalculator implements IGeographicCalculator { /** * Constructor * */ public DistanceAnglePredicateGeographicCalculator() { super(); //Componente1=distancia this.minValueComponent1=0; this.maxValueComponent1=Double.POSITIVE_INFINITY; //Componente2=orientacion this.minValueComponent2=-180.000000; this.maxValueComponent2=180.000000; //Predicado distancia-orientacion this.predicateClassName = "weka.associations.spatiotemporal.predicates.DistanceAnglePredicate"; } /** * Constructor con puntos (geograficos) a considerar en el calculo de las componentes * * @param originPoint * @param destinationPoint */ public DistanceAnglePredicateGeographicCalculator(Point originPoint, Point destinationPoint) { super(originPoint,destinationPoint); //Componente1=distancia this.minValueComponent1=0; this.maxValueComponent1=Double.POSITIVE_INFINITY; //Componente2=orientacion this.minValueComponent2=-180.000000; this.maxValueComponent2=180.000000; //Predicado distancia-orientacion this.predicateClassName = "weka.associations.spatiotemporal.predicates.DistanceAnglePredicate"; } /* (non-Javadoc)


211

* @see weka.associations.spatiotemporal.predicates.PredicateCalculator#calculateComponents() * componente1: distancia * componente2: orientacion */ @Override public void calculateComponents() { GeodeticCalculator geodeticCalculator = new GeodeticCalculator(); GeographicPoint origin = (GeographicPoint)this.originPoint; geodeticCalculator.setAnchorPoint(origin.getLongitude(),origin.getLatitude()); GeographicPoint destination = (GeographicPoint)this.destinationPoint; geodeticCalculator.setDestinationPoint(destination.getLongitude(),destination.getLatitude()); //distancia en km this.component1 = geodeticCalculator.getOrthodromicDistance()/1000; //respecto a eje horizontal positivo y en sentido antihorario if (geodeticCalculator.getAzimuth() >= -90.00) { this.component2 = 90.00 - geodeticCalculator.getAzimuth(); } else { this.component2 = (-1 )* (geodeticCalculator.getAzimuth() + 270.00); } } /* (non-Javadoc) * @see weka.associations.spatiotemporal.predicates.PredicateCalculator#getPointClassName() */ public String getPointClassName() { return POINT_CLASS_NAME; } /** * @param args */ public static void main(String[] args) { Point origin = new GeographicPoint(-58.38167,-34.60361); //Buenos Aires Point destination = new GeographicPoint(-57.55,-38); //Mar del Plata PredicateCalculator predicateCalculator = new DistanceAnglePredicateGeographicCalculator(origin,destination); System.out.println(predicateCalculator); } } /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software


212

* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.associations.spatiotemporal.predicates; import java.beans.Expression; /** * Conjunto de predicados espaciales manejados por el algoritmo * * @author Mariano Kohan ([email protected]) * */ public class PredicateSet { /** PredicateCalculator que calcula los componentes de los predicados * espaciales del conjunto */ private PredicateCalculator predicateCalculator = null; private double[] component1IntervalLimits = null; private String[] component1IntervalLabels = null; private double[] component2IntervalLimits = null; private String[] component2IntervalLabels = null; private Predicate[] predicates = null; /** * Constructor * * @param predicateCalculatorClassName nombre de la clase para el calculo de las * componentes de los predicados (PredicateCalculator) * @param component1IntervalLimits limites de los intervalos de la primer componente de los predicados espaciales * @param component2IntervalLimits limites de los intervalos de la segunda componente de los predicados espaciales * @param component1IntervalLabels etiquetas de los intervalos de la primer componente de los predicados espaciales * @param component2IntervalLabels etiquetas de los intervalos de la segunda componente de los predicados espaciales * @throws Exception */ public PredicateSet(String predicateCalculatorClassName, double[] component1IntervalLimits, double[] component2IntervalLimits, String[] component1IntervalLabels, String[] component2IntervalLabels) throws Exception { Class predicateCalculatorClass = Class.forName(predicateCalculatorClassName); this.predicateCalculator = (PredicateCalculator)predicateCalculatorClass.newInstance(); //valido limites de los componentes //creo un predicado nullo para saber los parametros si son ciclicos o no Class predicateClass = Class.forName(this.getPredicateCalculator().getPredicateClassName()); Expression expression = new Expression(predicateClass,"new", new Object[] {0.0,1.0,0.0,1.0,this.predicateCalculator} ); expression.execute(); Predicate nullPredicate = (Predicate)expression.getValue(); if ( !(this.validateLimits(component1IntervalLimits, nullPredicate.isParameter1Ciclic() , this.predicateCalculator.getMinValueComponent1(), this.predicateCalculator.getMaxValueComponent1())) )


213

{ throw new IllegalArgumentException("Bad interval limits for component 1"); } if ( !(this.validateLimits(component2IntervalLimits, nullPredicate.isParameter2Ciclic() , this.predicateCalculator.getMinValueComponent2(), this.predicateCalculator.getMaxValueComponent2())) ) { throw new IllegalArgumentException("Bad interval limits for component 2"); } this.component1IntervalLimits = component1IntervalLimits; this.component2IntervalLimits = component2IntervalLimits; this.component1IntervalLabels = component1IntervalLabels; this.component2IntervalLabels = component2IntervalLabels; this.createPredicates(); } /** * @return */ public PredicateCalculator getPredicateCalculator() { return this.predicateCalculator; } /** * Retorna el indice de un predicado, en el vector de predicados del "conjunto", * dados los indices en los vectores de limites de las componentes de los predicados * * @param indexComponent1 indice en el vector de limites de intervalos de la primer componente de los predicados * @param indexComponent2 indice en el vector de limites de intervalos de la segunda componente de los predicados * @return */ protected int getPredicateIndex(int indexComponent1, int indexComponent2) throws Exception { if ( (indexComponent1 >= (this.component1IntervalLimits.length - 1)) || (indexComponent2 >= (this.component2IntervalLimits.length - 1)) ) { throw new Exception("Component Index out of bounds."); } return ( indexComponent1 * (this.component2IntervalLimits.length - 1) + indexComponent2 ); } /** * Crea predicados * Construye cada objeto en base a valores de los limites y labels * de cada componente, y lo asigna al conjunto * * @throws Exception */ private void createPredicates() throws Exception { int maxPredicates = (this.component1IntervalLimits.length - 1) * (this.component2IntervalLimits.length - 1); Predicate[] predicates = new Predicate[maxPredicates]; int p = 0;

214

Class predicateClass = Class.forName(this.getPredicateCalculator().getPredicateClassName()); for (int i = 0; i < this.component1IntervalLimits.length-1; i++) { for (int j = 0; j < this.component2IntervalLimits.length-1; j++) { Expression expression = new Expression(predicateClass,"new", new Object[] {this.component1IntervalLimits[i], this.component1IntervalLimits[i+1], this.component2IntervalLimits[j], this.component2IntervalLimits[j+1], this.predicateCalculator, this.component1IntervalLabels[i], this.component2IntervalLabels[j]} ); expression.execute(); predicates[p] = (Predicate)expression.getValue() ; p++; } } this.predicates = predicates; } /** * Valida el vector de limites del componente: que los valores se encuentren en orden * - Componente no ciclico: 1º=min, ultimo=max * - Componente ciclico: igual anterior ó 1º=ultimo + salvedad de orden en un intervalo * * @param limits vector de limites del componente * @param ciclicComponent si el componente es ciclico o no * @param min minimo valor del componente * @param max maximo valor del componente * @return */ private boolean validateLimits(double[] limits, boolean ciclicComponent, double min, double max) { int unorderCount = 0; for (int i = 0; i < limits.length-1; i++) { if (limits[i] >= limits[i+1]) unorderCount++; } if (unorderCount == 0) { if (!((limits[0] == min) && (limits[limits.length-1] == max))) { return false; } } else { if (!ciclicComponent) { return false; } else { if (!((unorderCount == 1)&&(limits[0]==limits[limits.length-1]))) { return false; } } } return true; }

215

/** * Devuelve un predicado dado su indice * * @param index * @return */ public Predicate getPredicate(int index) { return this.predicates[index]; } /** * Calcula el predicado entre dos puntos * * @param origin punto origen * @param destination punto destino * @return indice del predicado (dentro del conjunto actual - (utilizable junto con @link #getPredicate(int)) */ //calculo componentes y recorro vector de limites para ver entre que valores cae // ( NO: recorrer predicados y evaluar -> repetiria calculo de componentes entre los puntos ) public int calculatePredicate(Point origin, Point destination) throws Exception { this.predicateCalculator.setOriginPoint(origin); this.predicateCalculator.setDestinationPoint(destination); double component1 = this.predicateCalculator.getComponent1(); double component2 = this.predicateCalculator.getComponent2(); int component1Index = Integer.MAX_VALUE, component2Index = Integer.MAX_VALUE; for (int i = 0; i < this.component1IntervalLimits.length-1; i++) { //sup. si limit inf. > limite sup. -> intervalor valido (seria componente ciclico -ya validado-) if (this.component1IntervalLimits[i] < this.component1IntervalLimits[i+1]) { if ( (this.component1IntervalLimits[i] <= component1) && (component1 < this.component1IntervalLimits[i+1]) ) { component1Index=i; break; } } else { if ( ( (this.component1IntervalLimits[i] <= component1 ) && (component1 < this.getPredicateCalculator().getMaxValueComponent1() ) ) || ( (component1 >= this.getPredicateCalculator().getMinValueComponent1()) && (component1 < this.component1IntervalLimits[i+1]) ) ) { component1Index=i; break; } } } for (int j = 0; j< this.component2IntervalLimits.length-1; j++) { //sup. si limit inf. > limite sup. -> intervalor valido (seria componente ciclico -ya validado-)

216

if (this.component2IntervalLimits[j] < this.component2IntervalLimits[j+1]) { if ( (this.component2IntervalLimits[j] <= component2) && (component2 < this.component2IntervalLimits[j+1]) ) { component2Index=j; break; } } else { if ( ( (this.component2IntervalLimits[j] <= component2 ) && (component2 < this.getPredicateCalculator().getMaxValueComponent2() ) ) || ( (component2 >= this.getPredicateCalculator().getMinValueComponent2()) && (component2 < this.component2IntervalLimits[j+1]) ) ) { component2Index=j; break; } } } return this.getPredicateIndex(component1Index, component2Index); } /** * Pruebas iniciales en el calculo de predicados en base a valores conocidos * y calculados externamente * * @param args * @throws Exception */ public static void main(String[] args) throws Exception { double[] component1Limits = {0, 40, 100, 220, 450, 900, 1800, Double.POSITIVE_INFINITY}; double[] component2Limits = {-157.5, -112.5, -67.5, -22.5, 22.5, 67.5, 112.5, 157.5, -157.5}; String[] component1Labels = {"MC", "C", "MDC", "MED", "MDL", "L", "ML"}; String[] component2Labels = {"SO", "S", "SE", "E", "NE", "N", "NO", "O"}; String predicateCalculator = "weka.associations.spatiotemporal.predicates.DistanceAnglePredicateGeographicCalculator"; PredicateSet predicates = new PredicateSet(predicateCalculator, component1Limits, component2Limits, component1Labels, component2Labels); /* Caso de ejemplo: Jujuy ((-65.3;-24.18)) y Viedma ((-63;-40.8)) (ambas (log,lat)) Distancia: 1859.16 km - Orientacion: -80º (aprox.) */ Point origin = new GeographicPoint(-65.3,-24.18); Point destination = new GeographicPoint(-63,-40.8); int index = predicates.calculatePredicate(origin, destination); Predicate predicate = predicates.getPredicate(index); System.out.println("Predicado: "+predicate); System.out.println("Evaluacion: "+predicate.evaluate(origin, destination)); predicate = predicates.getPredicate(20); System.out.println("Predicado2: "+predicate); System.out.println("Evaluacion: "+predicate.evaluate(origin, destination)); destination = new GeographicPoint(-73,-22.8); //800km, al O aprox. System.out.println("Evaluacion2: "+predicate.evaluate(origin, destination));


217

predicate = predicates.getPredicate(31); System.out.println("Predicado3 (L-O): "+predicate); System.out.println("Evaluacion2: "+predicate.evaluate(origin, destination)); } }

C.3. Paquete weka.associations.spatiotemporal.temporal

/* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.associations.spatiotemporal.temporal; /** * Histograma temporal de las transacciones del dataset * * @author Mariano Kohan ([email protected]) * */ public class TemporalHistogram { /** * Valores almacenados en el histograma * (cantidad de transacciones en cada intervalo) */ protected int[] histogram; /** * Extremo del valor temporal minimo */ protected double minTimestamp; /** * Extremo del valor temporal maximo */ protected double maxTimestamp; /** * Unidad temporal (en milisegundos) */ protected double temporalUnit; /** * Ancho del intervalo (en unidades temporales) */ protected double intervalWidth; /** * Indica si algun contador del histograma fue actualizado */


218

protected boolean updated; /** * Constructor * * @param minTimestamp extremo temporal minimo * @param maxTimestamp extremo temporal maximo (no incluido) * @param temporalUnit unidad temporal del histograma (en milisegundos) * @param intervalWidth ancho de los intervalos del histograma (en unidades temporales) */ public TemporalHistogram(double minTimestamp, double maxTimestamp, double temporalUnit, double intervalWidth) { this.minTimestamp = minTimestamp; this.maxTimestamp = maxTimestamp; this.temporalUnit = temporalUnit; this.intervalWidth = intervalWidth; double datasetLifespan = this.maxTimestamp - this.minTimestamp; int histogramLength = (int) Math.ceil(datasetLifespan /this.getIntervalWidthUnit()); this.histogram = new int[histogramLength]; this.updated = false; } /** * @return the maxTimestamp */ public double getMaxTimestamp() { return maxTimestamp; } /** * @return the minTimestamp */ public double getMinTimestamp() { return minTimestamp; } /** * @return the temporalUnit - unidad temporal del histograma */ public double getTemporalUnit() { return temporalUnit; } /** * Devuelve el ancho temporal de los intervalos (en milisegundos) * * @return */ public double getIntervalWidthUnit() { return (this.intervalWidth * this.temporalUnit); } /** * Devuelve el numero de transacciones contabilizadas en la posicion del intervalo dado * * @param pos posicion del intervalo * @return cantidad de transacciones contabilizadas en el mismo */ public int getTransactionsNumber(int pos)

219

{ return this.histogram[pos]; } /** * Incrementa el numero de transacciones contabilizadas en la * posicion del intervalo dado * * @param pos */ public void incrementTransactionsNumber(int pos) { this.histogram[pos]++; if (!this.updated) this.updated = true; } /** * Devuelve el indice de posicion en el histograma para el * valor temporal dado * * @param timestamp * @return */ public int getTemporalPosition(double timestamp) throws RuntimeException { if ((timestamp < this.minTimestamp) || (timestamp > this.maxTimestamp)) throw new RuntimeException("Invalid timestamp " + timestamp + "(" + new java.util.Date((new Double(timestamp)).longValue()) + ") - not compatible with dataset"); timestamp -= this.minTimestamp; return ((int)((long)timestamp/((long)this.getIntervalWidthUnit()))); } /** * Devuelve el valor temporal del extremo minimo del intervalo * según el indice de posicion del mismo * * @param pos * @return */ public double getIntervalMinimum(int pos) { return (this.minTimestamp + (pos * this.getIntervalWidthUnit())); } /** * Devuelve el valor temporal del extremo maximo del intervalo * según el indice de posicion del mismo * * @param pos * @return */ public double getIntervalMaximum(int pos) { if (pos == (this.histogram.length - 1)) return (this.maxTimestamp - this.temporalUnit); //la ultima posicion se cierra en el maximo del histograma else return (this.getIntervalMinimum(pos + 1) - this.temporalUnit); } /** * Indica si se actualizo algun contador del histograma *

220

* @return */ public boolean updated() { return this.updated; } /** * Devuelve la cantidad de intervalos del histograma * * @return */ public int getIntervalsCount() { return this.histogram.length; } }

C.4. Paquete weka.filters.unsupervised.attribute

/* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.filters.unsupervised.attribute; import weka.core.Attribute; import weka.core.Capabilities; import weka.core.FastVector; import weka.core.Instance; import weka.core.Instances; import weka.core.Option; import weka.core.OptionHandler; import weka.core.SingleIndex; import weka.core.UnsupportedAttributeTypeException; import weka.core.Utils; import weka.core.Capabilities.Capability; import weka.filters.Filter; import weka.filters.StreamableFilter; import weka.filters.UnsupervisedFilter; import java.util.Enumeration; import java.util.Vector; /**  * Convierte columnas con coordenadas geograficas en formato de gradosº minutos' segundos'' al * formato decimal grados,minutos_segundos_decimal. * Se uso es para algoritmos espaciales que manejan coordenadas geograficas, por ej. SpatioTemporalApriori.

221

* Las columnas de entrada vienen en un String con formato DDº MM' SS.fff'' o DDº MM' SS.fff * y se convierten en DD,dddd , siendo ddd la parte decimal de los minutos y segundos respecto * a los grados. *  *  * Opciones validas: * * <pre> -C <col,col,...> * Indices de columnas a convertir (default 2,3).</pre> *  * * @author Mariano Kohan ([email protected]) * @version 1.0 */ public class DegressToDecimalFormat extends Filter implements UnsupervisedFilter, StreamableFilter, OptionHandler { /** indices de los atributos a ser convertidos */ private SingleIndex[] m_AttributesIndex = new SingleIndex[]{ new SingleIndex("2"),new SingleIndex("3") }; /** * Retorna un string describiendo este Filtro * * @return descripcion del Filtro para ser * mostrada en el explorer/experimenter gui */ public String globalInfo() { return "Convert the columns with geographic coordinates and format degressº minutes' seconds'' " + "to the decimal format degress,minutes_seconds_decimal.\n"+ "It's used with spatial algorithms that process geographic coordinates, eg. SpatioTemporalApriori.\n"+ "The input columns are a String with format DDº MM' SS.fff'' or DDº MM' SS.fff "+ "and are converted to \"DD,dddd\", where dddd is the decimal part of the minutes and seconds " + "with respect to the degress."; } /** * Retorna las Capabilities default del Filtro * * @return capabilities del Filtro * @see Capabilities */ public Capabilities getCapabilities() { Capabilities result = super.getCapabilities(); //esquema dataset: t,posX,posY,att1=val1,....,attn=valn // attributes - fecha + posicion geografica (string) + att=valor (nominal, binario o numerico) result.enable(Capability.STRING_ATTRIBUTES); //los restantes atributos que no se van a manejar result.enable(Capability.DATE_ATTRIBUTES);

222

result.enable(Capability.NOMINAL_ATTRIBUTES); //para despues o antes de discretizacion result.enable(Capability.BINARY_ATTRIBUTES); result.enable(Capability.NUMERIC_ATTRIBUTES); // class result.enable(Capability.NO_CLASS); return result; } /** * Setea el formato de las instancia de entrada al filtro * * @param instanceInfo objeto Instances conteniendo la estructura * de las instancias de entrada al filtro (cualquier instancia contenida * en el objeto es ignorada) * @return true si el formato de salida puede ser obtenido de manera inmediata * @throws Exception si el formato de la entrada no puede ser seteado * de manera satisfactoria */ public boolean setInputFormat(Instances instanceInfo) throws Exception { super.setInputFormat(instanceInfo); for (int i = 0; i < this.m_AttributesIndex.length; i++) { m_AttributesIndex[i].setUpper(instanceInfo.numAttributes() - 1); if ( (!instanceInfo.attribute(m_AttributesIndex[i].getIndex()).isString()) && (!instanceInfo.attribute(m_AttributesIndex[i].getIndex()).isNominal())) { throw new UnsupportedAttributeTypeException ("Chosen attribute "+m_AttributesIndex[i].getSingleIndex()+"is not String."); } } this.setOutputFormat(); return true; } /** * Setea el formato de los atributos de salida del filtro */ private void setOutputFormat() { // Nuevos atributos FastVector newAtts = new FastVector(getInputFormat().numAttributes()); for (int j = 0; j < getInputFormat().numAttributes(); j++) { Attribute att = getInputFormat().attribute(j); boolean isColumnIndex = false; for (int i = 0; i < m_AttributesIndex.length; i++) { if (j == m_AttributesIndex[i].getIndex()) { isColumnIndex = true; } } if (isColumnIndex) { newAtts.addElement(new Attribute(att.name())); }

223

else { newAtts.addElement(att.copy()); } } // Nuevo Header Instances newData = new Instances(getInputFormat().relationName(), newAtts, 0); newData.setClassIndex(-1); setOutputFormat(newData); } /** * Realiza el filtrado de la instancia dada * * @param instance instancia de entrada a ser filtrada * @return true si la instancia filtrada puede ser recolectada * a continuacion mediante {@link DegressToDecimalFormat#output()} * @throws Exception si el formato de entrada no fue definido */ public boolean input(Instance instance) throws Exception { if (getInputFormat() == null) { throw new IllegalStateException("No input instance format defined"); } if (m_NewBatch) { resetQueue(); m_NewBatch = false; } Instance newInstance = (Instance)instance.copy(); for (int i = 0; i < m_AttributesIndex.length; i++) { String coordinate = instance.stringValue(m_AttributesIndex[i].getIndex()); newInstance.setValue(m_AttributesIndex[i].getIndex(), this.formatDegrees(coordinate)); } push(newInstance); return true; } /** * Convierte el string en formato de grados a formato numerico * * @param degress * @return */ private double formatDegrees(String degrees) throws Exception { int lastPosition = degrees.indexOf('-'); int sign = 1; if (lastPosition >= 0) sign = -1; degrees = degrees.substring(lastPosition + 1); degrees.trim(); int initPosition = 0; lastPosition = degrees.indexOf('°'); if (lastPosition == -1) {

224

lastPosition = degrees.indexOf('º'); if (lastPosition == -1) { throw new RuntimeException("No degrees symbol visible: "+degrees); } } double degree = Double.parseDouble(degrees.substring(initPosition, lastPosition)); initPosition = lastPosition+1; lastPosition = degrees.indexOf('\'',initPosition); if (lastPosition == -1) { new RuntimeException("No minutes symbol visible: "+degrees); } double minutes = Double.parseDouble(degrees.substring(initPosition, lastPosition)); initPosition = lastPosition+1; lastPosition = degrees.indexOf("''",initPosition); if (lastPosition == -1) { lastPosition = degrees.length(); } double seconds = Double.parseDouble(degrees.substring(initPosition, lastPosition)); return (sign*(degree + (minutes/60) + (seconds/3600))); } /** * Retorna una enumeracion describiendo las opciones disponibles * * @return Enumeration con todas las opciones disponibles */ public Enumeration listOptions() { Vector newVector = new Vector(1); newVector.addElement(new Option( "\tAttributes index of columns to convert (default 2,3).", "C", 1, "-C <col,col>")); return newVector.elements(); } /** * Parsea una lista de opciones dada *  * Opciones validas: * * <pre> -C <col,col,...> * Indices de columnas a convertir (default 2,3).</pre> *  * * @param options lista de opciones como arreglo de String * @throws Exception si una opcion no se encuentra soportada */ public void setOptions(String[] options) throws Exception { String attsIndex = Utils.getOption('C', options); if (attsIndex.length() != 0) { this.setAttributesIndexs(attsIndex); }

225

else { this.setAttributesIndexs("2,3"); } } /** * Obtiene la configuracion actual del Filtro * * @return arreglo de String, adecuando para ser pasado a * {@link DegressToDecimalFormat#setOptions(String[])} */ public String [] getOptions() { Vector result; result = new Vector(); result.add("-C"); result.add("" + getAttributesIndexs()); return (String[]) result.toArray(new String[result.size()]); } /** * Retorna el tip text para esta propiedad * * @return tip text de esta propiedad para ser * mostrada en el explorer/experimenter gui */ public String attributesIndexsTipText() { return "The attributes to process. This " + "attributes must be of type string (the values are separated with ',')"; } /** * Retorna los indices de los atributos a ser convertidos * * @return indices de los atributos */ public String getAttributesIndexs() { String attsIndex = m_AttributesIndex[0].getSingleIndex(); for (int i = 1; i < m_AttributesIndex.length; i++) { attsIndex += ","+m_AttributesIndex[i].getSingleIndex(); } return attsIndex; } /** * Setea los indices de los atributos a ser convertidos * * @param attIndex indices de los atributos a ser convertidos */ public void setAttributesIndexs(String attsIndex) { String[] indexs = attsIndex.split("\\,"); m_AttributesIndex = new SingleIndex[indexs.length]; for (int i = 0; i < indexs.length; i++) { m_AttributesIndex[i] = new SingleIndex(indexs[i]); } }

226

/** * Metodo main para uso del Filtro * * @param argv argumentos del Filtro * usar -h para ayuda */ public static void main(String [] argv) { runFilter(new DegressToDecimalFormat(), argv); } } /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.filters.unsupervised.attribute; import java.util.Enumeration; import java.util.Vector; import weka.clusterers.Clusterer; import weka.clusterers.EM; import weka.core.Attribute; import weka.core.Capabilities; import weka.core.FastVector; import weka.core.Instance; import weka.core.Instances; import weka.core.Option; import weka.core.OptionHandler; import weka.core.SingleIndex; import weka.core.Utils; import weka.core.Capabilities.Capability; import weka.filters.Filter; import weka.filters.UnsupervisedFilter; /**  * Realiza la discretizacion del atributo indicado mediante clustering: aplica el * clusterer sobre los valores del mismo y asigna el cluster correspondientes * sobre cada uno de los mismos. *  *  * Opciones validas: * * <pre> -W <clusterer name> * Nombre completo de la clase clusterer a utilizar. * por ej.: weka.clusterers.EM * Opciones adicionales se colocan luego de '--'. * (default: weka.clusterers.EM)</pre> * * <pre> -I <attn> * Indice del atributo a discretizar</pre> *

227

* Las opciones luego de -- son pasadas al clusterer.  * * * * @author Mariano Kohan * @version 0.1 */ public class ClusterDiscretize extends Filter implements UnsupervisedFilter, OptionHandler { /** Indice del atributo a ser discretizado*/ protected SingleIndex attibuteToDiscretizeIndex; /** Clusterer utilizado para discretizar los valores del atributo seleccionado */ protected Clusterer clusterer; /** Filtro para remover atributos que no van a ser discretizados */ protected Filter removeAttributesFilter; /** * Constructor del Filtro * @throws Exception */ public ClusterDiscretize() throws Exception { this.attibuteToDiscretizeIndex = new SingleIndex(); resetOptions(); } /** * Retorna las Capabilities default del Filtro * * @return capabilities del Filtro * @see Capabilities */ public Capabilities getCapabilities() { Capabilities result = clusterer.getCapabilities(); //un clusterer no maneja fechas, pero es probable que se encuentre en el dataset //en base al uso pensado para el filtro result.enable(Capability.DATE_ATTRIBUTES); result.setMinimumNumberInstances(0); return result; } /** * Testea si el Filtro puede manejar los datos dados * * @param instanceInfo datos a ser testeados * @throws Exception si falla el test */ protected void testInputFormat(Instances instanceInfo) throws Exception { getCapabilities().testWithFail(isolateAttributes(instanceInfo)); } /**

228

* Setea el formato de las instancia de entrada al filtro * * @param instanceInfo objeto Instances conteniendo la estructura * de las instancias de entrada al filtro (cualquier instancia contenida * en el objeto es ignorada) * @return true si el formato de salida puede ser obtenido de manera inmediata * @throws Exception si el formato de la entrada no puede ser seteado * de manera satisfactoria */ public boolean setInputFormat(Instances instanceInfo) throws Exception { super.setInputFormat(instanceInfo); removeAttributesFilter = null; attibuteToDiscretizeIndex.setUpper(instanceInfo.numAttributes() - 1); return false; } /** * Filtra todos los atributos que no van a ser discretizados * * @param data datos a ser filtrados * @return datos filtrados * @throws Exception si falla falla el filtro de Remove */ protected Instances isolateAttributes(Instances data) throws Exception { //solo tomo el atributo a discretizar Instances result = null; if (attibuteToDiscretizeIndex != null) { result = new Instances(data); removeAttributesFilter = new Remove(); String rangeString = attibuteToDiscretizeIndex.getSingleIndex(); rangeString += "-" + attibuteToDiscretizeIndex.getSingleIndex(); ((Remove) removeAttributesFilter).setAttributeIndices(rangeString); ((Remove) removeAttributesFilter).setInvertSelection(true); removeAttributesFilter.setInputFormat(data); result = Filter.useFilter(data, removeAttributesFilter); } return result; } /** * Devuelve identificaciones de los clusters obtenidos * * @return */ protected FastVector clustersLabels(String attributeName) throws Exception { //caso base: <attributte>_<num-cluster> //según el cluster se puede dar info particular //por ej. para EM existe getClusterModelsNumericAtts donde se indica la media, desvio standard y ... FastVector clusteredAttributeValues = new FastVector(); if (this.clusterer instanceof EM) { EM emClusterer = (EM)clusterer; double[][][] clusterModels = emClusterer.getClusterModelsNumericAtts(); for (int j = 0; j < this.clusterer.numberOfClusters(); j++) clusteredAttributeValues.addElement(attributeName + "_[ Mean=" + Utils.doubleToString(clusterModels[j][0][0],4) + "; StdDev= " + Utils.doubleToString(clusterModels[j][0][1],4) + "]" );

229

} else { for (int j = 0; j < this.clusterer.numberOfClusters(); j++) clusteredAttributeValues.addElement(attributeName + "_" + j); } clusteredAttributeValues.trimToSize(); return clusteredAttributeValues; } /** * Señala si finalizo el procesamiento batch del filtrado de las * instancias de entrada al filtro * Si el filtro requiere todas las instancias previo al procesamiento, * {@link #output()} deberia ser llamado para obtener las instancias filtradas. * * @return true si quedan instancias pendientes a ser procesadas para la salida * @throws IllegalStateException si el formato de entrada no fue definido */ public boolean batchFinished() throws Exception { if (getInputFormat() == null) { throw new IllegalStateException("No input instance format defined"); } if (outputFormatPeek() == null) { Instances toFilter = getInputFormat(); Instances toDiscretize = this.isolateAttributes(toFilter); clusterer.buildClusterer(toDiscretize); // create output dataset FastVector attInfo = new FastVector(); for (int i = 0; i < toFilter.numAttributes(); i++) { if (i == this.attibuteToDiscretizeIndex.getIndex()) { String clusteredAttributeName = toFilter.attribute(i).name(); FastVector clusteredAttributeValues = this.clustersLabels(clusteredAttributeName); attInfo.addElement(new Attribute(clusteredAttributeName,clusteredAttributeValues)); } else attInfo.addElement(toFilter.attribute(i).copy()); } attInfo.trimToSize(); Instances filtered = new Instances(toFilter.relationName()+"_clusterDiscretize", attInfo, 0); setOutputFormat(filtered); // armo el nuevo dataset for (int i = 0; i < toFilter.numInstances(); i++) { convertInstance(toFilter.instance(i)); } } flushInput(); m_NewBatch = true; return (numPendingOutput() != 0); }

230

/** * Realiza el filtrado de la instancia dada. * En general, las instancias se procesan y se encuentran disponibles en la salida * inmediatamente. Algunos filtros requieren leer todas las instancias de la entrada * antes de comenzar el procesamiento de la salida * * @param instance instancia de entrada a ser filtrada * @return true si la instancia filtrada puede ser recolectada * a continuacion mediante {@link DegressToDecimalFormat#output()} * @throws Exception si el formato de entrada no fue definido */ public boolean input(Instance instance) throws Exception { if (getInputFormat() == null) { throw new IllegalStateException("No input instance format defined"); } if (m_NewBatch) { resetQueue(); m_NewBatch = false; } if (outputFormatPeek() != null) { convertInstance(instance); return true; } bufferInput(instance); return false; } /** * Convierte una instancia dada. La instancia de salida se agrega * al final de la cola de salida * * @param instance instancia a ser convertida * @throws Execption */ protected void convertInstance(Instance instance) throws Exception { // set up values double [] instanceVals = new double[outputFormatPeek().numAttributes()]; this.removeAttributesFilter.input(instance); Instance toDiscretizeInstance = removeAttributesFilter.output(); int cluster = this.clusterer.clusterInstance(toDiscretizeInstance); for (int i = 0; i < instance.numValues(); i++) { if (i == this.attibuteToDiscretizeIndex.getIndex()) instanceVals[i] = cluster; else instanceVals[i] = instance.value(i); } push(new Instance(instance.weight(), instanceVals)); } /** * Retorna una enumeracion describiendo las opciones disponibles * * @return Enumeration con todas las opciones disponibles */ public Enumeration listOptions() {

231

Vector newVector = new Vector(2); newVector. addElement(new Option("\tFull name of clusterer to use. eg:\n" + "\t\tweka.clusterers.EM\n" + "\tAdditional options after the '--'.\n" + "\t(default: weka.clusterers.EM)", "W", 1, "-W <clusterer name>")); newVector. addElement(new Option("\tThe index of the attributte to discretize.", "I", 1,"-I <attn>")); return newVector.elements(); } /** * Resetea las opciones a sus valores default */ protected void resetOptions() throws Exception { String clustererString = weka.clusterers.EM.class.getName(); this.setDiscretizeClusterer(Clusterer.forName(clustererString,null)); this.setAttributeIndex("4"); } /** * Parsea una lista de opciones dada *  * Opciones validas: * * <pre> -W <clusterer name> * Nombre completo de la clase clusterer a utilizar. * por ej.: weka.clusterers.EM * Opciones adicionales se colocan luego de '--'. * (default: weka.clusterers.EM)</pre> * * <pre> -I <attn> * Indice del atributo a discretizar</pre> * * Las opciones luego de -- son pasadas al clusterer.  * * @param options lista de opciones como arreglo de String * @throws Exception si una opcion no se encuentra soportada */ public void setOptions(String[] options) throws Exception { this.resetOptions(); String clustererString = Utils.getOption('W', options); if (clustererString.length() > 0) this.setDiscretizeClusterer(Clusterer.forName( clustererString, Utils.partitionOptions(options))); String attributeIndex = Utils.getOption('I', options); if (attributeIndex.length() > 0 ) this.setAttributeIndex(attributeIndex); Utils.checkForRemainingOptions(options); } /** * Obtiene la configuracion actual del Filtro * * @return arreglo de String, adecuando para ser pasado a * {@link ClusterDiscretize#setOptions(String[])} */

232

public String [] getOptions() { String [] clustererOptions = new String [0]; if ((clusterer != null) && (clusterer instanceof OptionHandler)) { clustererOptions = ((OptionHandler)clusterer).getOptions(); } String [] options = new String [clustererOptions.length + 5]; int current = 0; String attributeIndex = this.getAttributeIndex(); if (!attributeIndex.equals("")) { options[current++] = "-I"; options[current++] = attributeIndex; } if (clusterer != null) { options[current++] = "-W"; options[current++] = getDiscretizeClusterer().getClass().getName(); } options[current++] = "--"; System.arraycopy(clustererOptions, 0, options, current, clustererOptions.length); current += clustererOptions.length; while (current < options.length) { options[current++] = ""; } return options; } /** * Retorna un string describiendo este Filtro * * @return descripcion del Filtro para ser * mostrada en el explorer/experimenter gui */ public String globalInfo() { return "A filter that discretize an attribute using a Clusterer. " + "It's build the clusterer using the attribute values and then assign to " + "each value the cluster's identifications."; } /** * Retorna el Clusterer utilizado para dicretizar el atributo seleccionado * * @return */ public Clusterer getDiscretizeClusterer() { return this.clusterer; } /** * Setea el Clusterer utilizado para dicretizar el atributo seleccionado * * @param clusterer */ public void setDiscretizeClusterer(Clusterer clusterer) { this.clusterer = clusterer; } /**


233

* Retorna el tip text para esta propiedad * * @return tip text de esta propiedad para ser * mostrada en el explorer/experimenter gui */ public String discretizeClustererTipText() { return "The clusterer used to discretize the selected attribute"; } /** * @return */ public String getAttributeIndex() { return this.attibuteToDiscretizeIndex.getSingleIndex(); } /** * @param index */ public void setAttributeIndex(String index) { this.attibuteToDiscretizeIndex.setSingleIndex(index); } /** * Retorna el tip text para esta propiedad * * @return tip text de esta propiedad para ser * mostrada en el explorer/experimenter gui */ public String attributeIndexTipText() { return "The attribute to discretize"; } /** * Metodo main para uso del Filtro * * @param argv argumentos del Filtro * usar -h para ayuda */ public static void main(String [] argv) { try { ClusterDiscretize clusterDiscretize = new ClusterDiscretize(); runFilter(clusterDiscretize, argv); } catch (Exception e) { e.printStackTrace(); } } } /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details.

234

* * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ package weka.filters.unsupervised.attribute; import weka.core.Attribute; import weka.core.Capabilities; import weka.core.FastVector; import weka.core.Instance; import weka.core.Instances; import weka.core.Option; import weka.core.OptionHandler; import weka.core.RelationalLocator; import weka.core.Utils; import weka.core.Capabilities.Capability; import weka.filters.Filter; import weka.filters.UnsupervisedFilter; import java.util.Enumeration; import java.util.Vector; /**  * Convierte un dataset de instancias espacio-temporales en uno de multiinstancias temporales * (según los atributos espaciales). * Se utiliza para el procesamiento de datasets espacio-temporales por el algoritmo SpatioTemporalApriori. * * * Nota: el formato de las instancias originales se supone (t, posX, posY, att_val1, ... att_valn ) * <ul> * <li>t: tiempo de registro de la transaccion. Agrupa transacciones</li> * <li>posX,posY: posiciones de los valores registrados. Agrupan los att_val registrados.</li> * <li>att_val1, ... att_valn: valores registrados en la transaccion. * Son los items propios de la transaccion. La cantidad de atributos es fija y * se determina por el formato del dataset de entrada</li> * </ul> * La ubicacion de los elementos señalados en la transaccion puede ser diferente a la indicada, siempre y cuando * se encuentren todos los elementos en la misma. * * De esta manera el formato obtenido seria: * (t,((posX1,posY1,att_val1,att_val2,..att_valn) * ,(posX2,posY2,att_val1,att_val2,..att_valn) * ... * ,(posXn,posYn,att_val1,att_val2,..att_valn))) * El mismo representa el esquema de transaccion para el algoritmo SpatioTemporalApriori. *  *  * Opciones posibles: * * <pre> -T <num> * Indice del atributo temporal</pre> * * <pre> -P<num> * Indice de los atributos de las componentes de la posicion (se da el indice * del primero, estando ambos contiguos)</pre> *

235

 * * @author Mariano Kohan ([email protected]) * @version 1.0 */ public class PropositionalToTemporalMultiSpatialInstance extends Filter implements OptionHandler, UnsupervisedFilter { /** * Indice del atributo temporal */ protected int timestampIndex=0; /** * Indice del atributo del primer componente la posicion */ protected int positionIndex=1; /** * Indices de atributos relacionales para un mismo t */ protected RelationalLocator m_SpatialRelationalAtts = null; //para un mismo t los atributos son numericos(posicion) y relacional //para un mismo t y posicion los atributos son nominales (items de las transacciones) //- forman parte de las instancias del atributo relacional /** * Retorna un string describiendo este Filtro * * @return descripcion del Filtro para ser * mostrada en el explorer/experimenter gui */ public String globalInfo() { return "Convert a dataset with spatio-temporal instances to a temporal multiinstances one " + "(considering the spatial attributes).\n"+ "It's been using in the spatio-temporal datasets procesing by the SpatioTemporalApriori algorithm. "+ "Note: the original format of the instance need to be (t ,posX, posY, att_val1, ... att_valn )\n"+ " - t: transaction time.\n"+ " - posX,posY: position of the registred values. It's group the att_val registrered.\n"+ " - att_val1, ... att_valn: registrered values in the transaction.\n"+ " They are the real transaction's items. The number of attributes is fixed "+ "and is determinated with the format of the input dataset.\n"+ "The locations of these elements can vary inside transactions, but they must have all the elements."+ "The obtained format will be:\n"+ " (t,((posX1,posY1,att_val1,att_val2,..att_valn)\n"+ " ,(posX2,posY2,att_val1,att_val2,..att_valn)\n"+ " ...\n"+ " ,(posXn,posYn,att_val1,att_val2,..att_valn)))\n\n"+ "It's represents the transaction's schema for the SpatioTemporalApriori Algorithm.\n"; } /** * Retorna una enumeracion describiendo las opciones disponibles

236

* * @return Enumeration con todas las opciones disponibles */ public Enumeration listOptions() { Vector result = new Vector(); result.addElement(new Option( "\tColumn of the temporal attribute" + "\t(default 1)", "T", 1, "-T <num>")); result.addElement(new Option( "\tColumns of the position attributes (contiguos)." + "\t(default 2)", "P", 2, "-P <num>")); return result.elements(); } /** * Parsea una lista de opciones dada *  * Opciones posibles: * * <pre> -T <num> * Indice del atributo temporal</pre> * * <pre> -P<num> * Indice de los atributos de las componentes de la posicion (se da el indice * del primero, estando ambos contiguos)</pre> *  * * @param options lista de opciones como arreglo de String * @throws Exception si una opcion no se encuentra soportada */ public void setOptions(String[] options) throws Exception { String tmpStr; tmpStr = Utils.getOption('T', options); if (tmpStr.length() != 0) this.setTimestampIndex(Integer.parseInt(tmpStr)-1); else this.setTimestampIndex(0); tmpStr = Utils.getOption('P', options); if (tmpStr.length() != 0) this.setPositionIndex(Integer.parseInt(tmpStr)-1); else this.setPositionIndex(1); } /** * Obtiene la configuracion actual del Filtro * * @return arreglo de String, adecuando para ser pasado a * {@link PropositionalToTemporalMultiSpatialInstance#setOptions(String[])} */ public String [] getOptions() { Vector result; result = new Vector();


237

result.add("-T"); result.add("" + (this.getTimestampIndex()+1)); result.add("-P"); result.add("" + (this.getPositionIndex()+1)); return (String[]) result.toArray(new String[result.size()]); } /** * @return the positionIndex */ public int getPositionIndex() { return positionIndex; } /** * @param positionIndex the positionIndex to set */ public void setPositionIndex(int positionIndex) { this.positionIndex = positionIndex; } /** * @return the timestampIndex */ public int getTimestampIndex() { return timestampIndex; } /** * @param timestampIndex the timestampIndex to set */ public void setTimestampIndex(int timestampIndex) { this.timestampIndex = timestampIndex; } /** * Retorna el tip text para esta propiedad * * @return tip text de esta propiedad para ser * mostrada en el explorer/experimenter gui */ public String timestampIndexTipText() { return "Number of the column with the temporal attribute"; } /** * Retorna el tip text para esta propiedad * * @return tip text de esta propiedad para ser * mostrada en el explorer/experimenter gui */ public String positionIndexTipText() { return "Number of the columns with the position attributes (contiguous)"; } /** * Retorna las Capabilities default del Filtro * * @return capabilities del Filtro * @see Capabilities

238

*/ public Capabilities getCapabilities() { Capabilities result = super.getCapabilities(); //esquema dataset: t,posX,posY,att1=val1,....,attn=valn // attributes - fecha + posicion geografica (numerico) + att=valor (nominal o binario) result.enable(Capability.DATE_ATTRIBUTES); result.enable(Capability.NUMERIC_ATTRIBUTES); result.enable(Capability.NOMINAL_ATTRIBUTES); result.enable(Capability.BINARY_ATTRIBUTES); // class result.enable(Capability.NO_CLASS); return result; } /** * Setea el formato de las instancia de entrada al filtro * * @param instanceInfo objeto Instances conteniendo la estructura * de las instancias de entrada al filtro (cualquier instancia contenida * en el objeto es ignorada) * @return true si el formato de salida puede ser obtenido de manera inmediata * @throws Exception si el formato de la entrada no puede ser seteado * de manera satisfactoria */ public boolean setInputFormat(Instances instanceInfo) throws Exception { if (instanceInfo.attribute(this.getTimestampIndex()).type()!= Attribute.DATE) { throw new Exception("The first attribute type of the original propositional instance dataset must be Date!"); } if ( (instanceInfo.attribute(this.getPositionIndex()).type()!= Attribute.NUMERIC) && (instanceInfo.attribute(this.getPositionIndex()+1).type()!= Attribute.NUMERIC) ) { throw new Exception("The second and thrird attribute type of the original propositional instance dataset must be Numeric!"); } super.setInputFormat(instanceInfo); /* crea nuevo formato de salida (multi-instancia) */ FastVector spAtts = new FastVector(instanceInfo.numAttributes()-1); Attribute attTimestamp = (Attribute) instanceInfo.attribute(this.getTimestampIndex()).copy(); spAtts.addElement(instanceInfo.attribute(this.getPositionIndex()).copy()); spAtts.addElement(instanceInfo.attribute(this.getPositionIndex()+1).copy()); for (int i = 0; i < instanceInfo.numAttributes(); i++) { if (!((i==this.getTimestampIndex()) || (i==this.getPositionIndex()) || (i==this.getPositionIndex()+1))) { spAtts.addElement(instanceInfo.attribute(i).copy());

239

} } Instances newData = new Instances ("spatial_items",spAtts,0); // elimina el atributo clase newData.setClassIndex(-1); FastVector attInfo = new FastVector(2); attInfo.addElement(attTimestamp); attInfo.addElement(new Attribute("spatial_items", newData)); // relation-valued attribute - items "mediciones espaciales" Instances data = new Instances("Multi-ST-Instance-Dataset", attInfo, 0); super.setOutputFormat(data.stringFreeStructure()); m_SpatialRelationalAtts = new RelationalLocator(data.attribute(1).relation()); return true; } /** * Agrega una nueva transaccion temporal a la salida * en base al instante de tiempo e instancias espaciales * dentro del mismo dados * * @param input dataset de entrada * @param output dataset de salida * @param spatialInstances instancias espaciales de la nueva transaccion * @param timestamp instante de tiempo de la nueva transaccion * @param spatialWeight peso de la nueva transaccion */ protected void addSpatialInstances(Instances input, Instances output, Instances spatialInstances, double timestamp, double spatialWeight) { // copia de valores relacionales for (int i = 0; i < spatialInstances.numInstances(); i++) { RelationalLocator.copyRelationalValues( spatialInstances.instance(i), false, input, m_InputRelAtts, spatialInstances, m_SpatialRelationalAtts); } int value = output.attribute(1).addRelation(spatialInstances); Instance newSTTr = new Instance(output.numAttributes()); newSTTr.setValue(0, timestamp); newSTTr.setValue(1, value); newSTTr.setWeight(spatialWeight); newSTTr.setDataset(output); output.add(newSTTr); } /** * Señala si finalizo el procesamiento batch del filtrado de las * instancias de entrada al filtro. * Si el filtro requiere todas las instancias previo al procesamiento, * {@link #output()} deberia ser llamado para obtener las instancias filtradas. * * @return true si quedan instancias pendientes a ser procesadas para la salida * @throws IllegalStateException si el formato de entrada no fue definido */ public boolean batchFinished()

240

{ if (getInputFormat() == null) { throw new IllegalStateException("No input instance format defined"); } Instances input = getInputFormat(); //supongo elementos ordenados por t Instances output = getOutputFormat(); Instances spatialInstances = output.attribute(1).relation(); Instance spatialInstance = new Instance(spatialInstances.numAttributes()); spatialInstance.setDataset(spatialInstances); double timestamp = input.instance(1).value(this.getTimestampIndex()); double spatialWeight = 0.0; // convertir instancia de la entrada for(int i = 0; i < input.numInstances(); i++) { double currentTimestamp = input.instance(i).value(this.getTimestampIndex()); //copio valores para instancia del atributo relacional -> posiciones + items spatialInstance.setValue(0, input.instance(i).value(this.getPositionIndex())); spatialInstance.setValue(1, input.instance(i).value(this.getPositionIndex()+1)); int k = 2; for (int j = 0; j < input.numAttributes(); j++) { if (!((j==this.getTimestampIndex()) || (j==this.getPositionIndex()) || (j==this.getPositionIndex()+1))) { spatialInstance.setValue(k, input.instance(i).value(j)); k++; } } spatialInstance.setWeight(input.instance(i).weight()); if (currentTimestamp == timestamp) { spatialInstances.add(spatialInstance); spatialWeight += spatialInstance.weight(); } else { addSpatialInstances(input, output, spatialInstances, timestamp, spatialWeight); spatialInstances = spatialInstances.stringFreeStructure(); spatialInstances.add(spatialInstance); timestamp = currentTimestamp; spatialWeight = spatialInstance.weight(); } } // se crea y se agrega la transaccion temporal multiinstancias espaciales addSpatialInstances(input, output, spatialInstances, timestamp, spatialWeight); for (int i = 0; i < output.numInstances(); i++) push(output.instance(i));


241

// liberar memoria flushInput(); m_NewBatch = true; return (numPendingOutput() != 0); } /** * Metodo main para uso del Filtro * * @param argv argumentos del Filtro * usar -h para ayuda */ public static void main(String[] args) { runFilter(new PropositionalToTemporalMultiSpatialInstance(), args); } }


242

Apéndice D. Material Digital

El DVD que acompaña a este trabajo contiene el material digital desarrollado o utilizado en el desarrollo del mismo. Su contenido se encuentra conformado por los siguientes elementos: • el documento digital de esta carpeta, ubicado en el directorio raíz de la estructura • el directorio “aplicacion”, que contiene el paquete de instalación de la aplicación

desarrollada • el directorio “datasets”, conteniendo el dataset completo sobre de transporte de gas

utilizado en los ejemplos de esta tesis • el directorio “resultados experimentación”, con los archivos producidos durante los

ejemplos de aplicación y pruebas de performance realizadas con la aplicación desarrollada -datasets procesados, parámetros de uso, resultados y archivos de log-

D.1. Dataset de ejemplo

Para los casos de ejemplo de esta tesis se manejo un dataset utilizado en el área del transporte de gas. Este dataset se encuentra dentro de una base de datos MS Access, la misma además fue migrada a una base de datos MySQL para poder utilizarse localmente con la aplicación en Linux. Dentro del material digital se incluye una copia de la base de datos MS Access y un dump de la base de datos MySQL. Para facilitar el uso de este dataset, a continuación se comentan los elementos principales de su estructura. Las tablas que componen al dataset fueron armadas en base a archivos provistos por el usuario de los datos. Estas tablas son:

Nombre Descripción / Estructura

measurements mediciones tomadas por los sensores. Armada en base al dataset principal de mediciones provisto por el usuario

(timestamp, meter_code, volume, volume_9300_kcal, energy, heating_value, diff_pressure, pressure, temperature, flow_time)

meters estaciones de medición. Armada en base a los datos de las estaciones de medición junto a sus datos geográficos. Se agrego un campo para marcar las utilizables, debido a que algunas estaciones no tenían todos los datos geográficos necesarios

(meter_code, description, latitude, longitude, height, atm_pressure, valid)

meter_measures contiene los datos propios de las estaciones de medición existentes en el dataset principal, junto con las variables medidas. Contiene valores duplicados.

(code, description, type)

Debido a que estas tablas fueron armadas en base a archivos iniciales dados por el usuario, presentan características que hace que no sea conveniente su uso de manera directa con la aplicación: contienen atributos adicionales, dividen los valores registrados respecto de los datos geográficos de los sensores que los registran, también contienen sensores sin valores


243

registrados o con datos geográficos incompletos. Por lo tanto, se deben realizar consultas SQL sobre estas tablas para obtener conjuntos de datos convenientes para el descubrimiento de las reglas de asociación. Para evitar la necesidad de escribir estas consultas cada vez que se obtienen los datos desde Weka, se han creado determinadas vistas dentro de la base de datos. De las mismas, las principales a ser utilizadas como datasets son: • mediciones_incremental_estaciones: combina las mediciones junto con los datos

geográficos de las estaciones de medición, en base a las estaciones de medición marcadas como válidas. Los registros se encuentran ordenados por fecha y estación de medición. Permite seleccionar las estaciones de medición respecto a las cuales mostrar las mediciones. Se muestran solamente los atributos utilizados en los casos de ejemplo, siendo la estructura de los registros obtenidos: (timestamp, longitude, latitude, volume_9300_kcal, heating_value, diff_pressure, pressure, temperature)

• mediciones_completas_seleccionadas: corresponde al caso anterior pero tomando las estaciones de medición con 365 mediciones registradas en el dataset. De esta manera, cada registro del dataset del modelo obtenido en base a esta consulta, correspondiente al dataset base, contiene valores registrados para todos los sensores y variables en cada uno de los instantes de tiempo. Este caso fue utilizado principalmente en las pruebas de performance. Mantiene la misma estructura, pero además permite seleccionar la fecha máxima de las mediciones a ser mostradas, respecto a la fecha de inicio del dataset.

Un Modelo de Reglas de Asociacion...

Documents

Transcript of Un Modelo de Reglas de Asociacion...