Journal Optimisez avec Open Metaheuristics 0.2.4

Posté par (page perso) .
Tags : aucun
0
11
avr.
2006
Open Metaheuristics (oMetah) viens de sortir en version 0.2.4

C'est un ensemble d'outils pour la conception et les tests de métaheuristiques d'optimisation (algorithmes génétiques, recuit simulé, algorithmes de colonies de fourmis, etc.).

oMetah est composé d'un framework et d'un ensemble de scripts de tests.

Le framework permet d'implémenter vos métaheuristiques et vos problèmes d'optimisation (en variables réelles uniquement). La liaison entre les deux est gérée par le framework, et vous pouvez optimiser un problème embarqué au sein du même éxécutable, accessible via le réseau ou sous la forme d'un module python.

Les scripts de tests (oMetahLab, écris en python) permettent de produire tout un tas de graphiques via R (le logiciel de statistique) et des rapports de synthèse (html ou latex). Une GUI toute simple est fournie.

oMetah est d'ors et déjà utilisé pour résoudre divers problèmes d'optimisations « difficile » du monde réel.

L'ensemble n'est qu'en version beta mais demande des tests, toute contribution est la bienvenue. N'hésitez pas à utilisez oMetah pour vos problèmes.

Site principal : http://ometah.berlios.de/index.php/Main_Page
Page du projet : https://developer.berlios.de/projects/ometah/
Infos sur les métaheuristiques : http://fr.wikipedia.org/wiki/M%C3%A9taheuristique
  • # question

    Posté par . Évalué à 2.

    Ca m'a l'air bien Interressant, les problèmes à tester peuvent s'implémenter en python où il faut se plonger dans le code C++ ?
    • [^] # Re: question

      Posté par (page perso) . Évalué à 1.

      On peut implémenter les problèmes en Python, il suffit d'utiliser un fichier « problem_for_ometah.py » dans le même répertoire que le binaire ometah : http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ometah/ometah/prob(...)

      L'interface n'étant pas encore suffisamment bien pensée, il faut utiliser ces noms pour le module et les fonctions, et pas d'autres.

      Ensuite, il suffit de lancer l'exécutable avec l'options « --com-client Python ».

      Pour le moment on ne peut pas embarquer toute la lib dans un module python, mais c'est sur la liste des trucs à faire.
  • # doc?

    Posté par . Évalué à 2.

    La doc n'est pas très claire, ça manque d'exemple pour savoir comment implémenter un problème :-(
    • [^] # Re: doc?

      Posté par (page perso) . Évalué à 1.

      Pour implémenter un problème en C++, il y a un example dans les sources : http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ometah/ometah/exam(...)

      En allant au plus simple, il n'y a qu'une fonction à coder. Après, on peut tout de même se faire une interface aux petits oignons.

      Je vais tâcher de faire un howto un peu plus complet rapidement.
      • [^] # Re: doc?

        Posté par . Évalué à 3.

        J'ai vu mais aux endroits intéressants il y a juste:

        // put here the code

        :-(
        • [^] # Re: doc?

          Posté par (page perso) . Évalué à 1.

          Simplement parce que c'est la partie qui dépend du problème lui-même. La seule contrainte c'est de modifier le point reçu en argument avec un vecteur de double. point.getSolution() te donne le vecteur de double avec les paramètres demandés, après il faut faire un return point.setValue( vecteur_de_double ) pour renvoyer la (ou les) valeurs associées.

          Après, la façon dont tu calcules la valeur à renvoyer à partir du vecteur, c'est ton problème :-)
  • # EvoGrid

    Posté par (page perso) . Évalué à 3.

    Argl, il se trouve que je travaille sur un projet similaire depuis peu. Il s'agit d'un framework pour implementer des algo evolutionnaires potentiellement parallèles en python (pur).

    Voici la documentation générée à partir des doctests :

    README
    http://champiland.homelinux.net/evogrid/code/evogrid.og.main(...)

    Overview des principaux composants (mini tutoriel):
    http://champiland.homelinux.net/evogrid/code/evogrid.og.main(...)

    Implémentation d'une stratégie de "sharing" pour eviter les convergence prématurée:
    http://champiland.homelinux.net/evogrid/code/evogrid.og.main(...)

    Sytème d'archivage des elites :
    http://champiland.homelinux.net/evogrid/code/evogrid.og.main(...)

    Le reste :
    http://champiland.homelinux.net/evogrid/code/evogrid.og.main(...)

    Mon repository bzr:
    http://champiland.homelinux.net/evogrid/code/evogrid.og.main

    C'est encore très pas fini et donc les interfaces sont susceptible de changer. Pas encore de relase packagée. Si vous voulez jouer avec le code, faut utiliser bzr (ou un wget recursif :).

    Ce qui est fait:

    - définition des interfaces
    - implémentation de composants indépendants de la représentation /du problème à optimiser:

    - pools de replicateurs (simple, ordonné, pool virtuel (union dynamique de pools))
    (non persitents pour l'instant
    - comparateurs (simple ou sharing aware)
    - selectors (random, tournamenent
    - replacers (random et tournamenent, generationel ou steady state)
    - checkpointers (time-based, compteurs, quality based, ...)
    - archives d'elites
    - evolvers pour organiser tout ca : simple, composé avec exécution séquentielle (nested evolvers) pour simuler une éxecution en //

    Reste a faire:

    - réprésentations standards (vecteurs de bits, de réels avec numarry par exemple)
    - comparateur implémentant une logique de dominance à la Pareto pour implémenter des optimizations multi-critéres
    - opérateurs de variations lamarckiens (tabu search par exemple)
    - evolvers // (en utilisant coroutines, thread et forks + communication reseau)
    - memoizer pour les evaluators et les distance des sharing avec interface memcached
    - plein d'autres choses que j'ai oubliées
    • [^] # Re: EvoGrid

      Posté par (page perso) . Évalué à 2.

      En fait, oMetah se situe un niveau d'abstraction au dessus de ce genre de lib, car elle n'est pas attachée à un type de métaheuristique en particulier. On projette de se greffer par dessus d'autres framework, qui auront la charge de l'implémentation des algos.

      Au même niveau que ta lib, il y a EO qui fait déjà tout ça et plus... Loin de moi l'idée de te couper dans ton élan, mais il vaut bien être sûr de son coup avant réimplémenter la roue :-) En plus, on a généralement besoin de rapidité pour tester ce genre d'algos, en python ça risque de ramer un poil trop.

      À mon humble avis, il vaut mieux travailler sur un binding Python pour EO (et MO, ParadisEO, tout les machinEO quoi) ou une autre lib (openBEAGLE ou même Sferes).
      • [^] # Re: EvoGrid

        Posté par (page perso) . Évalué à 2.

        J'ai déjà utilisé le binding python d'EO mais je le trouve trop compliqué à mettre en oeuvre (compilation, ...) et le fait que la lib soit en C++ templatiser m'embetais (car je suis pas développeur C++).

        J'aime beaucoup l'approche interface / composants de Zope3 et c'est pour ca que je developpe un nouveau framework basé sur ce paradigme. Il devrait permettre plus de souplesse pour se brancher sur d'autre composant et imaginer des architectures complexe de parallisations (grid computing ...).

        En plus programmer avec les doctests est un vrai plaisir.
        • [^] # Re: EvoGrid

          Posté par (page perso) . Évalué à 2.

          Et bien alors bon courage, tiens nous au courant de l'avancement du projet :)

          Si jamais tu veux te brancher sur oMetah, demande-moi. On a déjà pas mal de trucs qui peuvent servir à tester les algos, il suffit juste d'une sortie XML...
          • [^] # Re: EvoGrid

            Posté par (page perso) . Évalué à 1.

            Je posterai un journal, une annonce sur le site de l'AFPy et un enregistrement sur le cheeseshop des la release de la version 0.1 d'ici quelques semaines AMA.

            Concernant une integration avec oMetah, j'y jetterai un coup d'oeil des que j'aurais un peu de temps.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.