Mejoras sobre el código del proyecto

[AlexGonRo]

Originally reported by: Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown)

---

Se van a realizar diferentes mejoras que afectan al código del algoritmo LSH-IS y a la clase "main" encargada de lanzar los algoritmos de selección de instancias. Estas mejoras serán las siguientes:

• Mejoras propuestas por Carlos López en Issue #14

• Refactorización del código existente

• Mejoras a la hora de leer los datos y salvar los resultados

• Posibilidad de elegir el algoritmo de selección de instancias al lanzar el programa.

La descripción detallada de las modificaciones se indicará más abajo a medida que se vayan implementando.

---

• Bitbucket: https://bitbucket.org/agr00095/tfg-alg.-seleccion-instancias-spark/issue/23

[AlexGonRo]

Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):

---

Sobre el commit 0c97193:

Finalmente se ha solucionado el tema de las clases privadas y su serialización. Ahora solo hay una clase privada llamada "ANDsTable", que equivaldría a la antigua "HashTable" y que cuenta con una inner class que es la "EuclideanHash"

Se han llevado a cabo algunas labores de refactorización del código. Esto está también relacionado con el issue #22 y no creo que sea necesario detallar todos los cambios.

El pom ha sido ligeramente modificado para que, a la hora de construir el jar no tengamos problemas con las dependencias.

Este issue queda abierto hasta el lunes-martes por si alguien quiere comentar algo

[AlexGonRo]

Original comment by Carlos López (Bitbucket: clopezno, GitHub: clopezno):

---

Respecto a la serailzación me parece adecuada el uso de transient para controlar la serialización.

[AlexGonRo]

Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):

---

Comentarios sobre el commit 9ad4bbf

Se han mejorado los siguientes aspectos:

1. Ligeros cambios en el POM(descripción del proyecto, nombre, etc). También ha sido añadida una referencia al proyecto reflections que he tenido que usar para añadir nueva funcionalidad.

2. Añadida una clase para realizar la lectura de conjuntos de datos. Al contrario que lo que teníamos antes, ahora este lector cuenta con una clase que puede leer archivos CSV con cabecera (aunque la operación es bastante costosa) y permite indicar si el atributo de clase es el primero o el último de los atributos. Estuve tratando con los atributos nominales pero de momento todavía no los soportamos bien.

3. Ahora podemos elegir el algoritmo de selección de instancias en tiempo de ejecución. Para poder hacer esto el algoritmo ha de cumplir una serie de requisitos: heredar de AbstractIS.scala, implementar el constructor mínimo al que obliga AbstractIS(constructor con un argumento de tipo Array[String]) y estar incluido en el classpath (para que podamos encontrarlo). EDITADO: Pequeña corrección en el nuevo commit a876003: A causa de cambiar el constructor varias veces estos días se me había olvidado ponerlo de manera correcta aunque el programa funcionase sin problema.

4. La salida del resultado es mucho mejor. Se genera un único fichero con un nombre único que contiene tanto los argumentos con los que se ha ejecutado el algoritmo como el resultado final.

5. La clase main.scala ha sido cambiada y ahora solo instancia lo que necesita y deja la lógica para otras clases. Esto entra más en el aspecto de refactorización.

IMPORTANTE

Ahora si queremos ejecutar el programa tenemos que hacerlo de manera diferente. Los argumentos a pasar al programa son:

NombreAlgoritmo RutaDataSet (OpcionesLector) OpcionesIS

Donde:

• NombreAlgoritmo es el nombre de la clase que contiene el algoritmo que vamos a usar

• rutaDataSet es la ruta al conjunto de datos

• OpcionesLector son las opciones a pasar al método que lee el conjunto de datos. Contiene opciones por defecto así que salvo que el fichero contenga alguna singularidad, no serán necesarios.

• OpcionesIS Opciones a pasar al algoritmo de selección de instancias

---

Remarcar también que, como ya hice en versiones anteriores, main.scala tiene un par de lineas que sirven para ejecutar el programa directamente desde Eclipse. No están comentadas porque me supongo que en caso de querer ver como funciona el programa es mucho más fácil hacerlo desde Eclipse. Recordar que si queréis empaquetarlo en un .jar y lanzarlo desde Spark tenéis que comentar esas lineas y descomentar la siguiente. NO PRODUCE ERROR SI NO LO HACEIS pero no va a permitiros eleguir las opciones de Spark para lanzarlo (más bien las va a ignorar)

[AlexGonRo]

Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):

---

Ignorando el problema que tenemos planteado con la distribución de las clases para el algoritmo LSHIS, el commit e2bdc8d ha introducido algunas nuevas mejoras:

• Se ha refactorizado el código, aunque falta trabajo por hacer. En especial, el nombre de variables, métodos y las salidas por pantalla están en inglés. Los comentarios, en cambio, se mantienen en español para una mejor comprensión a la hora de evaluar el proyecto

• Ahora tanto la clase abstracta como su implementación en LSHIS.scala cuentan con un nuevo método para proporcionar más información sobre el uso de los parámetros de entrada en caso de ser introducidos erroneamente. Acabo de darme cuenta de que el método debería ser "protected" y será corregido para el siguiente commit.

• AbstractIS.scala ha pasado de ser una "clase abstracta" a ser un "trait". No estoy completamente seguro de este cambio porque tal vez tenga inconvenientes en una mejora que introduciré estos próximos días. Por lo tanto, este cambio no es definitivo.

• La manera en la que se tratan los atributos de entrada al instanciar el algoritmo ha sido mejorada (la dimensión del conjunto de datos se calcula sola, no se admiten valoes de AND u OR inválidos, etc)

[AlexGonRo]

Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):

---

He estado trabajando sobre la implementación de las inner class de la manera que Carlos propuso y parece que sigue obligándome a declarar la clase principal serializable (LSHIS.scala, la clase que contiene el algoritmo).

He continuado indagando sobre el tema (viendo tanto información sobre Scala como sobre Java) y lo único que he encontrado como otra posible solución es el uso de la palabra clave transient (es la misma palabra y se usa de manera muy similar tanto en Scala como en Java). Se podría hacer la trampa de declarar serializable la clase LSHIS.scala y posteriormente, mediante el uso de la palabra transient, solo marcar como atributos para serializar aquellos que nos interesan.

Desconozco que efectos puede tener esta implementación de cara a como se serializa el objeto, igual no estamos ganando demasiado.

Como es puente y tengo que seguir trabajando sobre el TFG, seguiré subiendo mejoras en la implementación que ya tengo definidas, dejando este tema apartado hasta que decidamos como implementarlo.

[AlexGonRo]

Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):

---

Con respecto a mi primer comentario:

1. Exactamente, estaba hablando de incluir las dos clases como innerclass

2. Hashtable no es realmente el nombre de la clase, se me ha colado ahí por equivocación.

DIcho esto, intentaré implementar la solución que planteas aplicando interfaces, creo que no debería haber ningún problema con eso.

Una clase estática pura no tiene sentido en este contexto, por eso mencioné en el mensaje anterior que la solución me parecía bastante mala.

[AlexGonRo]

Original comment by Carlos López (Bitbucket: clopezno, GitHub: clopezno):

---

ATENCIÓN CON EL NOMBRE HASHTABLE

Alejandro no sé si veo tu duda. Cuando comentas" ... HashTable como EuclideanDistance podrían incluirse dentro de LSHIS"o ¿con dentro te refieres a innerclass?

Si este es el caso quizás puedes aplicar la misma solución que Java con los iteradores. Crea dos interface públicas que extiendan de serializable (HashTableIF y EuclideanDistanceIF). Luego implementa las innerclases implementado esas interface.

Una clase estática pura tiene sentido en diseño sólo cuando existe una única instancia de la clase en el sistema. Evidentemente todos sus métodos tienen que ser estáticos. ¿Es el caso de HashTable y EuclideanDistance?

[AlexGonRo]

Original comment by Alejandro González Rogel (Bitbucket: agr00095, GitHub: Unknown):

---

Tengo una pregunta sobre uno de los temas tratados durante la reunión del último spring.

Ahora mismo tenemos tres clases para el algoritmo LSHIS:

• LSHIS (no es serializable)
• HashTable y EuclideanDistance (que necesitamos que sean serializables)

Mencionamos que tanto HashTable como EuclideanDistance podrían incluirse dentro de LSHIS. He estado implementándolo y realmente veo el problema de que, de esta manera, o hacemos las clases HashTable y EuclideanDistance estáticas o tenemos que serializar todo LSHIS.

Realmente la opción de hacer clases estáticas no creo que sea buena y serializar también el algoritmo no se si me convence mucho. Creo que podríamos crear una clase serializable que juntase HashTable y EuclideanHash, simplificando de esta manera comentarios y código.

No se realmente si pensasteis en esto al mencionarlo durante la reunión del spring, yo no, y por eso me gustaría preguntarlo. Yo he conseguido implementar el algoritmo de manera que se distribuya toda la clase LSHIS.