Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken counter for successful mutations in Genome.mutate() #156

Closed
HenrikMettler opened this issue Jun 23, 2020 · 3 comments · Fixed by #157
Closed

Broken counter for successful mutations in Genome.mutate() #156

HenrikMettler opened this issue Jun 23, 2020 · 3 comments · Fixed by #157
Labels
bug Something isn't working
Milestone

Comments

@HenrikMettler
Copy link
Contributor

I believe there is a problem with counting the mutations in Genome.mutate()
The counter successful_mutations increases only for mutations in the output region (see genome.py L400, L395: https://github.com/Happy-Algorithms-League/hal-cgp/blob/master/cgp/genome.py#L400). This causes the mutation_factor to be multiplied by a factor ≃ n_hidden_genes / n_output_genes (a bit lower in practice, since some hidden genes might be mutated several times)

Suggestion 1: add successful_mutations += 1 on line 400. But this causes the new issue, that also mutations that result in the same gene value are counted as successful mutations.
Suggestion 2: add a second output to _mutate_hidden_region that indicates whether there was a real change in the value of the gene (success?) and count only if a real mutation happened.

(PS. point 2 might also be necessary in _mutate_output_region as additional control for a "real" mutation)

@jakobj jakobj added the bug Something isn't working label Jun 23, 2020
@jakobj jakobj added this to the 0.1.1 milestone Jun 23, 2020
@jakobj jakobj changed the title counter for successful_mutations in Genome.mutate() Broken counter for successful mutations in Genome.mutate() Jun 23, 2020
@jakobj
Copy link
Member

jakobj commented Jun 23, 2020

Good catch @HenrikMettler 👏 👏

I think your first suggestion should be definitely implemented, regardless of the remaining issues. We should count a mutation if one was applied ;)

Regarding the second point, this requires a design decision, I don't think there's the perfect solution. I would suggest to only return from the function after a gene different from the previous one was picked, sort of while gene was not changed: mutate solution. Otherwise nothing in the dna has changed, and I would hardly count that a mutation. In general I think it would be nice if the return values of _mutate_hidden_region and _mutate_output_region to be logically similar, do you think that's possible?

I'm not sure I understand why the factor is n_hidden_genes / n_output_genes. Have you checked this numerically? Could be easily done by fixing the second point first and counting the actual number of mutations over a number of trials.

@mschmidt87
Copy link
Member

It appears to me that this commit introduced the faulty behavior:
91b62d5

@jakobj
Copy link
Member

jakobj commented Jun 29, 2020

oops, my bad, my bad 😳 thanks for finding this @mschmidt87 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants