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

Invalidate fitness for individuals in the history #139

Open
fmder opened this issue Jun 1, 2016 · 3 comments
Open

Invalidate fitness for individuals in the history #139

fmder opened this issue Jun 1, 2016 · 3 comments

Comments

@fmder
Copy link
Member

fmder commented Jun 1, 2016

Just after the deepcopy in History.update(), the individuals fitness should be invalidated to avoid confusion as to their validity.

@fmder fmder added this to the 1.1.0 milestone Jun 1, 2016
@jkpaulin
Copy link

jkpaulin commented Aug 17, 2018

I attempted to apply the suggested fix, but neither invalidating fitness of the original individual, nor the copy achieved the desired result. Deleting the fitness of the copy results in no fitness values being stored in the history at all. Deleting the fitness of the original does not prevent the surprising result that we see individuals in the history with different genomes, but identical fitness values (to 15 decimal places). A minimal example:

pop = toolbox.population(n=10)
hist = tools.History()
hist.update(pop)
...
pop, logbook = algorithms.eaSimple(pop, ...)
...
for a,b in zip([hist.genealogy_history[k] for k in hist.genealogy_history],
[hist.genealogy_history[k].fitness for k in hist.genealogy_history]):
        print a,b

Example output demonstrating that the third and fourth items have different genomes, but identical fitnesses.

[1, 3, 7, 300, 0, 15, 9, 7, 5, 5, 5, 7, 2, 9, 112] (-11.923277001181246,)
[1, 3, 7, 300, 0, 15, 9, 7, 5, 5, 5, 7, 2, 9, 112] (-13.263357290736487,)
[1, 3, 7, 300, 0, 15, 9, 7, 5, 5, 5, 7, 2, 9, 112] (-13.263357290736487,)
[1, 3, 7, 44, 0, 9, 6, 4, 5, 5, 9, 7, 6, 9, 100] (-13.263357290736487,)

I have only tested this under the eaSimple algorithm.

@fmder
Copy link
Member Author

fmder commented Aug 19, 2018

The proposed fix implies that the individuals will not have a valid fitness in the history. An extension of the fix would require to have a decorator for the evaluation that also sets the fitness in the history.

@jkpaulin
Copy link

Thank you @fmder . I've worked around the problem by using the Hall of Fame functionality. Losing fitness information from History seems a shame, as the graph output is excellent, however the current behaviour caused me quite a bit of confusion, and risked invalidating my experiment - it wasn't obvious that I should not trust the fitness values from the History. I'm a beginner with DEAP so I'm afraid I don't feel able to offer a patch with your suggested enhanced fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants