Computación evolutiva no tradicional
•Descargar como ODP, PDF•
1 recomendación•687 vistas
Una historia de probar cosas nuevas en computación evolutiva a lo largo de muchos años. Charla dada en la Complutense el 8 de septiembre de 2011
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (19)
Similar a Computación evolutiva no tradicional
Similar a Computación evolutiva no tradicional (20)
Más de Juan J. Merelo
Más de Juan J. Merelo (20)
Último
Último (20)
Computación evolutiva no tradicional
- 1. Computación evolutiva en entornos no tradicionales JJ Merelo Universidad de Granada Http://facebook.com/jjmerelo
- 3. Entorno no tradicional
- 5. Conseguir ciclos de computación en desuso.
- 6. Entender la esencia de los algoritmos bioinspirados.
- 7. ¿Qué vamos a ver? Diferentes formas de llevar a cabo EAs en entornos no tradicionales
- 8. Un ejemplo parásito para abrir boca $parcial =( $parcial ? "$parcial+" : "" ) . "log($i*$i*exp($i))+sqrt($i)" ; if ( $opt ) { print eval $parcial , " " ; } else { my $s = uri_escape ( $parcial ); my $url = "http://google.com/search?q=$s amp; btnG=B C3 BAsqueda" ; my $response = $browser -> get ( $url ); die "Canâ't get $url -- " , $response -> status_line unless $response -> is_success ; my ( $resultado )= ( $response -> decoded_content = ~ m {< b > . + ? = ( . + ? )</ b ></ td >}); $resultado = ~ s {(< font size =- 2 > </ font >)}{} g ; print "$i => Resultado es $resultado " ;
- 10. Y también en una cámara Canon .
- 12. Las redes P2P (entre pares) reflejan la complejidad del mundo actual..
- 13. Son redes dinámicas, ad-hoc, y superpuestas a las redes normales.
- 14. Topología P2P Red superpuesta Red física
- 15. Modelo de capas para computación evolutiva distribuida P2P PCs conectados a internet Red superpuesta P2P Sistema de agentes Computación evolutiva
- 17. Algoritmo evolutivo estructurado espacialmente
- 18. Cada agente estructura un sólo individuo
- 21. ¿Y porqué no en AJAX? function migrate ( pop ) { request = new XMLHttpRequest (); var peticion_str = 'http://geneura.ugr.es/~jmerelo/proyectos/ga-js/cgi/get_guy.cgi?chromosome=' + pop [ 0 ]. chromosome + "&fitness=" + pop [ 0 ]. fitness ; masca = null ; request . open ( 'GET' , peticion_str , true ); request . onreadystatechange = add_to_population ; request . send ( null ); } function add_to_population () { if ( request . readyState == 4 ) { if ( request . status == 200 ) { var json = request . responseText ; eval ( "masca = " + json ); document . getElementById ( 'ga-2' ). innerHTML = json ; if ( masca [ 'generaciones' ] > 0 ) { run_ga ( masca [ 'generaciones' ] ); } } } }
- 23. Hace falta un sistema de comunicación asíncrono
- 24. AJAX=Asynchronous Javascript & XML.
- 26. El modelo de objetos también es compatible.
- 27. Requisito: objeto XMLHttpRequest en el navegador.
- 28. Venga, va, ¿cómo funciona?
- 31. La distribución se realiza entre cliente/servidor, y también podría hacerse entre diferentes servidores.
- 32. Las pruebas nos permitirán establecer su factibilidad, y el entorno más favorable para la misma, así como una línea base de prestaciones. Se busca logo molón. Razón, aquí.
- 37. Escalado
- 39. Se trata, una vez más, de usar el navegador para computación distribuida masiva.
- 40. En este caso, todo el algoritmo evolutivo se ejecuta en el navegador
- 41. O volviendo a la carretera real
- 43. Be fluid, my friend “ FluidDB is an openly writable shared database” http://fluidinfo.com/about
- 45. “ FluidDB permite que los datos sean sociales.”
- 46. “ Modelo de control único pero potente”
- 47. Reutilización simple de la información.
- 48. ¿Cómo funciona? Thing fluiddb/about Another Thing http://wcci2010.org jjmerelo/likes dwcorne/stars 5 The sound of music
- 49. Fluidificando algoritmos evolutivos Thing fluiddb/about Another Thing 0100 1001 1100 1101 jjmerelo/exp-xyz/fitness dwcorne/exp-abc/fitness 33 22 0110 0001 1111 1101 jjmerelo/exp-xyz/current
- 50. Ejecutando un EA fluido 0010101100 001010000 0010101100 0010101100 1110101100 1101101100 0011101100 0010101100 0010101100 1011101100 0011101100 0010101100
- 54. Población = 2/32
- 55. Problema = MaxOnes (64 bits)
- 56. Número de reproducciones con éxito
- 57. Por ahora va bien El fitness se incrementa de forma continua
- 58. Usar el pool calculado mejora los resultados Esta es la primera Segunda ejecución
- 59. El tamaño del lote es importante Esta es la primera Esta es la segunda
- 61. Cómo se implementa un algoritmo evolutivo distribuido en él.
- 62. Medidas de aceleración sobre diferentes ordenadores
- 63. Diferencias entre modos de conexión. .
- 64. Dropbox
- 66. Conexión Gigabit Ethernet o WiFi + WPA.
- 67. Dropbox actualizado a la última versión
- 68. Funciones de fitness: MMDP, P-Peaks y Trap.
- 69. Nuboso, con posibilidad de evolución Individuo Evaluaciones/nodo
- 70. Atrapado en las nubes Ethernet WiFi
- 72. Resultados iniciales MMDP Computers Gens for Migration success(%) 1 100 83% 2 100 95% 4 100 100% 1 200 70% 2 200 88% 4 200 100% 1 400 80% 2 400 90% 4 400 100%
- 74. Resultados MMDP
- 77. El equilibrado de carga es automático.
- 78. La red importa.
- 79. Buen escalado.
- 80. ¿Significará un algoritmo mejor? ¡Sí!
- 83. ¿Hay alguna conclusión? No
- 84. ¿Hay alguna conclusión? Perdón, sí
- 87. Deja que la Naturaleza sea tu guía
- 88. Muchas gracias @jjmerelo http://geneura.wordpress.com Eso es todo
Notas del editor
- Foto de J. Bakker Ijmuiden en http://www.flickr.com/photos/joost-ijmuiden/3613829273/in/photostream/
- Un sólo ordenador/procesador, secuencial, o incluso si es paralelo usando una configuración homogénea, estática. Imagen de http://www.flickr.com/photos/wizzer/5357865167/ por wizzer2801
- Casi cualquier entorno que no sea ese: lenguajes no tradicionales, soportes no tradicionales (una cámara de fotos, por ejemplo, o incluso un teléfono móvil), computación basada en hebras, P2P, asíncrona.. Foto de .m for mathijs en http://www.flickr.com/photos/matthijs/3514892055/.
- Foto por The U. S. Army http://www.flickr.com/photos/soldiersmediacenter/4685688778/ Por supuesto, también hay una razón importante: publicar trabajos. Igual la más importante.
- Algoritmo genético que usa a Google para hacer cálculos. Va a ser más lento, porque hay que tener en cuenta la capacidad de la red, pero es cuestión de aprovecharlo. Ojo, esto es Perl, es para hombres de pelo en pecho. Y mujeres de pecho en pecho.
- En este caso, lo que se hace es que se usa el mecanismo asíncrono de AJAX para enviar un individuo a un servidor. El servidor responde con otro, escogido entre los mejores.
- JavaScript está construido alrededor de una serie de estándares ECMA. En realidad, hay otras formas de interaccionar de forma asíncrona entre el navegador y el servidor; ahora mismo, ésta es la más popular.
- Se podría haber usado un entorno diferente. En realidad, tampoco se usa excesivamente RoR y puede ser incluso una rémora a la hora de conseguir altas prestaciones. La gran ventaja que tiene es la integración con ajax. Es muy fácil hacer llamadas AJAX. Pero quizás hoy lo haría en otro lenguaje: Perl o usando el Google Web Toolkit. También se podría usar un entorno totalmente diferente: Microsoft .Net, por ejemplo, o Ruby. Pero no sería tan ubicuo.
- En principio, se podría usar otro cualquiera. De hecho, es posible que lo cambiemos, según el “peso” de la aplicación vaya del servidor al cliente. Pero el desarrollo en RoR es rápido, y tiene una comunidad activa
- En mi casa, con mi ordenador de sobremesa, y dos portátiles, el mío y el que le compramos a Lourdes, dos VAIO.
- No es como para tirar cohetes, pero algo se consigue. El problema es que RoR (mongrel) tiene una sola hebra de salida, y en estas condiciones se producen bloqueos para servir al cliente los resultados. Tampoco está optimizado en este sentido. Está en modo debug y no producción (aunque esto afectaría sobre todo a las prestaciones por nodo, no al escalado). En pruebas hechas con clusters de nodos se han conseguido mejores resultados, pero la aplicación no está hecha para trabajar con muchos nodos clientes. Así que hay que plantearse un cambio en el servidor, o en la distribución cliente-servidor
- Microsiervos lo publicó aquí: http://www.microsiervos.com/archivo/ordenadores/experimento-computacion-distribuida.html
- Objects are shared, can't be deleted. Graph link values are not, and depend on the permissions you have granted them. By default, just the creator can do anything on them.That's why they are shown in blue. Since the “about” tag belongs to fluiddb, once it's created it can't be changed (write-only)
- Take into account that the population must remain constant, and that it's ensured that every member in the population is unique. If the newly generated chromosome is repeated, it is dropped. The new chromosomes do have already its fitness attached, but in pinciple this is not needed; one client could do the evolutionary operators, and another the evaluation.
- It's free as in freedom, not as in free beer. Scientific software should be free from the get go, becasue it encourages reproctibility Image from: http://www.flickr.com/photos/zarwan/79822984/sizes/l/in/photostream/ It's the Perl camel drinking from the fluid evolutionary algorithm. Take into account that the concept of population does not really apply here. We have a “current” population, and also a “local” population, and a number of evaluations before each immigration.
- Since individuals are unique, the number of them added each generation goes down, which is only obvious. It could be done some other way, but it would involve many more database queries. It never goes down to 0, anyways.
- This is a sequential run; take into account that the number of evaluations is rather low; even so, it reaches the maximum due to high diversity in the pool
- Due to the alpha state of FluidDB and the concurrency problems, we have used sequential runs, with the second run starting after the first.The second gets random chromosomes from the pool, which increasingly mean that former solutions are reused. Esta es una de las ventajas de usar un sistema en el cual todas las soluciones son persistentes; siempre se va mejorando sobre lo ya obtenido. Lo único que tienes que preocuparte es de etiquetar correctamente cuales son las mejores soluciones.
- Batch size is 2 in this case; two are taken from the current population and put back into it (if new). Since inmigration is much more frequent, improvement is faster and steadier. This probably means that making more fluidinfo queries increases probability of obtaining good results
- Describe basic working principles of Dropbox as a free file synchronization service, how it monitors certain files and how they are copied when modifed under its own schedule. It's got a permission system that regulates who's got access to which resources; it's usually done per directory, and you can also make directory results publicly available.
- Every node runs independently, although they are started (roughly) at the same time. After an appointed number of generations, an individual (the best) is logged into the common directory, and another one is taken. A file with the total number of evaluations is also created, and the sum of all evaluations is checked as a termination condition. To speed up processing and reduce overhead speeding up synchronization, the individual is codified into the filename, so that the only thing that is read is the directory, not the content of the file itself. We use different kinds of codifications depending on the chromosome length, but lengths of several hundreds are not a problem. As it can be seen, the fitness is also codified into the name.
- Deberías usar los del paper. Se ven mejor...
- Picture from Andrew Rivett, Veggiefrog