Skip to content
This repository has been archived by the owner on Jul 16, 2024. It is now read-only.
Jacco Geul edited this page Feb 24, 2014 · 1 revision

Here follows a first draft of the development roadmap, in form of a TODO list.

Core enhancements

  • Optimization stuff
    1. Add mixed integer programming capabilities. Francesco proposes to add a member to the individual representing how many elements of the chromosome are integers. Algorithms such as DE would then work only on the continuous part. (DONE)
    2. Add constrained optimization capabilities. GOproblem should have a virtual function that returns also the constraint value and a member storing default values for penalty parameters to be used by those algorithms that do not know how to use the constraints. (DONE)
    3. Psowork stuff. Should be merged but only after a review of the code (or reimplementation). (DONE)
    4. Variable chromosome length. Could be done by a similar trick as the one proposed for the mixint.
    5. Add multiobjective. Same philosophy as above (virtual function returning vectors) (DONE)
    6. Provide a test problem for the external executable (twodee generalization)
    7. Centralize the individuals comparison (DONE)
    8. Come up with a test suite that actually tests all basic classes (and possibly automatically)
  • Parallelization stuff
    1. Reimplement entirely David work on serialization for the archipelago (prerequisite for many things) (DONE)
    2. Make island as a polymorphic class (mpi island, boinc island, local island) (DONE)
    3. Extend PaGMO to deal with mpi clusters ... (DONE)
    4. Extend PaGMO to deal with islands connected via ip (boinc type) ...
  • Pythonic stuff
    1. Allow users to define problems and algorithms in python. (DONE)

Source code & coding style

  1. Namespaces to be introduced as to mirror python module structures: example problem::rastrigin(20) instead of rastriginProb(20) - this is now being worked on in the [http://pagmo.git.sourceforge.net/git/gitweb.cgi?p=pagmo/pagmo;a=shortlog;h=refs/heads/code_refactor code_refactor] branch (DONE)
  2. Linux Kernel coding style is decided and used as a basic reference (e.g. no CamelCase and tabs are eight.....) [http://lxr.linux.no/linux/Documentation/CodingStyle Linus' kernel coding style document]. Only variables that are likely to be used by other code users have to follow these strict guidelines. Implemented using [http://astyle.sourceforge.net/ astyle] in the [http://pagmo.git.sourceforge.net/git/gitweb.cgi?p=pagmo/pagmo;a=shortlog;h=refs/heads/code_refactor code_refactor] branch
  3. Documentation uses doxygen and is mandatory (DONE)

Distribution

  • Comprehensive Windows packages: we may distribute a whole Python installation with all the needed extra packages (IPython, numpy, matplotlib, etc.). It would be quite big but self-sustaining. In addition, we could provide a minimal zip file with just PyGMO, for power-users who know how to administer their own Python installation. (DONE)
  • Ubuntu packages.
  • Source packages.

GUI

  • With [http://www.riverbankcomputing.co.uk/software/pyqt/intro PyQt4] we could have some nice GUI capabilities, if we think they are useful (long-term).
Clone this wiki locally