genCore is a part of GAF (Genetic Algorithms Framework), which is a cross-platform framework for using Genetic Algorithms for solutions. It is written in Java and uses convenient plug-in features for every phase in the genetic development, while maintaining an easy-to-use API for easy integration into applications. The genCore module is the heart of GAF, as it is the engine for the GA itself.
| Tags | Scientific/Engineering Artificial Intelligence Software Development |
|---|---|
| Licenses | BSD Revised |
| Operating Systems | OS Independent |
| Implementation | Java |
Recent releases


Changes: Circuits has been implemented and included. The TSPSolution example now supports it using the XML version of it.


Changes: The structure-based genotypes were finished. A (complicated) example can be seen in the "scheduler" project in CVS, but a TSPSolution example will be added to show how to use the structure-based genotypes. Yet another change was made in the package tree to make more sense when distinguishing between bitset-based genotypes and structure-based genotypes. Many functionalities were moved to the AbstractGenotype, and the way the VisitorsFactory worked was changed a little.


Changes: This version supports not only Bitset-based genotypes (such as the toolkit ArrayGenotype) but also a Structure-based genotypes (such as the LinkedListGenotype). In addition, the Genotype's operators have been externalized into a seperate structure to increase modularity.
- All comments
Recent commentsCircuits in genCore
Circuits is a concept I intend to add to genCore as of genCore 0.7 . This will Definetly break code. However, noone promised a stable API (until genCore 1.x anyway).
To begin with, I'll just say that this is an entire new approach to the way the genotypes in the genCore engine move around in the "circle of life". If up until now a life of a genotype was to be born, to be pushed into a pool of other genotypes, then evaluated, selected, breeded, mutated and matured and then back into the pool till the pool converges, the circuits approach is about determining the process the genotype must go through in its life.
Since the idea is being implemented using modules and connectors, it really reminded me of chips and their legs connecting them to other chips, trasferring pulses of information through them. Hence the term, "circuit-of-life", which defines the process which a genotype goes through from creation to re-evaluation.
Circuits mean that the user will determine what "stations" the genotype will pass - Be it the selection station, be it the crossover station, be it the mutation station - And how will these station aggregate the resulting genotype forward in the circuit. Meaning, if up until now I had a crossover -> mutate -> mature process, I could now make the genotype resulting from the crossover go through two different mutators, and then crossover the two resulting genotypes again and only then mutate them in a third mutator and re-evaluate them back into the pool of genotypes - And thats only one example out of many.
Now, for some real benefits code-wise. With Circuits:
* Monitoring the progress of the genetic algorithm process is made easy: By registering as a listener to the stations in the circuit, and getting events on the arrival of new objects to them or the release of a resulting object, or even on the progress of the change while inside the station.
* The decoupling between the genotypes and their respective operators is complete now: Crossover, Mutate, Mature, Fitness and Probability are no longer part of the genotype structure; The same goes for the Selection operator in the population structure.
* The Cycle operators in the nature structure and population structure are now represented by the circuit-of-life, hence made obsolete. In fact, the entire nature structure is now made obsolete, as it is now represented fully by the Circuit.
* Each station is initialized with the data it needs and is pushed with the values needed to be calculated (be it the Genotype to be mutated or the Population to be selected from). This makes the GenotypeDescriptor and SolutionDescriptor structures obsolete.
* The way circuits are constructed is very generic. Because of that, XML and XSD files are actually "crying" to be used here. Using XML files instead of Descriptor classes would simplify the code and reduce the need for rebuilds when changes occur in the stations (today, every change to the Descriptors or Solver requires a rebuild).
* Using XML could be even simplified by creating a common GUI which would use reflection to know the additional initialization parameters needed for each station, and which could monitor a genotype as it passes through the circuit-of-life, and eventually create an XML file to describe that circuit.
If any question rise about this subject, I'd be happy to answer them. Please, post them in the forums.
AviadBD.