Closed AlexGonRo closed 7 years ago
Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Puesto que las mediciones presentadas esta mañana no han tenido ninguna queja, esta tarea queda cerrada.
Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Al igual que se ha mencionado en el issue #25, se adjunta un documento con los datos tomados de las mediciones tanto del algoritmo LSHIS como del algoritmo DemoIS
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.
Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Aunque la tarea lleva pospuesta un tiempo, no sabía que podía marcarse como tal. Hasta que se terminen las labores de modificación del algoritmo y la clase lanzadora, esta tarea queda en espera.
Original comment by Álvar Arnaiz (Bitbucket: alvarag, GitHub: alvarag):
Podemos tratar de mejorar el código de Spark según las recomendaciones de los "chicos" de databricks http://es.slideshare.net/databricks/strata-sj-everyday-im-shuffling-tips-for-writing-better-spark-programs
Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Ninguno de los dos algoritmos ofrece buenos resultados en cuanto a tiempo se refiere
Original comment by Álvar Arnaiz (Bitbucket: alvarag, GitHub: alvarag):
¿Solamente hay problemas de tiempo con el DemoIS? ¿O también con el LSH? La paralelización que se consigue con el DemoIS, al igual que con el LSH, debería ser bastante destacable puesto que la implementación map-reduce es aprovechada al máximo. El lunes por la mañana podemos quedar sin problemas.
Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Escribo este mensaje también en referencia al issue #25 (Testéo de las salidas del algoritmo DemoIS) para evitar duplicar un mismo tema.
He estado realizando pruebas de rendimiento, tanto sobre Weka como sobre DemoIS y si bien parece que solucionamos los problemas con el porcentaje de acierto en test, el tiempo de ejecución de Spark con respecto a Weka me parece seriamente preocupante, siendo en Spark mucho mayor y sin previsión de que la diferencia de tiempo se reduzca al aumentar el número de instancias.
Pensé que era un aspecto solucionado, ciertamente se ha reducido el tiempo a 1/3 de lo que mostraban las pruebas anteriores sobre LSHIS, pero el problema persiste y me parece bastante importante dado el hecho de que no parece reducirse el tiempo de ejecución con Weka a medida que metemos carga de trabajo.
He estado analizando las operaciones en la herramienta de Spark que mostré en su momento en una de nuestras reuniones. Veo el problema en la manera en la que se ha planteado la implementación de los algoritmos: la inmutabilidad de las RDD y la necesidad que tenemos de jugar y retocar las "key" que asignamos a las instancias (tanto en LSHIS como en DemoIS) parece que ocasionan mucho más trabajo del esperado. Esto es todavía una suposición sobre la que tengo que seguir indagando pero de momento parece lo más probable.
Se agradecería saber vuestra opinión sobre este aspecto. Por mi parte veo prudente cancelar las pruebas de momento, esperar vuestras respuestas, y pensar en alguna solución al problema que no obligue a modificar el planteamiento inicial de los algoritmos porque eso nos podría echar para atrás muchisimo trabajo. Sé que este tema ya se trató en su momento y se le asignó una prioridad baja con respecto a otras tareas, es precisamente lo que voy a hacer yo de momento. Voy a trabajar sobre otros aspectos del proyeco que todavía siguien pendientes y si me surge alguna idea que tenga un coste bajo, intentaré ver que tal funciona.
Dado este problema y que el tiempo con el que contaba era poco, es probable que plantee mi presentación del proyecto para el mes de Febrero, aunque como he dicho esta mañana tomaré mi decisión final después del fin de semana. Es probable que vuelva el lunes a hablar con Álvar si está disponible.
Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Título modificado
Original comment by Álvar Arnaiz (Bitbucket: alvarag, GitHub: alvarag):
¿Cómo ejecutar un experimento en Weka? java -Xmx1024m -cp weka.jar:instanceselection.jar weka.experiment.Experiment -l /home/alvarag/experimento.xml -r
El nombre del meta-clasificador es ISFilteredClassifier:
Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Adjunto una foto con los datos obtenidos hasta ahora en la comparación, para poder comentarlos durante la reunión de hoy
Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Actualizados los objetivos de esta tarea
Original comment by Álvar Arnaiz (Bitbucket: alvarag, GitHub: alvarag):
Se me pasó contestarte ayer, perdona. Envié un e-mail al investigador de Granada que está con el tema del kNN y su respuesta fue que no lo tiene todavía publicado porque está haciendo modificaciones. La verdad es que me preocupa que no tengamos este método, su respuesta daba a entender que tardaría todavía un tiempo su publicación. Por el momento yo dejaría parada esta tarea con la intención de evitar hacer dos veces lo mismo.
Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
En la reunión del spring hablamos sobre realizar esta comparativa entre Weka-Spark con el algoritmo KNN en lugar del bayesiano.
Dado que Spark no cuenta con una implementación y que Álvar no ha comentado nada, supongo que no contamos con el algoritmo.
Si no me equivoco, el KNN lo vamos a necesitar más adelante para la implementación del algoritmo Democratic IS asÍ que tarde o temprano tendré que implementarlo.
Simplemente querría aclarar este aspecto de cara a la comparación, pues podríamos considerar posponerla hasta contar con una implementación del KNN
Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):
Tarea asociada a milestone.
Originally reported by: Álvar Arnaiz (Bitbucket: alvarag, GitHub: alvarag)
Utilizar conjunto de datos de Issue #11
Añadir nuevos conjuntos de datos de aplicaciones de ingeniería del software
Comparar utilizando el conjunto reducido con el clasificador KNN