danielkelshaw / pyga Goto Github PK

At the moment it is very much up to the user to define which function they want to optimise - it would be fairly trivial to include a selection of test functions which the user can implement with ease.

At the moment the parents are chosen at random from the population - this does not push the population towards the optimum position in any way. There are various methods for selection which will improve upon the current implementation - these shall be implemented as classes that the user can assign to the SOGA object at a later stage.

Selection Methods:

• Tournament Selection
• Truncation Selection
• Fitness-Proportionate Selection

The README.md should provide a good overview of the capabilities / aims of the project as well as provide some basic implementation details such as some usage examples.

At the moment the main source of recombination comes from crossover methods.

There are various other ways in which parents can be recombined in order to produce the children - these are more generally known as: recombination methods.

Examples to Implement:

• Line Recombination
• Intermediate Recombination

It could be very useful for the user to be able to visualise the performance of the optimiser by looking at how the optimum position has changed as the number of iterations increases.

There are various new features which can be added to the README.md:

• Tracking history of optimisation run
• Plotting capabilities / Plot Designer
• Printing of Individual to show position / fitness
• Customising termination criterion

It may be useful to provide a Dockerfile to allow for easy development within a range of different environments.

At the moment there is no option to impose any constraints on the optimiser and this can limit how useful the tool is. In many real-world scenarios, objective functions are subject to a whole host of constraints and as such it would be appropriate to develop a ConstraintHandler which takes these into account.

At the moment there is a single SOGA class which is running one example of a genetic algorithm. The main focus of development so far has been to abstract the other sections of the code so that they can be customised with ease - now that is complete it is time to start looking at alternate implementations of genetic algorithms, and these could all build very nicely from a BaseGeneticAlgorithm class.

the strong == in the dependencies makes installing this package quite difficult

There are various scenarios in which the user may benefit from running the optimiser a single iteration at a time, for example using an external method of assigning fitness etc. This will not change the functionality of the optimiser but acts as an additional interface that the user has access to.

In the current implementation of SOGA the termination check is managed by the code:

This is perfectly functional but it would be valuable to allow the user to easily define alternate termination criteria, such as:

• Number of allowable function calls.
• Total elapsed time.
• Global optimum position reached.

Initialise the repository with the relevant requirements / testing facilities.

In recent development certain aspects have not been as well documented as they perhaps should be - there should be a doctoring available for all code.

Essentials of Metaheuristics: Algorithm 20

The first Genetic Algorithm (GA) to be implemented should be the standard single-objective case - this will allow a class structure to be built and this can be furthered as additional implementations are later developed.

The library has reached a milestone now and is fully functional as a GA - the next step should be to publish this on PyPI for others to use.

This is Algorithm 34 in the Essentials of Metaheuristics book.

The history of the optimisation procedure should be recorded in the event that the user wants to further investigate the results of the optimisation procedure. Having the history of the optimisation procedure available also enables #10 to be fulfilled with relative ease.

It could prove useful to provide the ability to name the parameters used in the optimisation process when passing in the upper and lower bounds of the search space - this would make referring back to an Individual's position much more intuitive.

One particularly prevalent genetic algorithm is the 'Genetic Algorithm with Elitism' - this is founded on maintaining a proportion of the population as being elites - these are then used for crossover. This is known to be a particularly powerful implementation that can rapidly optimise objective functions.

Once the working in developing a BaseGeneticAlgorithm class is complete, as per #34, this should not be too challenging to implement.

All other aspects of the GA have been abstracted such that new implementations can be constructed from a base template - the mutation should be no different.

This is Algorithm 35 in the Essentials of Metaheuristics book.

A Genetic Algorithm works on the basis of evolving a population of individuals - it would be wise to develop a class, Individual that holds all of the relevant information for these population members.

In multiple tests there exist tests to ensure that sets of parameters are identical, eg:

This can be reduced to a single line:

total_parent_set = set(parent_a.position) | set(parent_b.position)

It's a simple change but reduces the amount of unnecessary code.

At the moment the only crossover method implemented is: One-Point Crossover. This is entirely functional but there are various others that the user may want to implement.

Crossover Methods:

• Bit-Flip
• K-Point Crossover
• Uniform Crossover