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
eoBestSelect always return the best individual
eoSequentialSelect a selectOne version of eoDetSelect (uses an index to
return next offspring from sorted pop)
Moreover, I got fed up with error due to const/non const, so I modified
PipeComSend to take a const argument. THe consequence is that it will not run
under plain C any more.
every generation) which is different from the continuous monitoring (same file/plot is
angemented every generation).
This lead to a number of modifications in many files in utils dir
But now we can watch on-line
- fitness spreadout
- FDC plots
- multi-objective Pareto fronts (though the multi-objective sruff isn't there yet!)
The former simply set values to the boundary values in case they are out
The latter allows to short-cut all bound-checks when no need
SOme day I will put this in utils, and have a eoRealBounds.cpp in the
pre-compiled library
but in generic format.
They are used at the omoment only in eoEsStdevXOver.h that calls a crossover
on the object variables, then a crossover on teh stdev vectors!
A piece of cake :-)
eo everything that is general to any representation
es.h everything about real representation (in es dir)
ga.h everything related to bitstring representation (in ga dir)
To be continued by gp.h, and ...
This has lead to some slight modifications in test file eobin and all tutorial
examples files...
I've also added in utils eoDistance, generic functor to compute distances,
including also the generic Euclidian distance
eo everything that is general to any representation
es.h everything about real representation (in es dir)
ga.h everything related to bitstring representation (in ga dir)
To be continued by gp.h, and ...
This has lead to some slight modifications in test file eobin and all tutorial
examples files...
