interpretation... (Have not compiled/checked/changed paradisEO.)
That is, the current code compiles with gcc-3.4 and the checks
(besides t-MGE1bit) all pass.
in some files (and some bugs were fixed as well [Marc: eoOneToOneBreeder was a mess])
eoFunctor.h now contains static functor_category members, this shouldn't hurt anyone.
src/es/eoEsGlobalXover.h and src/es/eoEsLocalXover.h for crossover
src/es/make_XXX_es.h for user-input
test/t-eoEsAll.cpp to test
However, an old bug appeared: className was not const in eoGenOp (and derived classes)
so I had to change that throughtout the hierarchy
Changed the signature of eoMon, eoBin and eoQuadOp to return a bool,
without invalidating fitness. Added a set of invalidators to take over
that job (see for instance eoSGA and eoSGATransform how this can transparantly used)
Derived eoState from eoFunctorStore (for convenience, from a design perspective this may sound wrong)
Added a wrap_op function that does the wrapping for you (see eoOpContainer how this made this functor
exceedingly less hairy). Checked all the tests removed the eoGeneric*Op family (not needed anymore)
and of course changed all the operators to reflect the change (and found a few that didn't
invalidate the fitness, thus really pointing out the advantage of the current approach)
I also changed
- the eoQuadratic into eoQuad (as dicussed with Maarten)
- the eoBin into eoBit, with more appropriate names for the "binary"
operators (that can be unary!) as no one protested when I posted on
eodev list
