           SPELL=libevocosm
         VERSION=2.5.0
          SOURCE=${SPELL}-${VERSION}.tar.gz
SOURCE_DIRECTORY=${BUILD_DIRECTORY}/${SPELL}-${VERSION}
   SOURCE_URL[0]=http://www.coyotegulch.com/${SPELL}/${SOURCE}
     SOURCE_HASH=sha512:44db3ddbe459e0705432b2a5ec51853ee7558d7d6ba73464c07e37708f2e3f1b7489a65bb0f56deab46078b7e7acb1fb45d7587e7cd9ea1e3b07ae89e1a3d835
        WEB_SITE=http://www.coyotegulch.com/libevocosm/
         ENTERED=20031218
      LICENSE[0]=http://www.coyotegulch.com/svfl.html
        KEYWORDS="libs"
           SHORT="Evolutionary algorithm library classes"
cat << EOF
Evocosm is a set of classes that abstract the fundamental components of an evolutionary algorithm
The classes include:
    * Random Numbers
      Evocosm relies on the code in The Twisted Road to to Randomness for random number generation.  The Mersenne Twister algorithm is particularly well-suited to evolutionary algorithms, based on its long period,  granularity, "randomness", and speed. As of the 2.1.0 release of libevocosm, the mtprng class resides in libcoyote, and not libevocosm as it did earlier. This means that any program using libevocosm must also link against libcoyote.
    * Validation
      To validate function arguments, Evocosm uses the code I describe in Beyond Assert; this code is part of libcoyote. Any program using libevocosm must also link against libcoyote.
    * Floating- Point Chromosomes
      Evcosom supports the crossover and mutation of IEEE-754 floating-point numbers, using an algorithm I invented in the mid-1990s. This topic is covered in detail here.
    * Roulette Wheels
      I introduced the concept of a software roulette wheel in The Power of Life; the roulette_wheel class implements that concept for Evocosm.
    * Organisms
      Think of an "organism" as an answer to a problem posed by a fitness landscape; "genes" define its behavior and an associated fitness value is assigned by an evocosm during testing. Evocosm provides the freedom to define organisms as almost anything: bit strings, floating-point numbers, finite state machines, LISP programs, or external robots controlled via radio waves. In A Complexity of Options, I used an Evocosm-derived GA to determine the gcc options that produce the faster code.
    * Fitness Landscapes
      A "fitness landscape" defines the environment where organisms "live" or a problem that they are tested against.  The landscape is intimately tied to the nature of the organism; think of an organism as a potential solution to a problem implemented by the landscape. A floating-point organism, for example, could be tested by a fitness landscape that represents a function to be maximized. Or, an organism describing the shape of wing could be tested by a landscape that simulates a wind tunnel.
    * Evocosms
      The evocosm class binds a population of organisms to a set of objects that define the rules of survival and reproduction. An evocosm will have one or more populations, which will evolve against population-unique and shared (common) fitness landscapes; breeding is controlled by a set of class objects from the following classes.
    * Fitness Scaling
      As a population converges on an "answer", the difference between fitness values often becomes very small; this prevents the best solutions from having a significant advantage in reproduction. Fitness scaling solves this problem by adjusting the fitness values to the advantage of the most-fit chromosomes. Evocosm includes a variety of fitness scaling algorithms, including windowed, quadratic, sigma, and linear algorithms.
    * Migration
      A migrator removes individuals (via "emigration") from a population of organisms, transferring them to another population (via "immigration"). The only concrete implementation of this interface is random_pool_migrator, which defines a specific number of organisms that may migrate from each population to another. When creating a random_pool_migrator, specify the number of organisms that can migrate from each population. Migration is, of course, meaningless in any application that has only one population.
    * Selecting Survivors
      A selector decides which organisms survive from one generation to the next. Some evolutionary algorithms will not use a selector; other will. In general, it is effective to keep the "best" organisms from one generation to the next, so that good genes do not become lost at random. This is, of course, an improvement on nature, where being "the best" doesn't guarantee survival.
    * Reproduction
      In most cases, a reproducer generates new organisms using parents selected (by fitness) from an existing population. In some singular (and probably rare) cases, a reproducer might generate new, random organisms in order to keep diversity high. Reproduction techniques can include crossover and asexual, sexual and (my favorite) try-sexual models.
    * Mutation Operators
      A mutator applies mutations (random, usually small changes) to a set of organisms. Mutation is highly dependent on the type of organism. In traditional genetic algorithms, a mutation flips one or more bits in an integer (i.e., chromosome). Evolving a path for the Traveling Salesman Problem involves complex mutations that maintain valid permutations of destination points; in the case of floating-point numbers, I've provided utilities for mutating and crossing IEC-60559 (IEEE- 754) float and double types.
EOF
