It is no longer derived from eoPop, it now gets a destination population.
This saves a lot of copying. The semantics has changed a little as well. It is
now an _infinite_ iterator. operator++ will *not* dispense new individuals, but
will merely stay at the end. To get a new indy, use operator*() as before.
eoEasyEA now checks the checkpoint *after* making a generation and clears the offspring
eoGeneralBreeder is changed to reflect the changes in eoPopulator
eoSequentialSelect now uses setup() rather than init()
To be able to use the primitive std::generate function, added a
set of wrappers in eoSTLFunctor.h that have the copy semantics most
STL functions expect (namely pass-by-value rather then pass-by-reference).
Updated test/Makefile.am to also test t-eoRandom
Also: introducing eoRndGenerators.h for eoRndGenerator derived classes:
eoNormalGenerator
eoUniformGenerator
eoBooleanGenerator
eoNegExpGenerator
Note the suffix that are added to aid in determining what these classes do
2 new important classes: eoPerf2Worth and eoSelectFromWorth
Instances of eoPerf2Worth are eoRanking and eoLinearFitScaling.
Coming soon (piece of cake now) are the niching strategies (sharing, clearing)
(a comment starting with // before the class definition is not taken into account)
Also updated the initial overall comment -
and waouw, doxygen generates links there, too! Cool.
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)
-Pvalue
This will now produce 'value'. The buggy parser would parse 'alue' here. I am truly and deeply
ashamed to have created such an off-by-one error.
Marc assumed this was wanted behaviour (so that it should read: -P=value)
I must admit that this is a logical conclusion, though it was merely a side-effect
of the error. To not force Marc to rewrite the tutorial and his way of working with
EO, I decided to make a feature out of the bug, so that now the parser will parse:
-Pvalue
-P=value
and of course the true and blue:
-Parameter=value
I will now go and check if I sent out some crappy papers caused by this bug (as I've been using eo!)
make check
Command I picked up in the automake documentation (RTFM, you know)
Tagged a lot of header functions in the GnuPlot files with 'inline',
so they can be used from more than one sourcefile.
Ok, now the interesting news. Started a new library libga (not to be confused
with Matthew's GaLib). Here I suggest we put a fairly complete and configurable
genetic algorithm. Just to see how far we can stretch ourselves and also to have
a GA-componenent that can be used in other applications without having to rebuild
the entire thing. test/t-eoGA.cpp tests this library
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
