Giter Club home page Giter Club logo

nojhan / paradiseo Goto Github PK

View Code? Open in Web Editor NEW
93.0 10.0 35.0 1.03 GB

An evolutionary computation framework to (automatically) build fast parallel stochastic optimization solvers

Home Page: https://nojhan.github.io/paradiseo/

License: Other

Shell 0.59% C++ 77.46% C 0.61% Objective-C 0.49% Python 1.26% CSS 0.49% JavaScript 0.37% CMake 5.84% Makefile 0.08% HTML 12.31% Perl 0.03% PHP 0.10% R 0.31% Jupyter Notebook 0.07%
paradiseo solvers metaheuristics evolutionary-algorithm parallelization algorithm cpp cpp17 framework optimization

paradiseo's Introduction

Paradiseo: a Heuristic Optimization Framework

Paradiseo is an open-source full-featured evolutionary computation framework which main purpose is to help you write your own stochastic optimization algorithms, insanely fast.

It focus on the efficiency of the implementation of solvers, by providing:

  • a modular design for several types of paradigms,
  • the largest codebase of existing components,
  • tools for automated design and selection of algorithms,
  • a focus on speed and several parallelization options.
Paradiseo logo

Quick Start

Very Quick Start

  1. Use a recent Linux, like an Ubuntu.
  2. sudo apt install g++-8 cmake make libeigen3-dev libopenmpi-dev doxygen graphviz libgnuplot-iostream-dev
  3. From the Paradiseo directory: mkdir build ; cd build ; cmake -D CMAKE_BUILD_TYPE=Release -DEDO=ON .. && make -j
  4. Copy-paste this CMA-ES code in cmaes.cpp:
#include <eo>
#include <edo>
#include <es.h>
#include <do/make_pop.h>
#include <do/make_run.h>
#include <do/make_continue.h>
#include <do/make_checkpoint.h>

using R = eoReal<eoMinimizingFitness>;
using CMA = edoNormalAdaptive<R>;

R::FitnessType sphere(const R& sol) {
    double sum = 0;
    for(auto x : sol) { sum += x * x; }
    return sum;
}

int main(int argc, char** argv) {
    eoParser parser(argc, argv);
    eoState state;

    size_t dim = parser.createParam<size_t>(10,
            "dimension", "Dimension", 'd',
            "Problem").value();

    size_t max_eval = parser.getORcreateParam<size_t>(100 * dim,
            "maxEval", "Maximum number of evaluations", 'E',
            "Stopping criterion").value();

    edoNormalAdaptive<R> gaussian(dim);

    auto& obj_func = state.pack< eoEvalFuncPtr<R> >(sphere);
    auto& eval     = state.pack< eoEvalCounterThrowException<R> >(obj_func, max_eval);
    auto& pop_eval = state.pack< eoPopLoopEval<R> >(eval);

    auto& gen  = state.pack< eoUniformGenerator<R::AtomType> >(-5, 5);
    auto& init = state.pack< eoInitFixedLength<R> >(dim, gen);
    auto& pop = do_make_pop(parser, state, init);
    pop_eval(pop,pop);

    auto& eo_continue  = do_make_continue(  parser, state, eval);
    auto& pop_continue = do_make_checkpoint(parser, state, eval, eo_continue);
    auto& best = state.pack< eoBestIndividualStat<R> >();
    pop_continue.add( best );
    auto& distrib_continue = state.pack< edoContAdaptiveFinite<CMA> >();

    auto& selector  = state.pack< eoRankMuSelect<R> >(dim/2);
    auto& estimator = state.pack< edoEstimatorNormalAdaptive<R> >(gaussian);
    auto& bounder   = state.pack< edoBounderRng<R> >(R(dim, -5), R(dim, 5), gen);
    auto& sampler   = state.pack< edoSamplerNormalAdaptive<R> >(bounder);
    auto& replacor  = state.pack< eoCommaReplacement<R> >();

    make_verbose(parser);
    make_help(parser);

    auto& algo = state.pack< edoAlgoAdaptive<CMA> >(
         gaussian , pop_eval, selector,
         estimator, sampler , replacor,
         pop_continue, distrib_continue);

    try {
        algo(pop);
    } catch (eoMaxEvalException& e) {
        eo::log << eo::progress << "STOP" << std::endl;
    }

    std::cout << best.value() << std::endl;
    return 0;
}
  1. Compile it with: c++ cmaes.cpp -I../eo/src -I../edo/src -DWITH_EIGEN=1 -I/usr/include/eigen3 -std=c++17 -L./lib/ -leo -leoutils -les -o cmaes
  2. ./cmaes -h

Not-so-quick Start

  1. Use your system of choice, as soon as you know how to operate a C++ buildchain on it.
  2. Dependencies are: libeigen3-dev libopenmpi-dev doxygen graphviz libgnuplot-iostream-dev (or similar packagesnames, depending on your system)
  3. From the Paradiseo directory, within a build directory, call the equivalent of cmake -D CMAKE_BUILD_TYPE=Release -DEDO=ON .., then call your system's favorite generator (see cmake's documentation for the -G option).
  4. Code your own algorithm, starting from one of the numerous examples (or tests) available around ParadisEO (see the source code in <module>/test/ or <module>/tutorial/, or see the website).
  5. Build it, indicating where to include the needed ParadisEO <module>/src/ directories, and the build/lib directory for the library linker.

Rationale

Black-box and Gray-box Optimization Problems

Paradiseo targets the development of solvers for mathematical optimization problems for which you cannot compute gradients. The classical use case is the automated design or configuration of some system which is simulated.

Metaheuristics / Evolutionary Algorithms

Paradiseo targets the design of metaheuristics solvers using computational intelligence methods, a subdomain of artificial intelligence.

Why choosing Paradiseo?

Learning a full-featured framework like Paradiseo very often seems overkill. However, we would like to stress out that you may forget some points while jumping to this conclusion.

Paradiseo provides the largest mature codebase of state-of-the-art algorithms, and is focused on (automatically) find the most efficient solvers.

The most classical impediment to the use of Paradiseo is that you just want to check if your problem can actually be solved with heuristics. You feel that it would be a loss of time to learn complex stuff if it ends being useless.

However, you should keep in mind that:

  • Metaheuristics do seem very easy to implement in textbooks, but the state-of-the art versions of efficient algorithms can be a lot more complex.
  • It is usually easy to get something to actually run, but it is far more difficult to get an efficient solver.
  • Metaheuristics performances on a given problem are very sensitive to small variations in the parameter setting or the choice of some operators. Which render large experimental plans and algorithm selection compulsory to attain peak efficiency.

Fortunately, Paradiseo have the largest codebase of the market, hardened along 20 years of development of tens of solvers. Additionally, it provides the tools to rapidly search for the best combination of algorithms to solve your problem, even searching for this combination automatically.

Paradiseo is the fastest framework on the market, which is a crucial feature for modern and robust approach to solver design and validation.

Another classical criticism against Paradiseo is that C++ is hard and that a fast language is useless because speed is not a concern when your objective function is dominating all the runtime.

However, we argue that:

  • During the design phase of your solver, you will need to estimate its performance against synthetic benchmarks that are fast to compute. In that case, fast computation means fast design iterations. And it's even more true if you plan to use automated design to find the best solver for your problem.
  • Modern C++ makes use of the very same high-level abstractions you would find in more accepted languages like Python. Sure, the syntax is cumbersome, but you will not see it after a while, given that you will work at the algorithm level.
  • C++ provides full type checking and the largest set of tooling for any modern language, which are your first line of defense against long-term bugs. Sure, it sometimes gives you the impression that you fight against the compiler, but chasing subtle interface bugs across a complex Python code is even harder.

Features

Component-based Design

Designing an algorithm with Paradiseo consists in choosing what components (called operators) you want to use for your specific needs, just as building a structure with Lego blocks.

If you have a classical problem for which available code exists (for example if you have a black-box problem with real-valued variables), you will just choose operators to form an algorithm and connect it to your evaluation function (which computes the quality of a given solution).

If your problem is a bit more exotic, you will have to code a class that encodes how solutions to your problem are represented, and perhaps a few more. For instance, you may want ad-hoc variations operators, but most of the other operators (selection, replacement, stopping criteria, command-line interface, etc.) are already available in Paradiseo.

Large Choice of Components

Paradiseo is organized in several modules, either providing different "grammars" for different algorithms, either providing high-level features. All modules follows the same architecture design and are interoperable with the others, so that you can easily choose the subset of features you need.

It is, for instance, easy to start with a simple local search, then add multi-objective capabilities, then shared-memory parallelization, then hybridization with an evolutionary algorithm and finally plug everything in an objective function so as to optimize the parameters with a particle swarm optimizer.

Portability

Paradiseo is mainly developed under Linux operating systems, where its dependencies and the C++ toolchain are easy to install. Recent versions have been tested with gcc and clang compilers.

Stable versions should however work on Windows and any Unix-like operating system with a standard-conforming C++ development system.

Code

The latest stable version is on the official Git repository of INRIA: git clone git://scm.gforge.inria.fr/paradiseo/paradiseo.git

Dependencies

In order to build the latest version of Paradiseo, you will need a C++ compiler supporting C++17. So far, GCC and CLANG gave good results under Linux. You will also need the CMake and make build tools.

A free working build chain under Windows seems always difficult to find. Paradiseo 2.0.1 was successfully tested with MinGW (minus the PEO module), but it's unsure if it still work for recent versions. If you managed to build under Windows, your feedback would be appreciated.

Some features are only available if some dependencies are installed:

  • Most of the EDO module depends on either uBlas or Eigen3. The recommended package is Eigen3, which enables the adaptive algorithms.
  • Doxygen is needed to build the API documentation, and you should also install graphviz if you want the class relationship diagrams.
  • GNUplot is needed to have the… GNUplot graphs at checkpoints.

To install all those dependencies at once under Ubuntu (18.04), just type: sudo apt install g++-8 cmake make libeigen3-dev libopenmpi-dev doxygen graphviz libgnuplot-iostream-dev.

Compilation

The build chain uses the classical workflow of CMake. The recommended method is to build in a specific, separated directory and call cmake .. from here. CMake will prepare the compilation script for your system of choice which you can change with the -G <generator-name> option (see the CMake doc for the list of available generators).

Under Linux, the default is make, and a build command is straitghtforward: mkdir build ; cd build ; cmake .. && make -j.

There is, however, several build options which you may want to switch. To see them, we recommend the use of a CMake gui, like ccmake or cmake-gui . On the command line, you can see the available options with: cmake -LH .. . Those options can be set with the -D<option>=<value> argument to cmake.

The first option to consider is CMAKE_BUILD_TYPE, which you most probably want to set to Debug (during development/tests) or Release (for production/validation).

Other important options are: EDO (which is false by default) and parallelization options: ENABLE_OPENMP, MPI, SMP.

By default, the build script will build the Paradiseo libraries only.

If you ENABLE_CMAKE_TESTING and BUILD_TESTING, it will be the tests, which you can run with the ctest command.

If you ENABLE_CMAKE_EXAMPLE, it will also build the examples.

If may want to make build scripts more verbose (especially when building the doc) by enabling CMAKE_VERBOSE_MAKEFILE.

Licenses

Paradiseo is distributed under the GNU Lesser General Public License and the CeCILL license (depending on the modules).

Note that those licenses places copyleft restrictions on a program created with Paradiseo, but does not apply these restrictions to other software that would links with the program.

Documentation

Paradiseo has a lot of documentation! You will find in the source repository a lot of examples, the tutorials and you can generate the API documentation (make doc, then open paradiseo/<build>/<module>/doc/html/index.html).

Tutorials are located in each module's directory. For example for the EO module: paradiseo/eo/tutorial. A lot of examples for (almost) each class are available in the test directories (e.g. paradiseo/eo/test). Example problems and bindings to external benchmark libraries are in paradiseo/problems.

For academic articles, books, more tutorials, presentations slides, real life example of solvers and contact information, please see the web site (available in paradiseo/website/index.html).

There is also an online wiki

Contact

For further information about ParadisEO, help or to report any problem, you can send an e-mail to: [email protected]

paradiseo's People

Contributors

aaziz-alaoui avatar aquemy avatar bertheasleo avatar jdreo avatar jokuha avatar joostdsj avatar lucasmpavelski avatar nojhan avatar potalas avatar psaveant avatar ropinho avatar scicomath avatar sverel avatar tlasnier avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

paradiseo's Issues

Homogénéisation de l'arborescence

Les différents modules utilisent différentes arborescences pour organiser le code.

C'est peu lisible et il deviens difficile de parcourir le code.

Harmoniser les arborescences, en utilisant un découpage similaire à celui de la documentation (variateurs, continuateurs, algos, etc., cf. MOEO)

‘make_from_tuple’ is not a member of ‘std’

Hello, I built and installed paradiseo-3.0.0-beta and now I am having a problem trying to build my own code. Examples below.

CMakeList.txt:

cmake_minimum_required(VERSION 3.5)

project(knapsack-paradiseo LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

add_executable(knapsack-paradiseo main.cpp)

main.cpp:

#include <stdexcept>  // runtime_error
#include <iostream>    // cout
#include <strstream>  // ostrstream, istrstream

#include <paradiseo/eo/eo>
#include <paradiseo/eo/eoSGA.h>
#include <paradiseo/eo/ga/eoBit.h>
#include <paradiseo/eo/eoPop.h>
#include <paradiseo/eo/eoEvalFuncPtr.h>
#include <paradiseo/eo/utils/eoRndGenerators.h>

using namespace std;

typedef eoBit<double> Indi;

double binary_value(const Indi & _indi)
{
 double sum = 0;
 for (unsigned i = 0; i < _indi.size(); i++)
     sum += _indi[i];
 return sum;
}

int main()
{
    const unsigned int SEED = 42;          // seed for random number generator
    const unsigned int T_SIZE = 3;        // size for tournament selection
    const unsigned int VEC_SIZE = 8;    // Number of bits in genotypes
    const unsigned int POP_SIZE = 20;  // Size of population
    const unsigned int MAX_GEN = 100;  // Maximum number of generation before STOP
    const float CROSS_RATE = 0.8;          // Crossover rate
    const double P_MUT_PER_BIT = 0.01; // probability of bit-flip mutation
    const float MUT_RATE = 1.0;              // mutation rate

    rng.reseed(SEED);

    // Evaluation: from a plain C++ fn to an EvalFunc Object
    eoEvalFuncPtr<Indi> eval(binary_value);

    eoPop<Indi> pop;
    for (unsigned int igeno=0; igeno<POP_SIZE; igeno++)
     {
         Indi v;                    // void individual, to be filled
         for (unsigned ivar=0; ivar<VEC_SIZE; ivar++)
             {
                 bool r = rng.flip(); // new value, random in {0,1}
                 v.push_back(r);          // append that random value to v
             }
         eval(v);                                // evaluate it
         pop.push_back(v);              // and put it in the population
     }
     // sort pop before printing it!
     pop.sort();
     // Print (sorted) intial population (raw printout)
     cout << "Initial Population" << endl;
     cout << pop;


    return 0;
}

The cmake .. command output is:

$ cmake ..
-- The CXX compiler identification is GNU 11.2.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/filipe/Desenvolvimento/knapsack-paradiseo/build

and the make output is:

$ make -j
[ 50%] Building CXX object CMakeFiles/knapsack-paradiseo.dir/main.cpp.o
In file included from /usr/include/c++/11.2.0/backward/strstream:50,
                 from /home/filipe/Desenvolvimento/knapsack-paradiseo/main.cpp:3:
/usr/include/c++/11.2.0/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp]
   32 | #warning \
      |  ^~~~~~~
In file included from /usr/local/include/paradiseo/eo/eo:164,
                 from /home/filipe/Desenvolvimento/knapsack-paradiseo/main.cpp:5:
/usr/local/include/paradiseo/eo/eoForge.h: In member function ‘Op* eoForgeOperator<Itf, Op, Args>::op_constructor(T&)’:
/usr/local/include/paradiseo/eo/eoForge.h:150:32: error: ‘make_from_tuple’ is not a member of ‘std’
  150 |             return new Op(std::make_from_tuple<Op>(args));
      |                                ^~~~~~~~~~~~~~~
/usr/local/include/paradiseo/eo/eoForge.h:150:32: note: ‘std::make_from_tuple’ is only available from C++17 onwards
/usr/local/include/paradiseo/eo/eoForge.h:150:50: error: expected primary-expression before ‘>’ token
  150 |             return new Op(std::make_from_tuple<Op>(args));
      |                                                  ^
/usr/local/include/paradiseo/eo/eoForge.h: In member function ‘void eoForgeVector<Itf, Enable>::add(Args ...)’:
/usr/local/include/paradiseo/eo/eoForge.h:267:56: error: ‘decay_t’ is not a member of ‘std’; did you mean ‘decay’?
  267 |             auto pfo = new eoForgeOperator<Itf,Op,std::decay_t<Args>...>(
      |                                                        ^~~~~~~
      |                                                        decay
/usr/local/include/paradiseo/eo/eoForge.h:267:56: error: ‘decay_t’ is not a member of ‘std’; did you mean ‘decay’?
  267 |             auto pfo = new eoForgeOperator<Itf,Op,std::decay_t<Args>...>(
      |                                                        ^~~~~~~
      |                                                        decay
/usr/local/include/paradiseo/eo/eoForge.h:267:68: error: template argument 3 is invalid
  267 |             auto pfo = new eoForgeOperator<Itf,Op,std::decay_t<Args>...>(
      |                                                                    ^
/usr/local/include/paradiseo/eo/eoForge.h: In member function ‘void eoForgeVector<Itf, Enable>::setup(size_t, Args ...)’:
/usr/local/include/paradiseo/eo/eoForge.h:295:56: error: ‘decay_t’ is not a member of ‘std’; did you mean ‘decay’?
  295 |             auto pfo = new eoForgeOperator<Itf,Op,std::decay_t<Args>...>(
      |                                                        ^~~~~~~
      |                                                        decay
/usr/local/include/paradiseo/eo/eoForge.h:295:56: error: ‘decay_t’ is not a member of ‘std’; did you mean ‘decay’?
  295 |             auto pfo = new eoForgeOperator<Itf,Op,std::decay_t<Args>...>(
      |                                                        ^~~~~~~
      |                                                        decay
/usr/local/include/paradiseo/eo/eoForge.h:295:68: error: template argument 3 is invalid
  295 |             auto pfo = new eoForgeOperator<Itf,Op,std::decay_t<Args>...>(
      |                                                                    ^
make[2]: *** [CMakeFiles/knapsack-paradiseo.dir/build.make:76: CMakeFiles/knapsack-paradiseo.dir/main.cpp.o] Erro 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/knapsack-paradiseo.dir/all] Erro 2
make: *** [Makefile:91: all] Erro 2

It is like the paradiseo compilation is not supporting the make_from_tuple function, despite the building and installation of the framework was correct.

Well, any idea about what is happening here?

All the best;

Correct location for contributions

Just a doubt, this Paradiseo Github repository has a lot of contributions but there is an Paradiseo repository at INRIA Gitlab.

I would like to know if this github repository is the 'correct' place for contributions and/or if the repository at INRIA is just like a mirror.

Maybe this info could be more clear at README and project website.

All the best!

Transformer eoLogger en stream standard

La classe eoLogger n'est pas un ostream.

Ceci empêche de la rediriger facilement vers un fichier.

Refactoriser la classe pour l'inclure dans l'arbo STL des streams.

Exposer le calcul incrémental de la variance dans eo

Calculer la variance incrémentalement peut être utile (notamment dans mo), or c'est ce qui est fait dans eo mais en interne (eoSecondMomentStats).
Il faudrait rendre l'algorithme réutilisable, en le faisant s'appliquer sur des EOT et non des pop, afin de pouvoir le réutiliser à la fois dans le calcul de la variance sur des pop et dans mo.

Initial parallel `full` build uses excessive memory

I just cloned the repo and, following the INSTALL instructions, started doing a full-Type build, i.e. I did

mkdir build
cd build
cmake .. -DINSTALL_TYPE=full
make -j

Notice that I appended the -j switch to my make call in order to parallelize the build (if possible). This will use as the same number of make (compilation) threads as there are (logical) processors available. In my case, that is 4.

This works rather well initially, but I quickly noticed a massive increase in memory (RAM) usage. My system could cope for a while by swapping out some of the data, but at some point both physical memory and swap were completely full. The kernel was beginning to do out-of-memory process kills, but everything had slowed down so much that I just hard-reset my machine.

Now, a normal (non-parallel) build works fine, so this is nothing critical. And I also do not know if this is a problem with Cmake/Make in general or related specifically to the ParadisEO project layout.

I just wanted to make you aware that such an issue may arise on some systems, and might warrant some kind of investigation. For comparison, I'll attach my relevant system data below.

I will be able to provide test data from another system (specifically one with more RAM) next weekend.


  • CPU: Intel(R) Core(TM) i5-2557M CPU @ 1.70GHz (two physical cores with two "threads" each, i.e. 4 logical cores exposed; current kernel dynamically scales freq up to 2.7GHz)
  • Mem: 4GB physical RAM, 4GB swap partition
  • OS: Xubuntu 13.04 x64 (up-to-date) with Kernel 3.11.0-031100-generic #201309021735 SMP from the ubuntu-mainline kernel ppa
  • Tool versions:
    • cmake version 2.8.10.1
    • GNU Make 3.81
    • gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) (Thread model: posix)

If you'd like more data, please let me know.

The tutorial link is broken

The tutorial is hosted on paradiseo.gforge.inria.fr which is not maintained anymore.
Could someone move the tutorial to other place, for example Github wiki?

Bug on MO tests, is not running

Tests running in mo module returns the same result (error):

When running the t-moAdaptiveWalkSampling.cpp test file, output is:

./t-moAdaptiveWalkSampling.cpp: line 1: /bin: Is a directory
./t-moAdaptiveWalkSampling.cpp: line 2: syntax error near unexpected token `newline'
./t-moAdaptiveWalkSampling.cpp: line 2: `<t-moAdaptiveWalkSampling.cpp>'


Whe running the t-moDynSpanCoolingSchedule.cpp test file, the output is:

./t-moDynSpanCoolingSchedule.cpp: line 1: /bin: Is a directory
./t-moDynSpanCoolingSchedule.cpp: line 2: syntax error near unexpected token `newline'
./t-moDynSpanCoolingSchedule.cpp: line 2: ` <t-moDynSpanCoolingSchedule.cpp>'

When running the t-moIndexedVectorTabuList.cpp test file, output is:

./t-moIndexedVectorTabuList.cpp: line 1: /bin: Is a directory
./t-moIndexedVectorTabuList.cpp: line 2: syntax error near unexpected token `newline'
./t-moIndexedVectorTabuList.cpp: line 2: ` <t-moIndexedVectorTabuList.cpp>'


When running the t-moRndIndexedVectorTabuList.cpp test file, output:

./t-moRndIndexedVectorTabuList.cpp: line 1: /bin: Is a directory
./t-moRndIndexedVectorTabuList.cpp: line 2: syntax error near unexpected token `newline'
./t-moRndIndexedVectorTabuList.cpp: line 2: ` <t-moIndexedVectorTabuList.cpp>'

Réorganiser les headers

Les headers sont tous indépendants et sont inclus directement :

#include <eo>

Pour éviter des conflits de nommage, il faudrait les inclure via un répertoire intermédiaire :

#include <paradiseo/eo>

De même, les inclusions dans les fichiers même des modules se font souvent en path absolu :

#include <continue/moeoHypContinue.h>

mais devraient se faire en relatif :

#include "../continue/moeoHypContinue.h"

Eompi: failed tests

Well, I'm having some troubles when executing eompi tests with ctest command.
Here the exceptions I've got :

      Start 42: t-mpi-parallelApply
42/45 Test #42: t-mpi-parallelApply ..............***Exception: Other  0.04 sec
      Start 43: t-mpi-wrapper
43/45 Test #43: t-mpi-wrapper ....................***Exception: Numerical  0.02 sec
      Start 44: t-mpi-multipleRoles
44/45 Test #44: t-mpi-multipleRoles ..............***Exception: Other  0.04 sec
      Start 45: t-mpi-distrib-exp
45/45 Test #45: t-mpi-distrib-exp ................***Exception: Other  0.03 sec

The following tests FAILED:
     42 - t-mpi-parallelApply (OTHER_FAULT)
     43 - t-mpi-wrapper (NUMERICAL)
     44 - t-mpi-multipleRoles (OTHER_FAULT)
     45 - t-mpi-distrib-exp (OTHER_FAULT)
Errors while running CTest

Plus, t-mpi-eval and t-mpi-multistart never end.

Correction du parsing de eoParser

Le eoParser n'accepte que les arguments du type --arg=value.

Cela ne respecte pas les standards GNU (--arg value, notamment).

Corriger la classe pour supporter un parsing POSIX/GNU.

[Feature Request] An abstraction for eoSGA operator()

eoSGA

eoSGA provides simplicity, but not freedom to implement the genetic algorithm internally, for this there are other features with higher learning curve.

My idea for this feature is:

A derived class from eoSGA that provides the possibility to implement its own operator()(eoPop<EOT>&).

In this case the class would get a pointer to a function implemented by user that uses the eoSGA attributes, and the operator() of the class would call this function.

OBS: the access to eoSGA attributes should be changed to protected.

Derived class from eoSGA

Example:

template <class EOT>
class ExampleGA : protected eoSGA<EOT> {
public:
    ExampleGA (/* {eoSGA args} */, void (* _func)( eoSgaArgs, eoPop<EOT>& ))
    : eoSGA<EOT>( eoSgaArgs ), implFunc(_func) {}

    void operator()(eoPop<EOT>& _pop) {
        (*implFunc)(eoSgaArgs, _pop);
    }
    
protected:
    /*same protected attributes */
    void (* implFunc)( eoSgaArgs, eoPop<EOT>& );
}

Considering eoSgaArgs as all args that get from eoSGA class.

The objective of this would be provides more freedom and flexibility on internal implementation to genectic algorithm. This way is the better way to create the your own GA if you want freedom to implement, without need learn an amount of classes implementation.

What you think?

Paquetages Debian

Mettre à jour la config CPack pour créer des paquetages debian.

Framework for tests

Hi,

Tests are very important to verify the software quality and let the users comfortable.
I think more modern tests can turn a more reliable framework. There are several libs and frameworks for tests in C++. Googletest and Doctest, both ate easier to implement and macro-based tests cases.

Mettre à niveau les do/make*

Les scripts en make_* dans les répertoires do/ sont rarement mis à jours au vu des nouvelles fonctionnalités du framework.

Nettoyer les fonctionnalités désuètes et ajouter les plus modernes.

Sémantique des foncteurs

L'arborescence des foncteurs ne porte pas de sémantique quand à l'utilisation des sous-classes.

Ceci empêche la composition automatique d'opérateurs.

Homogénéiser la hiérarchie de classes des foncteurs à travers les modules (par exemple, MOEO n'utilise pas les foncteurs EO).

Injecter des classes intermédiaires portant la sémantique des opérateurs du framework (sélecteur, variateurs, remplaceurs, continuateurs, etc.).

Bug Report: Compilation of es module

When compiling es target on eo module, std::string is not recognized as a type.

On eoFunctor.h file, std::string is referenced but not is included.

The error log on cmake -DCMAKE_BUILD_TYPE=Release -DEO_ONLY=ON:

Scanning dependencies of target es
[ 23%] Building CXX object eo/src/es/CMakeFiles/es.dir/make_algo_scalar_es.cpp.o
[ 25%] Building CXX object eo/src/es/CMakeFiles/es.dir/make_algo_scalar_real.cpp.o
[ 26%] Building CXX object eo/src/es/CMakeFiles/es.dir/make_checkpoint_es.cpp.o
[ 28%] Building CXX object eo/src/es/CMakeFiles/es.dir/make_checkpoint_real.cpp.o
[ 30%] Building CXX object eo/src/es/CMakeFiles/es.dir/make_continue_es.cpp.o
In file included from /tmp/paradiseo/paradiseo-master/eo/src/es/../do/../eoContinue.h:28,
                 from /tmp/paradiseo/paradiseo-master/eo/src/es/../do/../eoCombinedContinue.h:33,
                 from /tmp/paradiseo/paradiseo-master/eo/src/es/../do/make_continue.h:37,
                 from /tmp/paradiseo/paradiseo-master/eo/src/es/make_continue_es.cpp:44:
/tmp/paradiseo/paradiseo-master/eo/src/es/../do/../eoFunctor.h:63:18: error: ‘string’ in namespace ‘std’ does not name a type
   63 |     virtual std::string className() const { return "unknown";}
      |                  ^~~~~~
/tmp/paradiseo/paradiseo-master/eo/src/es/../do/../eoFunctor.h:31:1: note: ‘std::string’ is defined in header ‘<string>’; did you forget to ‘#include <string>’?
   30 | #include <functional>
  +++ |+#include <string>
   31 |

Solution:
Add #include <string> on eoFunctor.h file

Découplage de modules

Les modules eoserial et eompi sont actuellement des sous-répertoires du module eo/.

Les sortir dans des modules à part.

Site web

Fusionner les sites web de ParadisEO et de EOdev en un seul site.

Utiliser la documentation comme base des pages.

ParadiseO, not rcognized

@nojhan

Despite installing ParadiseO on my linux machine, using the .deb from the web site, the compiler doesn't recognize the package.

Machine

Linu:: Ubuntu:: 18.04 LTS

ParadiseO verion:: 2.0

even when adding it to the includePath, it still doesn't work.

Screenshot from 2020-05-24 19-29-26

Découplage PSO

Certaines classes dans EO implémentent des algos PSO, avec un typage de template dédié.

Or, EO ne devrait contenir que des classes à typage générique.

Découpler les classes traitant de PSO dans un module à part.

readFrom should be a free function to allow for EOT with constructors without arguments

Currently, readFrom is a member of eoSerial, thus it necessitate an existing instance to be called.
This makes constructors without parameter mandatory, and is error prone.
For instance, it allows some operators to create empty EOT instances (like when using resize) on the fly.

The fix would be to make readFrom free friend functions, in which one can instantiate with mandatory parameters, just like std::begin.

Namespaces

Remplacer le préfixage des classes par des namespaces (exemple : paradiseo::eo::Pop).

CMake error on installation

Installation using $ cmake .. and $ make install

Message error:

Install the project...
-- Install configuration: ""
-- Installing: /usr/local/share/paradiseo/eo/doc
CMake Error at eo/doc/cmake_install.cmake:41 (file):
  file INSTALL cannot make directory "/usr/local/share/paradiseo/eo/doc": No
  such file or directory
Call Stack (most recent call first):
  eo/cmake_install.cmake:42 (include)
  cmake_install.cmake:42 (include)


make: *** [Makefile:86: install] Error 1

Allow the usage as a Git submodule

Hi, I would like to use the ParadisEO as a Git submodule. I know that is possible to do it, but it requires more configuration.

In order to use ParadisEO as a Git submodule, would be interesting change the references to directory names in CMakeLists.txt files. When we try to configure all project with cmake, it tries configure the eo directory as [my-project-path]/eo instead some thing as [my-project-path]/external/paradiseo/eo.

(the path to submodule is external/paradiseo in this case).

Suggestion

The suggestion is replace the CMAKE_SOURCE_DIRs with CMAKE_CURRENT_SOURCE_DIR or PROJECT_SOURCE_DIR to cmake always configures these directories as relative path to the paradiseo repository path. This way, the following simple CMake code works:

add_subdirectory(external/paradiseo)

Confidence interval

Hi
Is there a way to calculate the confidence interval in global optimum from ParadisEO?
If yes, which mathematical approach is used for that ?
Thanks

Correction errors found

Hello,

We found 2 errors in the source code.

The first one is due to an error in compilation on windows where sighandler is not defined.
We need to add in eo/src/eoSIGContinue.h (line 36) :

#include <csignal>
typedef void (*sighandler_t)(int);
#include "eoContinue.h"

The second one was observed during test on the CMAES algorithm where the solution was converging on a area and at a certain point got a switched and diverged a lot without success to reconverging on a area. We found out that it was due to the covaraince matrix where an utilisation of a eigen fonction wasn't working as it has to be with like it seems to be an "aliasing issue".
So in edo/src/edoEstimatorNormalAdaptive.h (line 236):

Matrix mD = eigensolver.eigenvalues().asDiagonal();
// from variance to standard deviations
// Correction
mD = mD.cwiseSqrt();

Thanks

Best regards

Passer la documentation sous Sphinx

La documentation de paradiseo est uniquement sous doxgen, ce qui est peu pratique pour intégrer des pages généralistes (tutoriaux, howto, etc.).

Trouver un système qui permette d'articuler doxygen et sphinx (breathe ?).

Déplacer les edoRepairers dans eo

Les classes héritées de edoRepairers sont dans le module EDO.

Or, elles sont suffisamment génériques pour pouvoir être utiles dans le reste du framework.

Les renommer et les déplacer dans le module EO.

Validation CMA-ES

Il faut tester l'algorithme CMA-ES du module EDO sur le benchmark BBOB.

[Refactor] Add paradiseo paths on the all #include directives

Absolute includes considers the system paths

The includes within source files is in the form:

#include <eoVector.h>

I believe this form considers the install path of EO, but when ParadisEO was installed, the include path is */paradiseo/eo/.
It forces us to use the -I flag on g++ command, including the complete path on compile command.
Add the paradiseo path improvements these situation.

In this case:

#include <paradiseo/eo/eoVector.h>

... in all source files.

Improvements on Headers (.h to .hpp) [Refactoring]

.hpp vs .h headers

Using headers in *.hpp format and including class definitions and implementations in the same files makes the inclusion of the headers more straightforward and reliable.

*.hpp files also provides a simplier installation process.

Projects make purely in C++ should use hpp files to includes.

Remember, C is not C ++ and it can be very dangerous to mix and match.

I suggest a refactoring on the header files format, merging the implementations which is separate of the definitions in the same files.


Google Translate to Franchise:

L'utilisation d'en-têtes au format * .hpp et l'inclusion de définitions de classe et d'implémentations dans les mêmes fichiers rendent l'inclusion des en-têtes plus simple et fiable.

Les fichiers * .hpp fournissent également un processus d'installation plus simple.

Les projets purement en C ++ doivent utiliser des fichiers hpp à includes.

Rappelez-vous que C n'est pas C ++ et qu'il peut être très dangereux de mélanger et d'associer.

Je suggère un refactoring sur le format des fichiers d'en-tête, fusionnant les implémentations qui sont séparées des définitions dans les mêmes fichiers.

Wrapper PISA

Un wrapper EO<->PISA. Par exemple un eoEvalFunc spécialisé, peut-être seulement dans MOEO, ou alors étendre le principe de PISA à tous les modules.

no matching function for call to std::swap with vector of bool

Hi, I'm experienced an issue when compiling the libraries in the version v3.0.0 on Linux 6.1.51-1-lts x86_64. The function std::swap not accepts the eoBit<...> as arguments, it not did convert to expected types.

/home/ronaldd/Workspace/cvrp-metaheuristics-loggi/.temp/paradiseo-3.0.0/eo/src/ga/eoBitOp.h:367:24: error: no matching function for call to ‘swap(std::vector<bool>::reference, std::vector<bool>::reference)’
  367 |               std::swap(chrom1[i], chrom2[i]);
      |               ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/c++/13.2.1/bits/stl_pair.h:61,
                 from /usr/include/c++/13.2.1/bits/stl_algobase.h:64,
                 from /usr/include/c++/13.2.1/bits/specfun.h:43,
                 from /usr/include/c++/13.2.1/cmath:3699,
                 from /usr/include/c++/13.2.1/math.h:36,
                 from /home/ronaldd/Workspace/cvrp-metaheuristics-loggi/.temp/paradiseo-3.0.0/eo/src/ga/../utils/eoData.h:28,
                 from /home/ronaldd/Workspace/cvrp-metaheuristics-loggi/.temp/paradiseo-3.0.0/eo/src/ga/../eoObject.h:30:
/usr/include/c++/13.2.1/bits/move.h:189:5: note: candidate: ‘std::_Require<std::__not_<std::__is_tuple_like<_Tp> >, std::is_move_constructible<_Tp>, std::is_move_assignable<_Tp> > std::swap(_Tp&, _Tp&) [with _Tp = _Bit_reference; _Require<__not_<__is_tuple_like<_Tp> >, is_move_constructible<_Tp>, is_move_assignable<_Tp> > = void]’ (near match)
  • Env: GNU/Linux 6.1.51-1-lts x86_64
  • GCC version: 13.2.1 20230801
  • ParadisEO version: v3.0.0

Templates for constrained optimization

I think is a good idea supply template class(es) for constraints to use together EvalFunctions classes in order to supply features for implementations of constrained optimization problems.

An example of a feature is penalization rules in the evaluation of individuals.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.