For the Elitism line 157 in ga.jl, could you utilize thefull_fitness rather than recalculate to populatefitness? This could help if your objective function is expensive.

I've seen in other GA algorithms, the fitness is kept with the individual and only recalculated if it is from a mutation or crossover.

you're absolutely right, I'm already aware of that and fixed it after doing this pull request, now the objective function is used only in thefull_fitness variable

@tpdsantos Thanks for the effort. However, can we make these changes gradually. I will not be able to review PR in this form.
Some of the things that I noticed:

• Why do you need to to create a wrapper type for mutations & etc.?
• Why the input type for mutating functions changed toBitVector? I understand change from Vector{Bool}, but why the rest?

I deliberately tried to be open-ended with the individual type, so any kind of structure can be accepted. Introducing a supertype, e.g. AbstractGene, seems like a big constraint. In any way, you would write specific mutations and recombinations for the special individual type but they would remain in functional form. This PR would require any additional individual type integrated into the package.

If you need to attach any specific information to individual, e.g.IntegerGene name value, you can create a wrapper function around your type to expose an individual structure to the already available individual modification functions. Similarly to what you do withSelection type wrapper.

@wildart thanks for the reply. I understand that there are many changes. My main reason was just to add this branch to your project to ease the creation of individual types, since I thought it was confusing and the documentation was lacking.

Following your points:

• I created the wrapper for mutations because the mutations available were for specific types of genes, and if the individual has different types of genes the mutations must be different as well. I was basically trying to not mess with thega function. regarding the wrapper around theIntegerGene, I wanted to give the user the ability to easily change the mutation functions BEFORE entering thega function. My main goal was to compile all that I could before running the algorithm itself and not evaluate the mutation symbol in each iteration.
• I actually only changed theVector{Bool} types forBitVector

Anyway, I understand that it can't be done now. I'm still working on this branch, since I want to add more functionalities for parallelism, working out-of-the-box with external programs and easily integrate the code with clusters. If I have time I'll try to make it even more general.

What do you think the branch needs to be accepted?

I wanted to give the user the ability to easily change the mutation functions BEFORE entering thega function. My main goal was to compile all that I could before running the algorithm itself and not evaluate the mutation symbol in each iteration.

Mutations is a parameter toga, you can overwritega to accept mutation symbols instead of function names, and select an appropriate function to pass to the original version ofga.

I'm still working on this branch, since I want to add more functionalities for parallelism, working out-of-the-box with external programs and easily integrate the code with clusters.

I understand that parallelism is long overdue for this package. But, initially one thing should be addressed before implementing it. In#36, I outlined that an individual initialization must be removed from the main algorithm, as it runs only one before starting main algorithm loop. That would make possible to deconstruct main algorithm to a components suitable for parallelization.

I think that specific parallel devices must be created to run parts of the algorithm in single-core, multi-core and multi-threading environments. I haven't started thought of this much. I opened a new issue to discuss the parallelization approach. See#45.