Fluid Evolutionary Algorithms


Published on

Presentation of a prototype of evolutionary algorithms based on the FluidDB platform

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Some more details; you might wonder why I'm the single author of this paper; there probably haven't been many of this kind in the conference (but there's already one in this session). But it's a long story, and we only have around 15 minutes, so you'll have to wait for the journal paper.
  • Objects are shared, can't be deleted. Graph link values are not, and depend on the permissions you have issued it. 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.
  • 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 queries increases probability of obtaining good results
  • Foto de http://www.flickr.com/photos/djou/91562666/sizes/o/in/photostream/
  • Fluid Evolutionary Algorithms

    1. 1. Fluid Evolutionary Algorithms JJ Merelo http://twitter.com/jjmerelo GeNeura team: http://geneura.wordpress.com University of Granada: http://www.ugr.es
    2. 2. Be fluid, my friend “FluidDB is an openly writable shared database” http://fluidinfo.com/about
    3. 3. FluidDB was born from evolutionary computation <ul><li>Company created by Terry Jones. </li></ul><ul><li>“ FluidDB is a single web of things.”
    4. 4. “ FluidDB makes it possible for data to be social.”
    5. 5. “ Unique yet powerful control model”
    6. 6. Makes information easy to reuse. </li></ul>
    7. 7. How does FluidDB work? Thing fluiddb/about Another Thing http://wcci2010.org jjmerelo/likes dwcorne/stars 5 The sound of music
    8. 8. Fluidifying Evolutionary algorithms 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
    9. 9. Running a fluid EA 0010101100 001010000 0010101100 0010101100 1110101100 1101101100 0011101100 0010101100 0010101100 1011101100 0011101100 0010101100
    10. 10. There is a free... software <ul><li>Free software available from http://sl.ugr.es/001U
    11. 11. Implemented in Perl
    12. 12. 1600 evaluations
    13. 13. Population = 2/32
    14. 14. Problem = MaxOnes (64 bits) </li></ul>
    15. 15. Number of successful reproductions
    16. 16. So far, so good Continuous increase of fitness (steady-state like)
    17. 17. Using the pool for improving results This one is first This goes second
    18. 18. Decreasing batch size yields better results This one is first This goes second
    19. 19. Concluding <ul><li>Concurrency possible, but will have to wait
    20. 20. FluidDB can be a persistent pool of problem solutions
    21. 21. Balancing using FluidDB and local pool </li></ul>
    22. 22. Thanks for your attention Enjoy Barcelona!