Wrong conception of mutator

[matthieu-vergne]

Actually, the aim of the mutator operator, as it is used now, is to produce an individual which will compete with the "mutated" individual. There is no particular intention to have a "close" individual, thus the assumption that the mutant is at a distance of 1 mutation of the original is not justified. Moreover, because the use of the mutator operator necessarily (as it is implemented now) lead to have a competition between the original and the mutant, there is something more than the simple idea of producing an individual.

I would suggest to replace the concept of "mutator" by the concept of "stresser", or another one, which drops the intuition that the two individuals (the one selected and the one generated) are necessarily close to each other and at the same time illustrates the intention to make them compete afterward. This will also show clearly the fact that we are considering an exploratory-prone behaviour (with the explorator) and a converging-prone behaviour (with the stresser).

[matthieu-vergne]

And maybe the competition operator should be integrated to this Stresser operator. Considering the aim of the Stresser, it makes sense to have them together. In particular, given that a specific Stresser could stress a specific set of properties, there is no point to have a generic competition operator which aims at checking all the properties at once. The competition can be computed way faster by checking only the properties stressed. Then, one can simplify his job by implementing a single (or reduced set of) competition function(s) to reuse in each Stresser rather than implementing an operator-specific function for each Stresser.

Of course, if the different properties are influencing each other, an exhaustive function reused everywhere could be better to avoid mistakes in the evaluation.

[matthieu-vergne]

Regarding the joining stresser+evaluator, it is better to not do it. If they are joined, it conceptually allows one evaluator (associated to a given stresser) to evaluate as better an individual which would be evaluated as worse by another (associated to another stresser). Said another way, by assuming several evaluators to be "conceptually distinct" (stresser-specific) we do not enforce a consistent evaluation among them, while the evaluation is supposed to drive the overall consistently, independently of the way we browse the space.

Keeping the stresser and the evaluator separated, we assume them to be independent, and this is the responsibility of the user to introduce dependencies if he needs it. Joining them would implies the opposite, which is not what we want here. In particular, if one want to reduce the evaluation to the minimum, he can store in the mutant the original individual it is generated from and the mutator/stresser used to create it.

Also the original individual needs to be stored because otherwise it relies on the current implementation to implicitly assume it, but nothing says that it will not change one day (competitions could be made between individuals in the population in the future), so better to be rigorous from the start to avoid mistakes.

[matthieu-vergne]

Regarding the naming of the concept replacing Mutator, Improver seems to me a better candidate: the same an Explorator aims at exploring the space, but achieve it in a more or less fruitful way, an Improver aims at improving the current position in the space (in the sense of having a better evaluation), with a more or less fruitful result too.

Improver could be too generic, in the sense that an Explorator is also an improver, but with an exploration perspective. Converger could be another candidate, illustrating better the basic aim of the algorithm (converging to the best solutions). Yet it is hard to make sense of it in a situation where we consider only an initial individual to generate another one (convergence suppose there is a history behind or a target to converge to, which are not present here). At the opposite, the Explorator is an idea based on the current ability of the population to represent the overall space, which corresponds to providing the full population (which is done here). Maybe another concept could be considered, or maybe it shows that the complete function (especially the arguments) should be redefined.

Considering another point of view, the Mutator is aimed to generate an individual which will be then used in a competition, while the explorator generates an individual to which no additional operation is done (for the same round). Maybe this could explain the difficulty to find a representative concept to replace Mutator, as their is some implicit assumptions here. Maybe it also means that the output of an Explorator should be evaluated in some way before to be validated (here the validation is immediate and always granted).

[matthieu-vergne]

Maybe Competizer would be the right name. Also it is neologism, it gives the idea of "generating competitors", without the assumption of making it from the provided individual. The fact that it should be a "competitor" makes it consider anyway which could make it better.

It could be also that Competizer fits more for the function which produce the competition (returns the winner).