           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
