-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...
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.
This impacts on many files, creating new entries in src (the old ones are moved
to obsolete dir), modifying t-eoSymreg.cpp and t-eobin.cpp in test,
as well as gprop.cc and mastermind.cc in app dir (not to mention almost all
files in tutorial:-(
