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 JJ Merelo http://twitter.com/jjmerelo GeNeura team: http://geneura.wordpress.com University of Granada: http://www.ugr.es
Be fluid, my friend “FluidDB is an openly writable shared database” http://fluidinfo.com/about