Also added a Ctor of variable length objects that take an eoInit.
Some day we might want to clean all that stuff ... unless we leave
the choice to the user (but then the documentation shoudl be as clear
as glass, which it is not at the moment!)
two populations, parents and offspring, and does whatever necessary.
The subclass eoPopLoopEval does the simple loop on the offspring.
eoEasyEA was subsequently modified to handle an eoPopEval passed in Ctor,
but also to encapsulate an eoEvalFunc into an eoPopLoopEval tranparently.
in order to evaluate them.
Modified eoEaseyEA accordingly - you can either pass an eoEvalFunc, as
before (it is then encapsulated into an eoPopLoopEval that does the good
old loop on the offspring - or directly pass a full eoPopEvalFunc
Small modification also in make_op_es -> keyword "none" is now recognized
for one of the crossover of either object variables or stdev's
now: eoParseTree <-- the eoParseTree class
eoParseTreeDepthInit <-- the eoParseTree depth initializer (eoGpDepthInitializer)
eoParseTreeOp <-- the operators (xover and mutation)
base documentation written for:
* eoParseTree
* eoGpDepthInitializer
* eoSubtreeXOver
* eoBranchMutation
* eoPointMutation
* eoExpansionMutation
* eoCollapseSubtreeMutation
* eoHoistMutation
I also created a group ParseTree which contains all classes related to eoParseTree
eoGpMutate.h has been removed (merged with eoParseTree operators into eoParseTreeOp
sort of the initializor vector containing all possible nodes. This sort
assures that the terminals are in the front of vector. Untill now this
was assumed but not checked or enforced.
More important, the eoRealVectorBounds, vectorized version (a vector<eoRealBounds *>
has also become an eoPersistent object and now derives from an eoRealBaseVectorBounds
class.
A useful consequence (and actual motivatino) was to be able to have soem
eoValueParam<eoRealVectorBounds> with all possibilities for input
(see doc for Lesson4 in the tutorial for the syntax).
