[Made] Lanzar los experimentos YA

[fergunet]

@raiben tienes que lanzar lo siguiente:

Criterio de parada: la media de la población se acerca al mejor individuo (con un umbral). Esto quiere decir que se ha estancado. Imprimir tiempos por pantalla porque los usaremos para comparar!

Fitness:

• Tres funciones fitness F (o escenarios): una con un arquetipo, otra con 2 y otra con 5. (usando lo de low, many, etc.)
• Tres números de perfiles P: 1, 2, 4 y 8
  (recordemos que el fitness se ejecuta 5 veces cada vez y se saca la media)

Mundo: Número de días D: 128, 256, 512

Algoritmo genético: población de tamaño S: 64, 128, 256

O sea, 3x3x3x3 combinaciones. Saca los logs de la forma run_[1-30]F[1-3]P[1,2,4]D[128,256,512]S[64,128,256].log (mete fors en el script)

Te daré acceso al cluster bioatc.ugr.es para que lances en paralelo.

[amorag]

Entiendo que las métricas entonces las aplicaréis a posteriori, ¿verdad?

El problema de eso es que en base a los resultados de las métricas podría ser adecuado cambiar la parametrización del algoritmo para obtener mejores individuos, ¿no?

[fergunet]

@amorag No vamos a usar las métricas de interés en este paper, porque habría que programarlas y no va a dar tiempo, así que vamos a lanzar un montón de parámetros distintos con el criterio de parada igual para todos (convergencia) y ver su efecto en el mundo generado. Mira el issue #13

Edit: este es el issue #13... estoy idiota...

[amorag]

Ok.

De: Pablo García Sánchez [mailto:notifications@github.com]
Enviado el: martes, 28 de octubre de 2014 14:23
Para: geneura-papers/2015-Evostar
CC: Antonio Mora
Asunto: Re: [2015-Evostar] [Made] Lanzar los experimentos YA (#13)

@amorag https://github.com/amorag No vamos a usar las métricas de interés en este paper, porque habría que programarlas y no va a dar tiempo, así que vamos a lanzar un montón de parámetros distintos con el criterio de parada igual para todos (convergencia) y ver su efecto en el mundo generado. Mira el issue #12 #12 al final del todo

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

No se encontraron virus en este mensaje.
Comprobado por AVG - www.avg.com
Versión: 2013.0.3485 / Base de datos de virus: 4031/8468 - Fecha de publicación: 10/28/14

---

No se encontraron virus en este mensaje.
Comprobado por AVG - www.avg.com
Versión: 2013.0.3485 / Base de datos de virus: 4031/8441 - Fecha de publicación: 10/23/14

[rhgarcia]

Hola,
La idea es que al lanzar la aplicación en consola, ella sola genere las 30x3x3x4x3 (=3240) ejecuciones. ¿no?
Supongo que el cluster ya estará configurado para paralelizar y tal...
Estoy preparándolo todo...

[JJ]

Puedes hacer varias ejecuciones, no tiene que hacerse todo del tirón...
mejor así, incluso.

JJ

[fergunet]

@raiben no, el cluster no paraleliza automáticamente. Tienes que hacer ssh pepito@bioatc.ugr.es (entras en el nodo local) y luego ssh compute-0-X para entrar a uno de los nodos disponibles y en cada nodo ejecutas una porción. Empieza dejando algunos parámetros fijos y conforme vayan terminando ejecutas los siguientes.

Ojo con los logs, que cada nodo comparte sistema de archivos!

Aquí tienes la carga del cluster en tiempo real, por si quieres ver los nodos disponibles http://bioatc.ugr.es/ganglia/

[rhgarcia]

Otra pregunta:

¿Qué hago con el resto de parámetros?

Por un lado tengo parámetros del mundo, que afectan a los resultados y no
están modulados por el cromosoma.
Por otro lado tengo valores base de los agentes que sí están modulados por
el cromosoma: cada uno de esos valores se multiplicará por un gen
representado por un real entre 0 y 1.

Del mundo:
txtFoodPerDay=10 // raciones de comida al día
txtMapGridDimension=10 // dimensión del mapa
txtNumberOfInitialAgents=15 // nº de agentes distribuidos aleatoriamente
en el mapa al principio

De los agentes:
txtBaseAgeToBeAdultFemale=42 // días que tarda una rata hembra en
convertirse en adulta
txtBaseAgeToBeAdultMale=49 // días que tarda una rata macho en convertirse en adulta
txtBaseBite=5 // daño máximo que puede causar una rata por mordisco (se comparará con la defensa de su contrincante)
txtBaseEnergy=5 // puntos de energía máxima que puede tener una rata
txtBaseFur=5 // defensa máxima de una rata ante un mordisco (se comparará con el ataque de su contrincante)
txtBaseLifeInDays=200 // vida máxima en días de una rata
txtBaseNutrition=4 // puntos máximos de energía que aporta una ración de
comida
txtbasePregnancyDays=30 // días máximos para la gestación
txtBaseSmell=3 // nº máximo de cuadros de distancia para detectar comida

Personalmente, dejaría fijos los parámetros base del agente, pero
analizaría los del mundo. ¿Qué opináis?

2014-10-29 17:29 GMT+01:00 Pablo García Sánchez notifications@github.com:

@raiben https://github.com/raiben no, el cluster no paraleliza
automáticamente. Tienes que hacer ssh pgarcia@bioatc.ugr.es
pgarcia@bioatc.ugr.es (entras en el nodo local) y luego ssh
compute-0-X para entrar a uno de los nodos disponibles y en cada nodo
ejecutas una porción. Empieza dejando algunos parámetros fijos y conforme
vayan terminando ejecutas los siguientes.

Ojo con los logs, que cada nodo comparte sistema de archivos!

Aquí tienes la carga del cluster en tiempo real, por si quieres ver los
nodos disponibles http://bioatc.ugr.es/ganglia/

—
Reply to this email directly or view it on GitHub
#13 (comment)
.

[JJ]

¿Qué hago con el resto de parámetros?

Usa valores "razonables". En cualquier caso, mantenlos fijos. Sería
interesante, más adelante, plantear un análisis de sensibilidad de todos
los parámetros, pero parece que, razonablemente, esos son los que tienen
más influencia en el resultado. Si acaso puedes hacer algúna exploración
inicial variándolos y quedándote con algún valor.

Por un lado tengo parámetros del mundo, que afectan a los resultados y no
están modulados por el cromosoma.
Por otro lado tengo valores base de los agentes que sí están modulados por
el cromosoma: cada uno de esos valores se multiplicará por un gen
representado por un real entre 0 y 1.

Del mundo:
txtFoodPerDay=10 // raciones de comida al día
txtMapGridDimension=10 // dimensión del mapa
txtNumberOfInitialAgents=15 // nº de agentes distribuidos aleatoriamente
en el mapa al principio

Lo dicho. Busca valores razonables y fijos. Aunque, pensándolo bien,
algunos de estos valores deberían de formar parte también del "diseño" del
mundo. No va a ser igual un mundo con mucha que con poca comida. Desde
luego, eso hay que comentarlo, porque ahora mismo el diseño de la atmósfera
va todo a la función fitness, y se me ocurre que en un mundo superpoblado
habría que tocar el último y en un mundo con guerra el primero. Quizás el
segundo, no tanto...

De los agentes:
txtBaseAgeToBeAdultFemale=42 // días que tarda una rata hembra en
convertirse en adulta
txtBaseAgeToBeAdultMale=49 // días que tarda una rata
txtBaseBite=5 // puntos de daño máximo que puede causar una rata por
mordisco
txtBaseEnergy=5 // puntos de energía máxima que puede tener una rata
txtBaseFur=5 // puntos de defensa máxima
txtBaseLifeInDays=200 // vida máxima en días de una rata
txtBaseNutrition=4 // puntos máximos de energía que aporta una ración de
comida
txtbasePregnancyDays=30 // días máximos para la gestación

Joder, se tarda casi tanto en convertirse en adulto como en parir. ¿En
serio que esto merece la pena meterle un parámetro?

txtBaseSmell=3 // nº máximo de cuadros de distancia para detectar comida

Todos estos parámetros simplemente complican la vida. Tendrías que
plantearte simplificar el modelo. Quizás lo de ser adulto permita crear las
"bildungsroman" o historias donde se convierte uno en adulto, pero los
puntos de daño y todo eso... véase arriba.

Personalmente, dejaría fijos los parámetros base del agente, pero
analizaría los del mundo. ¿Qué opináis?

Pues lo dicho más arriba. Yo casi que dejaría la cantidad de comida y el
número de agentes originales como parte del modelo (como el fitness) y
cambiaría la dimensión del mundo, solamente. Teniendo en cuenta que el
resto, a lo largo de la tesis, tendrás que considerar qué haces con ellos,
los dejas, los quitas, los haces depender unos de otros y si los ejas un
análisis de sensitividad a los resultados. Si tuviera que hacer algo ahora
mismo, todos los parámetros de edad los dejaría fijos y con cantidades
razonables (un embarado que sea la 6ª parte de la vida no lo es), basebite,
basefur, basenutrition y baseenergy los colocaría bajo control genético.
Ahora mismo tienes un metabolismo artificial con valores arbitrarios,
pero lo suyo sería que fuera genético (y que hubiera un verdadero algoritmo
genético dentro del mundo).

Todo eso lo dejamos para la versión 2.0. Para esta: se cambia tamaño del
mundo. ¿Vale?

[rhgarcia]

Perfecto,
Entonces añado también en el loop el tamaño del mundo:¿Que te parece 5x5
(=25 celdas) y 10x10 (=100 celdas)?

2014-10-29 18:18 GMT+01:00 Juan Julián Merelo Guervós <
notifications@github.com>:

¿Qué hago con el resto de parámetros?

Usa valores "razonables". En cualquier caso, mantenlos fijos. Sería
interesante, más adelante, plantear un análisis de sensibilidad de todos
los parámetros, pero parece que, razonablemente, esos son los que tienen
más influencia en el resultado. Si acaso puedes hacer algúna exploración
inicial variándolos y quedándote con algún valor.

Por un lado tengo parámetros del mundo, que afectan a los resultados y
no
están modulados por el cromosoma.
Por otro lado tengo valores base de los agentes que sí están modulados
por
el cromosoma: cada uno de esos valores se multiplicará por un gen
representado por un real entre 0 y 1.

Del mundo:
txtFoodPerDay=10 // raciones de comida al día
txtMapGridDimension=10 // dimensión del mapa
txtNumberOfInitialAgents=15 // nº de agentes distribuidos aleatoriamente
en el mapa al principio

Lo dicho. Busca valores razonables y fijos. Aunque, pensándolo bien,
algunos de estos valores deberían de formar parte también del "diseño" del
mundo. No va a ser igual un mundo con mucha que con poca comida. Desde
luego, eso hay que comentarlo, porque ahora mismo el diseño de la
atmósfera
va todo a la función fitness, y se me ocurre que en un mundo superpoblado
habría que tocar el último y en un mundo con guerra el primero. Quizás el
segundo, no tanto...

De los agentes:
txtBaseAgeToBeAdultFemale=42 // días que tarda una rata hembra en
convertirse en adulta
txtBaseAgeToBeAdultMale=49 // días que tarda una rata
txtBaseBite=5 // puntos de daño máximo que puede causar una rata por
mordisco
txtBaseEnergy=5 // puntos de energía máxima que puede tener una rata
txtBaseFur=5 // puntos de defensa máxima
txtBaseLifeInDays=200 // vida máxima en días de una rata
txtBaseNutrition=4 // puntos máximos de energía que aporta una ración de
comida
txtbasePregnancyDays=30 // días máximos para la gestación

Joder, se tarda casi tanto en convertirse en adulto como en parir. ¿En
serio que esto merece la pena meterle un parámetro?

txtBaseSmell=3 // nº máximo de cuadros de distancia para detectar comida

Todos estos parámetros simplemente complican la vida. Tendrías que
plantearte simplificar el modelo. Quizás lo de ser adulto permita crear
las
"bildungsroman" o historias donde se convierte uno en adulto, pero los
puntos de daño y todo eso... véase arriba.

Personalmente, dejaría fijos los parámetros base del agente, pero
analizaría los del mundo. ¿Qué opináis?

Pues lo dicho más arriba. Yo casi que dejaría la cantidad de comida y el
número de agentes originales como parte del modelo (como el fitness) y
cambiaría la dimensión del mundo, solamente. Teniendo en cuenta que el
resto, a lo largo de la tesis, tendrás que considerar qué haces con ellos,
los dejas, los quitas, los haces depender unos de otros y si los ejas un
análisis de sensitividad a los resultados. Si tuviera que hacer algo ahora
mismo, todos los parámetros de edad los dejaría fijos y con cantidades
razonables (un embarado que sea la 6ª parte de la vida no lo es),
basebite,
basefur, basenutrition y baseenergy los colocaría bajo control genético.
Ahora mismo tienes un metabolismo artificial con valores arbitrarios,
pero lo suyo sería que fuera genético (y que hubiera un verdadero
algoritmo
genético dentro del mundo).

Todo eso lo dejamos para la versión 2.0. Para esta: se cambia tamaño del
mundo. ¿Vale?

—
Reply to this email directly or view it on GitHub
#13 (comment)
.

[JJ]

y 20x20

[rhgarcia]

Ok, ya he eliminado JGAP de la ecuación porque no recalculaba el fitness de un indivíduo si este sobrevivía tal cual. Eso provocaba que el fitness nunca bajase ...

Se van a montar los experimentos siguientes:

Cálculo del fitness del indivíduo:

• fitnes_indivíduo = AVG (fitness_de_las_5_ejecuciones_del_mundo)
• Importante, el fitness "cuanto más mejor" usa la fórmula:
  fitness = log ((x * 10) + 1) / log(11)) from x= 0 to 1
  donde proportion = nº agentes que cumplen arquetipo / nº total de agentes en el mundo
  En wolfram alpha vereis la gráfica. Con esta fórmula se prima la aparición de todos los arquetipos buscados. Puedo cambiarla si no os gusta o la veis muy arbitraria, pero decidme por cual :-)

Criterio de parada:

• Dado que el fitness estará normalizado entre 0 y 1 (independientemente del nº de arquetipos)
• Entonces: Criterio de parada = Si en las 30 últimas generaciones no se ha mejorado el mejor fitness OR nº_generaciones == 200
  (he cambiado el criterio de parada porque me parece más sencilla de implementar e igualmente permite localizar cuando la solución se estanca, decidme si lo veis bien o si lo cambio por el propuesto por Pablo).

-Escenarios:

• F1: buscar máximo de Villanos
• F2: buscar el máximo de Villanos y de héroes
  Nota: El arquetipo héroe depende de la existencia del arquetipo Villano
• F5: buscar el máximo de Villanos, héroes, mentores, obstáculos y vengadores
  Nota: los arquetipos mentor y obstáculo dependen de la existencia del arquetipo héroe.

Perfiles:

• P1: 1
• P2: 2
• P4: 4
• P8: 8

Mundo.- Número de días virtuales:

• D128: 128 días
• D256: 256 días
• D512: 512 días

Mundo.- Dimensión del mapa:

• M5: 5x5 celdas
• M10: 10x10 celdas
• M20: 20x20 celdas

GA.- Población:

• S64: 64 indivíduos
• S128: 128 indivíduos
• S256: 256 indivíduos

Nomenclatura de los ficheros de salida:
run_[1-30]F[1,2,5]P[1,2,4,8]D[128,256,512]M[5,10,20]S[64,128,256].log

Formato del log:

(generacion) (mejor fitness) (f parcial1) (f parcial2) (f parcial3) (f parcial4) (f parcial5)
... (n veces)
(tiempo ejecución ms)

(La última línea del log será el tiempo invertido, en ms)

[JJ]

¿5 ejecuciones cuando? ¿5 últimas ejecuciones? ¿De las 5 últimas generaciones) En todo caso, escribe todo eso también en el trabajo, justificando todas las elecciones y valores, por favor.

[fergunet]

5 ejecuciones para evaluar el fitness.

El sábado, 1 de noviembre de 2014, Juan Julián Merelo Guervós <
notifications@github.com> escribió:

¿5 ejecuciones cuando? ¿5 últimas ejecuciones? ¿De las 5 últimas
generaciones) En todo caso, escribe todo eso también en el trabajo,
justificando todas las elecciones y valores, por favor.

—
Reply to this email directly or view it on GitHub
#13 (comment)
.

Pablo García Sánchez
University of Granada
http://www.ugr.es/~pablogarcia

[JJ]

Bueno, a ver. Dependiendo de cómo sea el fitness, puede que sólo haga falta una ejecución. Pero si se usan varias, véase el trabajo del ECTA sobre algoritmos evolutivos ruidosos.

[rhgarcia]

Con 5 ejecuciones solo hago referencia a ejecutar cada indivíduo 5 veces y
sacar la media, exactamente lo que había dicho Pablo.
Si todo lo demás está ok, sigo adelante :-)

2014-11-01 17:12 GMT+01:00 Juan Julián Merelo Guervós <
notifications@github.com>:

¿5 ejecuciones cuando? ¿5 últimas ejecuciones? ¿De las 5 últimas
generaciones) En todo caso, escribe todo eso también en el trabajo,
justificando todas las elecciones y valores, por favor.

—
Reply to this email directly or view it on GitHub
#13 (comment)
.

[JJ]

Vamos a ver. En términos estadísticos, 5 ejecuciones no son nada. Para tener valores estadísticamente significativos, hay que hacer por lo menos 15. Así que o se ejecuta quince o sólo una. De todas formas el ruido tiene una influencia en los algoritmos genéticos relativa. Por eso, basta con reevaluar los individuos cada generación.

[pacastillo]

Quizás aquí también viene bien echarle un vistazo al tutorial del GECCO que os comenté sobre estadística:
"Statistical analysis for evolutionary computation: introduction"
http://dl.acm.org/citation.cfm?id=1570409

Puesto que luego hay que pasarle algunos tests estadísticos, merece la pena (si el tiempo de ejecución lo permite) hacer alrededor de 30 ejecuciones.

Puesto que el cluster bioatc tiene 18 nodos y cada uno tiene 16 núcleos (creo recordar), se pueden lanzar todas las ejecuciones que hagan falta. Supongo que tenéis acceso, pero si necesitáis ayuda, avisadme.

Por otro lado, tanto para este trabajo como para otros, si necesitáis más recursos, podemos usar el superordenador http://alhambra.ugr.es Sólo tenéis que indicármelo.

[deantares]

Me apunto lo del alhambra para mis "mierdas". La verdad que ya lo estuve mirando en su momento y creo que puede ser interesante. El lunes me pongo a echarle un ojo.

[fergunet]

Bueno, pues ya he puesto el bluster bioatc echando humo: nodos del 1 al 6, cada uno con 5 ejecuciones del .jar de MADE (cada run ejecuta TODAS las combinaciones de parámetros una sola vez, por eso lo he lanzado 30 veces). Se van a generar 29160 ficheros de log, cada uno bien identificado.

@deantares mira que no te afecten esos nodos a la ejecución de lo tuyo.

Cierro el issue, esperemos que terminen para el viernes...

[mgarenas]

Cuidadín con el espacio

Maribel

On 02/11/14 22:39, Pablo García Sánchez wrote:

Bueno, pues ya he puesto el bluster bioatc echando humo: nodos del 1
al 6, cada uno con 5 ejecuciones del .jar de MADE (cada run ejecuta
TODAS las combinaciones de parámetros una sola vez, por eso lo he
lanzado 30 veces). Se van a generar 29160 ficheros de log, cada uno
bien identificado.

@deantares https://github.com/deantares mira que no te afecten esos
nodos a la ejecución de lo tuyo.

Cierro el issue, esperemos que terminen para el viernes...

—
Reply to this email directly or view it on GitHub
#13 (comment).

[deantares]

@fergunet yo tenía lanzado mi algoritmo en el nodo compute-0-0.

[mgarenas]

chicos, no es para nada una buena práctica que lancéis experimentos en
el nodo 0, a no ser que necesitéis ese nodo porque todos los demás están
ocupados. por qué? pues porque es la entrada el cluster, y todos los
usuarios van a entrar al cluster por ahí, osea.... que por una parte
estáis retrasando a todos en sus accesos y además estáis retrasando
vuestros experimentos porque ese nodo hace de pasarela a todo el que entra.

Maribel

On 02/11/14 23:01, Antonio Fernández Ares wrote:

@fergunet https://github.com/fergunet yo tenía lanzado mi algoritmo
en el nodo compute-0-0.

—
Reply to this email directly or view it on GitHub
#13 (comment).

[deantares]

En bioatc está el frontend (nodo-local al que acceden los usuarios) y los 18 nodos de cómputo (numerados desde compute-0-0 a compute-0-17). El compute-0-0 no es el nodo de entrada de los usuarios 😋

[mgarenas]

Ok entonces mejor

Enviado de Samsung Mobile

-------- Mensaje original --------

De: Antonio Fernández Ares notifications@github.com

Fecha:02/11/2014 23:17 (GMT+01:00)

Para: geneura-papers/2015-Evostar 2015-Evostar@noreply.github.com

Cc: Maribel García Arenas mgarenas@ugr.es

Asunto: Re: [2015-Evostar] [Made] Lanzar los experimentos YA (#13)

En bioatc está el frontend (nodo-local al que acceden los usuarios) y los 18 nodos de cómputo (numerados desde compute-0-0 a compute-0-17). El compute-0-0 no es el nodo de entrada de los usuarios

—
Reply to this email directly or view it on GitHub.

[amorag]

Perdonad por la respuesta tardía, pero he estado de niñero sábado y domingo... :_(

Respecto al artículo en sí:

• repeticiones para evaluar individuos SÍ Y SOLO SÍ el resultado no es determinista, como es lógico. :P
• pueden ser 5, aunque claro, cuantas más mejor.
• la reevaluación (entendida como evaluar en cada generación a todos los individuos, aunque ya se hubiesen evaluado en la anterior) está bien, pero en un problema tan complejo unas cuantas reevaluaciones no van a paliar el ruido en mucha medida, creo yo. Yo combinaría reevaluación con múltiples evaluaciones por individuo (cuantas más mejor, pero 5 sirven de algo al menos).
• van a salir un número ingente de resultados. Va a ser muy complicado saber qué parámetros tienen más influencia o simplemente, tienen influencia. Hay que hacer una super-comparativa con test ANOVA (supongo yo), pero repito que va a ser chungo saber si los resultados mejoran sólo en base a determinados parámetros... :_(
• aunque si se curra bien puede salir un trabajo muy bueno, así que ánimo. :D

[mgarenas]

On 03/11/14 14:06, Antonio Mora wrote:

Perdonad por la respuesta tardía, pero he estado de niñero sábado y
domingo... :_(

Respecto al artículo en sí:

Yo en este artículo no he aportado mucho, porque no lo controlo y no me
gusta meterme donde no me llaman, pero si queréis mi ayuda-opinión, ahí
la lleváis.

• repeticiones para evaluar individuos SÍ Y SOLO SÍ el resultado no
  es determinista, como es lógico. :P

Claro, supongo que no hay ninguno determinista, porque si lo hay, tendrá
poco que ver con los AEs

• pueden ser 5, aunque claro, cuantas más mejor.

Con 5 resultados, la muestra es bastante, bastante pequeña.

• la reevaluación (entendida como evaluar en cada generación a todos
  los individuos, aunque ya se hubiesen evaluado en la anterior)
  está bien, pero en un problema tan complejo unas cuantas
  reevaluaciones no van a paliar el ruido en mucha medida, creo yo.
  Yo combinaría reevaluación con múltiples evaluaciones por
  individuo (cuantas más mejor, pero 5 sirven de algo al menos).
• van a salir un número ingente de resultados. Va a ser muy
  complicado saber qué parámetros tienen más influencia o
  simplemente, tienen influencia. Hay que hacer una
  super-comparativa con test ANOVA (supongo yo), pero repito que va
  a ser chungo saber si los resultados mejoran sólo en base a
  determinados parámetros... :_(

Si formateais bien la tabla de resultados, es decir, algo como

parametro1 parametro2 parametro3 ... resultado
valor1.1 valor2.1 valor3.1 r1
valor1.2 valor2.2 valor3.2 r2

yo os paso los test de ANOVA, peroooooooooo, ANOVA tiene unas
condiciones de aplicación que seguramente no cumplís y que deberíamos de
testear, como por ejemplo la normalidad en los resultados, la
independencia de varianzas y la independencia de las ejecuciones, que
creo que es la única que se suele cumplir. Yo plantearía directamente un
test no paramétrico, en vez de ANOVA

Maribel

• aunque si se curra bien puede salir un trabajo muy bueno, así que
  ánimo. :D

—
Reply to this email directly or view it on GitHub
#13 (comment).

[JJ]

Hola,

El 3 de noviembre de 2014, 15:09, Maribel García Arenas <
notifications@github.com> escribió:

On 03/11/14 14:06, Antonio Mora wrote:

Perdonad por la respuesta tardía, pero he estado de niñero sábado y
domingo... :_(

Respecto al artículo en sí:

Yo en este artículo no he aportado mucho, porque no lo controlo y no me
gusta meterme donde no me llaman, pero si queréis mi ayuda-opinión, ahí
la lleváis.

• repeticiones para evaluar individuos SÍ Y SOLO SÍ el resultado no
  es determinista, como es lógico. :P

Claro, supongo que no hay ninguno determinista, porque si lo hay, tendrá
poco que ver con los AEs

No estamos hablando de los algoritmos, sino de la evaluación de un
individuo. En este caso no es determinista.

• pueden ser 5, aunque claro, cuantas más mejor.

Con 5 resultados, la muestra es bastante, bastante pequeña.

O sea que no sirve de nada. Estamos hablando de evaluaciones del fitness,
no de ejecuciones.

• la reevaluación (entendida como evaluar en cada generación a todos
  los individuos, aunque ya se hubiesen evaluado en la anterior)
  está bien, pero en un problema tan complejo unas cuantas
  reevaluaciones no van a paliar el ruido en mucha medida, creo yo.
  Yo combinaría reevaluación con múltiples evaluaciones por
  individuo (cuantas más mejor, pero 5 sirven de algo al menos).

A ver, leeros el artículo del ECTA. Ni uno ni otro es la solución. Pero ese
no es el tema de este trabajo. Lo único que estoy diciendo es que para 5
evaluaciones se hace una y listo.

[amorag]

Maribel, ya te ha respondido JJ.

Mi opinión, si no lo he entendido mal, es que este problema es infinitamente más ruidoso que el Planet Wars y otros juegos dependientes del comportamiento de un agente (rival). Aquí el resultado depende de las interacciones entre muuuuchos agentes.

Por eso propongo, en conjunción con Fergu hacer un pequeño test en paralelo, que luego se pueda añadir al artículo, si sale bien, como justificación.
Sería realizar un pequeño estudio de cómo afecta el ruido a este problema, pero sin entrar en muchos detalles.

Con los mismos parámetros que usases en otros artículos (como el del ALIFE), yo probaría con varios grupos de evaluaciones, por ejemplo:

• con 5 evaluaciones por fitness (algoritmo original)
• con 1 evaluación por fitness
• con 10 evaluaciones
• con 30 evaluaciones

Esto se repite 30 veces para cada configuración.

Se estudia (brevemente) en qué medida afecta el ruido (cómo varía el fitness en cada caso) y se determina cuántas repeticiones son las más adecuadas.
Esperemos que salga que no afecta mucho y así se justifica bien que sólo se haya usado una evaluación por individuo. ;D

En todo caso un estudio como este bien hecho (estilo el artículo de JJ :P) daría para un artículo potente. ;D

Taluego!

PD
Yo sí me leí el artículo del ECTA.
De hecho, te corregí algunas cosillas (en GH) y no me hiciste caso. XD

[JJ]

El 3 de noviembre de 2014, 17:10, Antonio Mora notifications@github.com
escribió:

Maribel, ya te ha respondido JJ.

Mi opinión, si no lo he entendido mal, es que este problema es
infinitamente más ruidoso que el Planet Wars y otros juegos dependientes
del comportamiento de un agente (rival). Aquí el resultado depende de las
interacciones entre muuuuchos agentes.

Bueno, habrá que verlo. Es posible, pero habrá que ver realmente cómo es el
ruido. Por eso sería conveniente que @raiben hiciera, igual que le hemos
pedido a todo el mundo, un estudio evaluando 100 veces 10 individuos de la
primera generación, 10 de una intermedia y 10 de la final, a ver la forma
que tiene.

Por eso propongo, en conjunción con Fergu hacer un pequeño test en
paralelo, que luego se pueda añadir al artículo, si sale bien, como
justificación.
Sería realizar un pequeño estudio de cómo afecta el ruido a este problema,
pero sin entrar en muchos detalles.

Con los mismos parámetros que usases en otros artículos (como el del
ALIFE), yo probaría con varios grupos de evaluaciones, por ejemplo:

• con 5 evaluaciones por fitness (algoritmo original)
• con 1 evaluación por fitness
• con 10 evaluaciones
• con 30 evaluaciones

Esto se repite 30 veces para cada configuración.

No, Antonio, no se trata así el ruido. En el artículo se usa un estadístico
como la media o bien comparaciones usando Wilcoxon. 5 evaluaciones por
fitness son igual que 1, es decir, sigue siendo ruido. Más evaluaciones
enlentecen mucho y más si es un individuo que te vas a cargar, así que en
el artículo propone usar la "memoria" para acumular evaluaciones.

Yo sí me leí el artículo del ECTA.
De hecho, te corregí algunas cosillas (en GH) y no me hiciste caso. XD

Mal por mi parte. Pero en ese artículo proponía diferentes formas de tratar
el ruido, ninguna de las cuales tiene que ver con lo que dides arriba antes.

[amorag]

Wolas.

No he dicho que así se trate el ruido, he propuesto que se haga un estudio, en la línea del que quieres hacer tú, para ver cómo ha evolucionado el fitness en distintos puntos del algoritmo.
Mi idea era ver la progresión del mejor fitness y del fitness medio (de todas las ejecuciones) en cada caso, aunque de forma gráfica. Por eso he dicho que era un test simple.
Mucho mejor si se hace con un test estadístico, claro, pero ya se complica la cosa y quizá nos excedamos para un artículo como este. ;)

Talego!

[JJ]

El 3 de noviembre de 2014, 17:47, Antonio Mora notifications@github.com
escribió:

Wolas

No he dicho que así se trate el ruido, he propuesto que se haga un
estudio, en la línea del que quieres hacer tú, para ver cómo ha
evolucionado el fitness en distintos puntos del algoritmo.

Eso es lo que quiero. Para eso, 100 evaluaciones de 10 individuos al
principio, en mitad y al final de la ejecución, igual que le he pedido a
todo el mundo.

Mucho mejor si se hace con un test estadístico, claro, pero ya se complica
la cosa y quizá nos excedamos para un artículo como este. ;)

No se trata de hacer un test estadístico, sino un modelo estadístico, y no
para este artículo, sino para otro. En este, como digo, simplemente
reevaluar el fitness cada generación.

[amorag]

Ok, sólo pretendía justificar con resultados numéricos/gráficos la elección de una sola evaluación por individuo.

Aunque se puede justificar como tú dices (JJ) y ya está.

[JJ]

En el artículo ese, y en muchos otros, se usa simplemente reevaluación de los individuos como un método para tener en cuenta el ruido. Si no hay mucho ruido (lo que está por ver) y si el algoritmo evolutivo no tiene una presión selectiva muy alta, no es un mal método y sobre todo ahorra reevaluaciones.

[fergunet]

@raiben puedes describir bien la fórmula del fitness para que la meta en el .tex? no veo donde está proportion, por ejemplo. Supongo que al final lo que se hace es sumar por arquetipos, no? (y va de 0 a 1, supongo)