Closed AlexGonRo closed 7 years ago
AlexGonRo
commented
8 years ago Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Las mediciones ya han sido realizadas , mostrando resultados buenos, por lo que se considera esta tarea acabada.
AlexGonRo
commented
8 years ago Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Sobre el commit 287a2a3
Modificado el nivel de persistencia de algunas de las RDD dentro del algoritmo. Con los casos utilizados no tiene demasiada importancia (ligera disminución del tiempo de ejecución) pero cobra más importancia al ejecutar el algoritmo con varias funciones OR y debería hacerlo también cuanto más grande sea el conjunto de datos utilizado.
En el commit que han quedado un par de lineas que asignan nombre a las RDD. Esto no tiene ninguna importancia en el flujo del programa, simplemente ayuda a visualizar mejor la gestión de recursos.
AlexGonRo
commented
8 years ago Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Sobre el commit 3083653 (Este mensaje se encuentra repetido en el issue #27)
Modificadas algunas de las operaciones del algoritmo para conseguir una más rápida ejecución. La mejora tanto en DemoIS como en LSHIS parece bastante buena, con reducciones de tiempo del 50% en los casos medidos. Todo ello se ha conseguido reduciendo la carga de datos que se cargaban en disco.
La tarea necesita algo más de trabajo, tanto de cara a replantear nuevas posibilidades como a intentar mejorar la eficiencia de las acciones ya existentes.
AlexGonRo
commented
8 years ago Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Reabierto para tratar los problemas de rendimiento de los que sufre el algoritmo.
AlexGonRo
commented
8 years ago Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Sobre el commit 7dc5d16 en lo referente a este tema.
Tras la reunión con Álvar esta mañana parece que hemos aceptado que hay un funcionamiento erroneo de Weka cuando tiene que operar con más de una función OR, probablemente causa de haber modificado el código el algún momento. El funcionamiento de ambas implementaciones con solo una función OR es el esperado y, dado que el mejor resultado esperado es precisamente con una función OR y sobre ello se van a realizar las mediciones, no vamos a tener problema en este sentido.
Se han realizado las siguientes modificaciones:
Añadida la función Array.hashCode para calcular el HASH de las ANDsTable, tal y como lo hace Weka, que fué añadida durante el proceso y que la mantengo para garantizar que sea exactamente la misma que usa Weka.
Spark ahora toma numAtributos+1 para realizar las tablas AND, a sugerencia de Álvar. Esta opción no está implementada en Weka y, por lo tanto, ambas implementaciones darán un resultado ligeramente diferente. Puedo asegurar con toda probabilidad que las implementaciones de Weka y Spark son idénticas a excepción de este aspecto, por lo tanto sirve como justificación si, a la hora de comparar, encontramos una ligera diferencia en el número de clases seleccionadas.
Añadidos aspectos relacionados con la interfaz gráfica que no se tratarán en este issue.
Dejaré la tarea abierta por si alguien quisiese comentar algo. En caso contrario se cerrará mañana.
AlexGonRo
commented
8 years ago Original comment by Álvar Arnaiz (Bitbucket: alvarag, GitHub: alvarag):
Muy interesantes tus conclusiones y, como bien indicas, es mejor tratarlo en una reunión que por aquí. Si quieres podemos hacer una reunión el lunes 27 presencial u on-line para tratar el tema.
Me alegro de que se haya encontrado el punto de inflexión a partir del cual Spark supera a Weka en tiempo de ejecución, puesto que son conclusiones que incluir en tu memoria.
Felices fiestas.
AlexGonRo
commented
8 years ago Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Despues de muchisimas horas trabajadas sobre este tema y a riesgo de pasarme tres pueblos, creo tener pruebas para sostener que la implementación de Weka no trabaja bien con las funciones OR.
Creo que es un tema complicado como para debatirlo mediante este sistema asi que me gustaría discutirlo bien en persona o ,si no se puede, por Skype.
Aprovecho a decir, en referencia al tiempo de ejecución, que tras varios experimentos y correcciones puedo decir que Spark trabaja más rápido que Weka a partir del conjunto de datos Poker, en contraste a los malos datos que presenté en el spring. Es un tema que desarrollaré una vez termine con las correcciones OR.
Felices fiestas y buena noche
AlexGonRo
commented
8 years ago Original comment by Álvar Arnaiz (Bitbucket: alvarag, GitHub: alvarag):
Prueba siempre con 10 funciones AND que suele ser el que mejores resultados ofrece.
Que con más funciones OR aumente el número de instancias es normal, porque estamos seleccionando más instancias. Pero este número debería ser igual (o similar al menos) que el número de instancias seleccionado por Weka.
AlexGonRo
commented
8 years ago Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Sobre el commit 8e5acc7
Arreglado el error con el número de atributos pasábamos a la HashTable (ahora usamos todos los atributos + atributo de clase).
Sin embargo, el error al clasificar sigue persistiendo, el resultado final no ha cambiado significativamente.
No creo que el error esté en la lógica del algoritmo, sino en el cálculo de los buckets. Revisaré el método de hashcode de la lista indexada y compararé con el código de Weka por si algún paso es diferente.
Sobre los resultados de los algoritmos en función del número de OR que tengamos, pongo aquí el número de instancias de Poker y Covertype tras aplicar el algoritmo:
OR=1 OR=2 OR=3 EsperadoPoker 4954 7545 13565 ~3800
Covtype 2118 3987 4300 2000-3000
Las pruebas se han ejecutado con 4 funciones-Y, así que el número de instancias final tiene variaciones considerables dependiendo del valor aleatorio (500 o hasta 1000 instancias en Covertype)
Como se ve en los resultados Poker parece incrementar cada OR un número más o menos fijo de instancias, pero es algo que no pasa en Covertype. Poker es más complicado, tal vez sea por eso, pero en cualquiera de los casos no resuelve el problema.
Revisaré todo lo que tenga que ver con el cálculo del Hash como siguiente tarea.
IMPORTANTE: Esta última modificación del código ha reducido el tiempo de ejecución del algoritmo SUSTANCIALMENTE. Mientras que Covertype, por ejemplo, ejecutaba en 25 segundos en todos los casos, ahora tarda 15. EDITADO La diferencia fundamental entre las ejecuciones anteriores (25 segundos) y la actual (15) es que para mis mediciones anteriores ejecuté en modo Standalone mientras que, por confusión, ahora lo he hecho en modo local al dejar el código de eclipse sin comentar. Va a ser un dato importante si finalmente tocamos este tema.
AlexGonRo
commented
8 years ago Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
En referencia a lo que acaba de comentar Álvar y las experimentaciones que estoy haciendo.
He chequeado el problema de la "doble normalización" que realizabamos en Weka, pero obviamente no hay diferencia entre realizar de nuevo la normalización o no porque esta normalización se realiza en el KNN, no cuando estamos aplicando el filtro.
Voy a realizar las modificaciones en mi código que hemos propuesto esta mañana, donde las tablas Hash AND deben tener un tamaño de nº de atributos + 1(atributo de clase). Dado que esto afecta a todos los pasos del algoritmo, y lo que he mencionado en mi anterior mensaje, creo que podría ser un punto a evaluar cuanto antes.
Si pese a esto no conseguimos un buen resultado, realizo unas pruebas y subo los datos de salida que menciona Álvar.
AlexGonRo
commented
8 years ago Original comment by Álvar Arnaiz (Bitbucket: alvarag, GitHub: alvarag):
Veo que estás siguiendo los pasos que hemos comentado esta mañana y hemos descartado la implementación del kNN como fuente del error. Para que podamos ver los resultados sería interesante que hicieses una tabla (no hace falta en latex, puede ser en texto aqui) para que podamos ver cómo aumenta el número de instancias almacenadas a medida que aumenta el número de funciones OR, ej: 1, 2 y 4. 10 AND. Si con una función OR tenemos ya diferencias, habrá que revisar la propia función AND. Igual el problema lo estamos teniendo en la generación de los vectores aleatorios sobre los que se proyecta. Mañana estaré toda la mañana por el despacho por si quieres comentar algo.
AlexGonRo
commented
8 years ago Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Sobre este aspecto he empezado analizando el comportamiento de mi implementación del KNN, en caso de que fuese errónea.
He descargado y normalizado los siguientes conjuntos de datos:
El resultado producido por mi KNN es similar al que ofrece el IBk, la precisión apenas cambia un 0,15% en el peor de los casos (en validación cruzada 10), así que descarto este problema como posible causa de los malos resultados.
He realizado diferentes experimentos modificando el número de funciones-OR del algoritmo. El problema no parece venir de aquí tampoco, por lo menos no en el sentido de que aplicar las funciones-OR duplica el conjunto de datos de salida. Sin embargo si que se observa una diferencia significativa en las instancias que se seleccionan por cada iteración, siendo en cada iteración de Spark mayor que en Weka.
El siguiente paso será el análisis de los conjuntos de datos de nuevo con Weka, puesto que me Álvar ha mencionado que la clase "EuclideanDistance" (usada en LinnearNNSearch, que a su vez se usa en IBk) normaliza los datos por defecto, algo que no deberíamos repetir porque los datos se normalizan antes de ser pasados al clasificador.
Originally reported by: Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown)
En vista a los resultados que proporciona este algoritmo se ve necesario un análisis de su implementación y la realización de cambios cuando sea necesario.
Como principales puntos a revisar están el tamaño del conjunto de datos resultante y la precisión que podemos alcanzar con el conjunto de datos obtenido.