Upgrade from versions prior to 3.0

[Documentation Index]

Introduction

Some JGAP versions (such as 2.4 and 3.0) introduced many concepts as well as many architectural changes. This was seen necessary to evolve the structure of the product.

If you work with a JGAP version prior to 3.0  (i.e. 1.1 or 1.0), and want to upgrade to a newer version , you should read this document. It will guide you thru the process of upgrading to version 2.0 and later upcoming versions.

Hint: If you try to upgrade from a version lower than 2.0 to a version higher than 2.0, first upgrade to 2.0, then test your application. After that, upgrade to 2.4 (or a later version) and test again! The same holds true for upgrading from lower 2.6 to 3.0: First advance to 2.6, then to 3.0

Upgrade Instructions

Reproduction Operator

The ReproductionOperator class is no longer needed. Reproduction takes place via implementations of NaturalSelector's. Main reason: Performance increase.
As this information has been added quite a time after releasing version 2.0, it could be that it applies not for version 2.0. But it applies  for the latest JGAP versions for sure!

Central Configuration Object

With version 2.0, the holder of the org.jgap.Configuration object has been made a Singleton. That means you don't have to give it into any method as it was necessary earlier. After you set up the configuration object in the used manner, you only need to state:

Configuration myConfiguration;
//Set up the configuration object
...
//Register the configuration object
Genotype.setConfiguration(myConfiguration);

As you see, the holder of the Configuration object is org.jgap.Genotype.

With version 3.0, the configuration object is passed to any object needing it via each object's constructor. The access via Genotype.getConfiguration() and Genotype.setConfiguration(org.jgap.Configuration) is deprecated and no longer supported by most of the objects. 

Configuration myConfiguration;
//Set up the configuration object
...
//Register the configuration object with each JGAP class used, e.g.:
IChromosome sampleChromosome = new Chromosome(gaConf,
            new BooleanGene(gaConf),
            chromeSize);

Fitness value now of type double

The type of the fitness value has changed from int to double. The fitness value can be obtained via

double fitnessValue = Chromosome.getFitnessValue();

Just change your implementation to work with double-typed variables instead of int-typed ones. There is no performance loss as our extended tests show!

Fitness evaluator in Configuration Object

If you don't construct your Configuration object via something like

Configuration myConfig = new DefaultConfiguration()

you need to make sure you set the FitnessEvaluator. You can easily do this by

myConfig.setFitnessEvaluator(new DefaultFitnessEvaluator());

The fitness evaluator is responsible for deciding when a fitness value is better and when it's not. If you are interpreting the fitness value as a defect rate then the lower the better. If your fitness value is a performace indicator, it should be higher to be better.

NaturalSelector now an abstract class

Change class declaration

The org.jgap.NaturalSelector interface has become an abstract class. The interface definition has moved to org.jgap.INaturalSelector.

So instead of writing

class MySelector implements NaturalSelector {...}

you should now write

class MySelector extends NaturalSelector {...}

Implement new method returnsUniqueChromosomes()

Interface org.jgap.INaturalSelector now holds method returnsUniqueChromosomes:

/**
 * @return true: The implementation of the NaturalSelector only returns
 * unique Chromosome's (example: BestChromosomesSelector).
 * false: Also doublettes could be returned (example: WeightedRouletteSelector)
 */
boolean returnsUniqueChromosomes();

Just implement something like

public boolean returnsUniqueChromosomes() {
   return true;
}

in your implementation of org.jgap.NaturalSelector.

Signature of method select changed

The new signature of the select method in org.jgap.NaturalSelector (declared in INaturalSelector) is as follows:

 /**
  * Select a given number of Chromosomes from the pool that will move on
  * to the next generation population. This selection should be guided by
  * the fitness values, but fitness should be treated as a statistical
  * probability of survival, not as the sole determining factor. In other
  * words, Chromosomes with higher fitness values should be more likely to
  * be selected than those with lower fitness values, but it should not be
  * guaranteed.
  *
  * @param a_howManyToSelect the number of Chromosomes to select
  * @param a_from_population the population the Chromosomes will be selected from
  * @param a_to_population the population the Chromosomes will be added to
  */
void select(int a_howManyToSelect, Population a_from_population, Population a_to_population);

Normally, calls to this method should only be made by org.jgap.Genotype in method applyNaturalSelectors. If you call the method yourself, adapt the parameters as shown above or have a look at the implementation in Genotype.

Signature of method newGene changed

The new signature of the select method in interface org.jgap.Gene (used in all implementations, as in StringGene) is as follows:

/**
   * Provides an implementation-independent means for creating new Gene
   * instances. The new instance that is created and returned should be
   * setup with any implementation-dependent configuration that this Gene
   * instance is setup with (aside from the actual value, of course). For
   * example, if this Gene were setup with bounds on its value, then the
   * Gene instance returned from this method should also be setup with
   * those same bounds. This is important, as the JGAP core will invoke this
   * method on each Gene in the sample Chromosome in order to create each
   * new Gene in the same respective gene position for a new Chromosome.
   * <p>
   * It should be noted that nothing is guaranteed about the actual value
   * of the returned Gene and it should therefore be considered to be
   * undefined.
   *
   * @return a new Gene instance of the same type and with the same
   * setup as this concrete Gene
   *
   * @since 1.0
   */
Gene newGene();

Previous signatures included an input parameter of type org.jgap.Configuration. The configuration is now set as described in this document (see above).

Method add(Chromosome a_chromosomeToAdd) is private now

As method add(Chromosome a_chromosomeToAdd) is private now, you need to adapt your implementations to reflect this: Just change the public keyword in your implementation to protected.

If you call the add-method, remove these calls. They are obsolete as the select method (see above) now calls the add-method itself. 

Since 2.2: New abstract base class for all Gene implementations

The abstract base class org.jgap.BaseGene should be used as a base class for all org.jgap.Gene implementations. With that you get all default logic for free.

Since 2.4: toString() of classes  implementing Gene interface changed

Please consider that the result of the toString() methods in the classes implementing the Gene interfaces (DoubleGene, StringGene, CompositeGene etc.).

In the new implementation, the class name is preceeding the rest of the output (e.g. "CompositeGene(...)" or "BooleanGene=true").

Since 2.4: New Method keepPopulationSizeConstant(boolean) in class org.jgap.Configuration

The new method keepPopulationSizeConstant(boolean) allows to keep the population size constant after each single evolution, even if no appropriate NaturalSelector has been registered with the Configuration to be executed as postprocessor. The population size will be kept constant to the size specified with Configuration.setPopulationSize(int).

Since 2.4: Extended interface org.jgap.Gene

In interface org.jgap.Gene two new methods have been introduced: Object getApplicationData() and boolean isCompareApplicationData(). You could easiest adapt your existing Gene implementations without further modifications if you extended them from org.jgap.BaseGene.

Since 2.4: Gene implementations: m_value is private

For all  implementations of interface org.jgap.Gene their variable Object m_gene was made private (it was protected before). Now use the more sophisticated methods getAllele() and setAllele(Object) instead. Reason for this change was the need of registering when the allele value changed..

Since 2.6: Supergene-related classes capitalized

All names of classes related to supergenes have been capitalized. Each class name should begin with a capital letter!

Since 2.6: Configuration must be set before calling Gene.setAllele or applyMutation

As setAllele and applyMutation (and possibly other methods) in Gene classes may call mapToValueWithinBounds, which in turn accesses the configuration via Genotype.getConfiguration, the configuration must be set before the call to setAllele, applyMutation and possibly other methods. However, this should be good practice! 

Since 2.6: Several fields private instead of protected

These fields are Genotype.m_population, Chromosome.m_genes, Genotype.m_activeConfiguration, CrossoverOperator.m_crossoverRate, MutationOperator.m_mutationRate, IntegerGene.m_upperBounds, IntegerGene.m_lowerBounds, DoubleGene.m_upperBounds and DoubleGene.m_lowerBounds. Use setters resp. constructors instead!

Since 2.6: Method(s) Genotype.randomInitialGenotype

The above method now uses the sample Chromosome provided with the Configuration to determine the class of new Chromosomes to be created. The method with signature (Configuration, Class) has been removed for that!

Since 2.6: Gene's new method newGeneInternal()

Now the newGene() method is a template method in BaseGene calling protected method newGeneInternal. The latter needs to be implemented in all offsprings of BaseGene.

Since 2.6: Interface IGeneConstraintChecker changed

For method verify there are two new paramaters: a_chromosome and a_geneIndex.

Since 2.6: Removed method getNoFitnessValue() in class FitnessFunction

Use the constant FitnessFunction.NO_FITNESS_VALUE instead.

Final remarks

It should be quite straight forward upgrading from version 1.1 to 2.0. With version 1.0 it could be a bit more difficult, although realistic.

If you have *any* problems accomplishing this or think this documentation is incomplete or inconsistent, feel yourself required to post a message to the forum!


[Documentation Index]

SourceForge Logo