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!)
