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)
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
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!)
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
in eoPop (I had been postponing that for a long time!) which in turn required
another class of random generator (whose operator() takes an unsigned as argument)
Also added "using eo::rng" in eoRNG.h so nothing has to be modified.
We should gradually move to write eo::rng everywhere, and remove that using
directive to be almost full-proofed against possible name collision.
Also contains the class eoDynUpdater. They are eoUpdater, they receive an eoUpdatable
at construct time, and call their upate() method in their operator() method
a method called lastCall is called for everything contained in that checkpoint
(stats, updaters and monitors). This can be extremely useful
- for stateSavers (see below)
- for monitoring things like rates of success of operators, where what you
are interested in is the final result only.
Added of course a virtual method lastCall that does nothing by default in classes
eoBaseStat, eoBaseSortedStat, eoUpdater and eoMonitor
Added a boolean to control the save of the state in method eoCountedStateSaver::lastCall
so you can ask that the state is saved at final population, whatever happens.
I also added the corresponding constructor to take this into account.
I've inserted it in teh file actually - but if we go on with gnuplot,
it will need to be taken out again, and used in all other monitors
we will write using gnuplot (e.g. eoGnuplotWithErrorbarsMonitor,
eoGnuplotHistogramMonitor, ...).
and I added a boolean argument to indicate whether or not we want to
overwrite an existing file with same name (default is overwrite).
Added the getFileName accessor.
