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
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!
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);
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!
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.
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 {...}
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.
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.
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).
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.
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.
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").
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).
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.
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..
All names of classes related to supergenes have been capitalized. Each class name should begin with a capital letter!
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!
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!
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!
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.
For method verify there are two new paramaters: a_chromosome and a_geneIndex.
Use the constant FitnessFunction.NO_FITNESS_VALUE instead.
This method returns the configuration set explicitly for the Gene. This is new because in previous versions of JGAP, the configuration was a Singleton.
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]
This page is copyright © 2005-2006 Klaus Meffert, GNU free documentation license