pos=networkx.graphviz_layout(graph,prog='dot'), then pass the position as the keyword argument
posto the networkx draw function.
insertmethod code https://github.com/cmd-ntrf/deap-1/blob/master/deap/tools/support.py#L539.
gp.compileADF: the docs say to put the pset that calls all the others as the last in the list of psets, but I'm finding it only works when I put the main pset first. Is the documentation backward, or am I? It does get reversed in the code, or it might relate to the order in Individual? I'm not sure too many people have used compileADF so maybe it's never been noticed or, more likely ;-) I'm just confused. Well I know that much but... just throwing it out there.
# is working for me toolbox.register("compile", compileADF, psets=[pset, adfpset]) # is not working for me toolbox.register("compile", compileADF, psets=[adfpset, pset])
algorithms.eaSimpleto stop the optimization when the evolution has stagnated/reached its solution? I'd rather it stopped when it reaches the solution after 5 generations rather than continue on to the max number of generations, without improving the solution at all. Ideally, there would be a stopping condition callback that you could provide.
make htmlfor the docs/sphinx it spat out a zillion warnings that bemoaned you need to upgrade this chunk of code to python 3—the change in syntax of around exceptions was particularly noisy. Then I realised that to install on py3 it is actually py2 code run through 2to3? I probably could get away with a documentation change, but to squelch all the warnings and just wing it—tendering a pull request which had not actually been tested on py2—was all the discouragement I needed.
@johnmee Sorry you got discouraged. I have observed what you described and have open a new issue on that matter DEAP/deap#81.
There is not much code left in DEAP that is out of the box incompatible with Python 3, and for documentation compilation the two culprits are print and exception. Print can be addressed easily, exception not so much.
I'm having "fun" with the ADF's. We're following a strict Kosa model of ADF's and Result Producing Branch (RPB), and I've had no great problems implementing dynamic numbers of ADF's in each individual such that the RPB calls the ADF's.
But I'm having difficulty getting the ADF's to refer to each other (laying them out hierarchically such that ADF0pset = primitives, ADF1pset = primitives + ADF0, ADF2pset = prims + ADF1 + ADF0... etc.) I don't see why it wouldn't work, but given how much trouble I'm having getting it right I'm starting to wonder...
@johnmee We have tried in the past to use AST module to compile GP expressions, multiple times. Each try had the same conclusion: it is slower to use AST. That said, each time we looked at AST was with the objective of reducing compile time.
The most promising solutions we have so far to improve compilation performance are using PyPy and compiling trees to bytecode directly. @mgard did some experiments with bytecode and Python, but his code has not found its way in deap's core yet. I think you can find some of his work in his deap fork.
However, you might have something else in mind when asking about AST.
@hawkerpl Object oriented is not the solution to everything. We think that functions provide much more flexibility for the algorithms and operators. Note that we use classes at many (usefull) places and even use functions as objects. We simply don't force the use of objects where it is not convenient.
For the camelCase, we chose this style because we thought it made a better separation between the prefix (cx, mut, sel, ...) than underscores:
two_point_crossover() looks kinda weird.