Escribir el procedimiento experimental y redescribir los métodos probados about 2015-evostar

[unintendedbear]

Ok pues me quedo pendiente :)

[JJ]

Reescribirlo de acuerdo con lo escrito en #13 por @deantares Asigno a @amorag, que escribió la versión origina. en vista de que @deantares no lo hace por mucho CRITICAL que lleva.

[deantares]

Estoy en ello joooooooo 😭

Más CRITICAL es lanzarlo (que es lo que estoy ajustando ahora mismo) y mientras está lanzado ya lo escribo...

[JJ]

Escríbelo que las cosas en caliente pegan.

[JJ]

Te reasigno.

[JJ]

Alguno de vosotros, @amorag o @deantares , ¿lo va a hacer de una vez? Lleva siendo urgente desde hace una semana... que es sólo reescribir lo que hay poniendo la descripción real de los experimentos, coñe.

[amorag]

Sip, lo voy a hacer yo.

Pero todavía no sabemos los valores reales que se utilizarán.

Antares está haciendo pruebas.

En todo caso intentaré mejorar/completar las descripciones actuales. ;)

De: Juan Julián Merelo Guervós [mailto:[email protected]]
Enviado el: miércoles, 5 de noviembre de 2014 12:58
Para: geneura-papers/2015-Evostar
CC: Antonio Mora
Asunto: Re: [2015-Evostar] Escribir el procedimiento experimental y redescribir los métodos probados (#14)

Alguno de vosotros, @amorag https://github.com/amorag o @deantares https://github.com/deantares , ¿lo va a hacer de una vez? Lleva siendo urgente desde hace una semana... que es sólo reescribir lo que hay poniendo la descripción real de los experimentos, coñe.

—
Reply to this email directly or view it on GitHub #14 (comment) . https://github.com/notifications/beacon/AC6-Ws0h55RWParu9I8Do30Ch7nUim9-ks5nKggzgaJpZM4C1Tru.gif

No se encontraron virus en este mensaje.
Comprobado por AVG - www.avg.com
Versión: 2013.0.3485 / Base de datos de virus: 4189/8513 - Fecha de publicación: 11/05/14

[amorag]

Hecho, aunque veía del Issue #10, no del #13. ;)

Yo metería una tabla de resumen de criterios y valores, por claridad para el lector.

[deantares]

Por contar como va la cosa, todavía no han terminado (todas) las ejecuciones del algoritmo, pero ya tengo preparada la parte de script para el análisis de los resultados. Os dejo algunos resultados parciales por si se os ocurre alguna cosa más a mirar:

Evolución del fitness de la población en una ejecución concreta del algoritmo

Correspondencia entre el tiempo de ejecución del algoritmo y el número de generaciónnnnnnn

Boxplot de SCORE alcanzado por el mejor individuo según cada método de parada en todas las ejecuciones del algoritmo

Boxplot de GENERACIONES necesarias para el mejor individuo según cada método de parada en todas las ejecuciones del algoritmo

Comparativa

[JJ]

Vale. La del tiempo por generación no sirve de nada. El resto, veo un
incremente muy lento del fitness según aumenta el número de generaciones.
Age of Outliers es prácticamente inútil. Y FT sólo es úitl si efectivamente
sabes algo dle fitness (en el caso de Made, por ejemplo, no lo sabemos)
Usa como base NG_030 y compara el número de generaciones necesarias para
conseguir una unidad adicional de fitness.

[JJ]

No entiendo muy bien por qué FT obtiene mejores resultados. Me parece que
la comparación que estáis haciendo no es justa. ¿Qué fitness ponéis en FT y
en el resto? Igual que NG. El fitness sólo puede depender del número de
generaciones, porque todas las ejecuciones se hacen a la vez, ¿no?
OK, ya me ha explicado @amorag que el score no es el fitness, sino una evaluación externa. Y en todo caso es media, o sea que sí podría ser que variara si no se distribuyen las generaciones necesarias según un límite central.

[JJ]

Por favor, incluye tamtién en el repo el código R para generar los gráficos y .RData y RHistory

[amorag]

Lo que le he dicho a @JJ es lo que he supuesto, que los resultados del score muestran la puntuación obtenida por cada mejor individuo al evaluarlo de forma 'externa' contra otros rivales, ¿no?

¿La última gráfica muestra resultados medios o el mejor que se ha obtenido en cada caso?

Me ha encantado la de Generaciones/Tiempo. XD

[deantares]

Todas las condiciones de parada tienen el mismo fitness. Y todas las evaluaciones se hacen a la vez.

Sobre FT el problema es que hay muchas ejecuciones en la que no está llegando a ese valor umbral y está tomando una infinidad de generaciones adicionales (casi el doble) en las que si lo está haciendo. La cuestión es que para un incremento del fitness de un punto, es necesaria una gran cantidad de generaciones adicionales del algoritmo, doblando casi el tiempo necesario.

Sobre poner los .R en el repo, okis 😊

De todos modos, son resultados parciales ya que aún no han terminado todas las ejecuciones. En cuanto terminen vuelvo a generarlas.

Un saludote.

[JJ]

Pero esas ejecuciones también las has metido, ¿no?

¿Cuál es el máximo de generaciones?

[deantares]

Máximo de generaciones: 500. Si a las 500 no ha "terminado" un criterio de parada, se concluye el algoritmo. Para no tenerlo de por vida ejecutándose...

Si, he metido todas las ejecuciones tanto las terminadas como las que están en proceso para ir preparando los scripts y viendo como van la experimentación.

[JJ]

Con todo y con eso, FT tiene los mejores resultados, ¿no?

[amorag]

Entonces ok.

En la última gráfica:
Lo que me despista son las 'oscilaciones' que se producen con los resultados de los FT, ya que siempre mejoran a otros resultados obtenidos posteriormente (en la misma ejecución):
FT_20 mejora a NG_100 RT_0,125, FT_22 mejora a NG_200 y RT_0,0625...

Es un poco sospechoso que pase siempre con los resultados de FT.
Comprueba que estén bien, plis. ;)

Ahm, @JJ me dice que son resultados medios de todas las ejecuciones, ¿es así?
En ese caso puede pasar, pero sigue siendo un poco sospechoso, ¿no?