PlatEMO: the case for zero dependencies in a comparison field

Three hundred and sixty algorithms, zero libraries

The feature list leads with the counts: more than three hundred open source evolutionary algorithms and more than six hundred benchmark problems. The current release puts the exact figures at three hundred and sixty and six hundred and thirty.

The second feature is the one that makes those numbers usable. The platform consists of a number of MATLAB functions without using any other libraries, and any machine able to run MATLAB can use it regardless of the operating system, with badges confirming Windows, Linux and macOS. There is no package manifest, no dependency file, no lock file and no build step. The top-level tree is three entries: the platform directory, a documentation folder, and the README.

That looks like an absence until you consider what a multi-objective comparison actually requires. The evidence standard in evolutionary optimization is a statistical comparison across many independent runs per algorithm per problem, because these algorithms are stochastic and their variance is part of the finding. Producing thirty runs of six algorithms over ten problems is six hundred experiment executions, and doing that in a language with a dependency graph means your result depends on which version of a numerical library, which BLAS and which GPU kernel library were installed on the machine that produced it.

A directory of functions with no dependencies removes that variable. The claim is not that MATLAB is a good language; it is that the same code runs everywhere, so a number in a 2024 paper and a number you produce this month came from the same arithmetic. For a field where comparisons are the product, that is the feature, and it is not the one the README leads with.

It also has a cost, and the cost is the language. Anything you want to do with these algorithms outside MATLAB means writing MATLAB.

One release, three axes of difficulty

The 4.16 release note is a short list of names, and reading it as names rather than as a changelog tells you what is hard in this field in 2026.

One algorithm was added for large-scale problems. Two were added for constrained problems. Five were added for expensive problems, and the names make the technique obvious: two of them pair a surrogate model with a decomposition, one is an efficient global optimisation variant applied to a decomposition, and two are built on efficient global optimisation and on transfer surrogate-assisted methods. Expensive multi-objective optimisation means you cannot afford to evaluate a candidate a thousand times, so the whole subfield is about learning the objective instead of calling it.

So one release covers three axes of difficulty that are independent of each other: scale, constraints, and evaluation budget. Those are the three things that break a well-tuned evolutionary algorithm, and the fact that a single release adds eight algorithms spread across them says the field's attention has moved from proposing better crossover operators to proposing algorithms that survive a harder setting.

The five new benchmark problems go the same way. They are multimodal problems, meaning the test suite has one true front to find but several, and a good algorithm has to find all of them. A platform that only tests single-modal problems cannot tell you whether your algorithm is good or whether it got lucky, so adding a multimodal suite is a statement about what counts as evidence.

The release note also says that state-of-the-art algorithms will be included continuously, and the cadence supports it: three releases across 2026, roughly two months apart, each adding algorithms and problems rather than restructuring anything.

Every algorithm arrives with its citation

There is a contribution rule in this project and it is unusual enough to be worth reading twice.

The instructions say that if you want to add an algorithm, a problem, an operator or a performance indicator, you should send the MATLAB code, able to be used in the platform, together with the relevant literature. Issues and pull requests are open, and a named maintainer plus a group chat are offered for questions.

Two requirements in one sentence: the code must run in the platform, and the paper must come with it. The first is ordinary integration hygiene. The second is a provenance policy, and it is enforced at the contribution gate rather than in a policy document.

That policy is what makes three hundred and sixty algorithms coexist in one directory without anybody having to adjudicate which implementation is the better one. Every entry in the platform is attached to a published result, so the argument about whether an algorithm works is settled by the paper rather than by the implementation. The README is explicit that the implementations were written from the group's understanding of the published algorithms, which is an honest admission that a reimplementation is not the authors' code and may differ from it.

This also tells you how to read a number the platform produces. It is the output of someone else's reimplementation of someone else's paper. That is a normal and accepted currency in this field, but it is a currency and not a guarantee, and the disclaimer says so: you are told not to rely on the material as a basis for business, legal or other decisions, and that no responsibility is assumed for the consequences of using any algorithm in the tool.

For a research workflow that disclaimer is appropriate. For anyone who wants to put a result in front of a decision-maker, it is the sentence to notice.

It is not open source, and the difference matters

The counts say open source algorithms. The platform itself is a different matter, and this is the first thing to check before you build on it.

The project page shows no licence identifier, and there is no licence file in the repository. What exists instead is a copyright section. It states that the copyright belongs to the research group, that you are free to use the platform for research purposes, and that all publications which use the platform or any code in it should acknowledge the use of PlatEMO and reference a specific paper in a computational intelligence magazine from 2017.

So the permission is real but it is narrower than an open source licence in two ways. It is scoped to research, and it carries a citation obligation. There is no statement about commercial use, no patent grant, and no warranty.

That combination is ordinary for an academic platform and unusual for a repository with three hundred and sixty implementations of other people's algorithms in it, so it is worth being deliberate about it. The algorithms are published results and belong to their authors. The platform's arrangement with those authors is between the group and the field, not between you and the authors, and the terms it offers you are the research-use terms.

This review does not interpret licences and there is nothing here to interpret, because the file does not exist. What to do is straightforward: read the copyright section, decide whether your use is research use, and if you need anything wider, ask before you build a pipeline on it. The citation requirement is not optional either, and it is cheap to satisfy, since it names the exact reference.

The GUI is the experiment runner

The productivity claim in this README is about bookkeeping, not about algorithms, and it is the reason most people will use this platform.

The stated feature is a graphical interface where you configure all the settings and perform experiments in parallel without writing any code. If you have run a multi-objective comparison you know what that means in practice: the same grid of algorithms and problems, every algorithm repeated with many independent random seeds, and the results collected into a table with statistical tests applied. Done by hand in a script it is a day of writing plumbing per paper, and the plumbing is where mistakes live.

The figure list is the other half and it tells you what the intended output is. You can display the Pareto front of a result, the Pareto set, the true Pareto front of the problem for comparison, and the evolutionary trajectories of any performance indicator values. That last one is the diagnostic view: it shows how an algorithm moved rather than only where it ended, which is how you tell a converged run from a stalled one.

And then the export. Statistical results can be saved as an Excel table or a LaTeX table, described as directly usable in academic writing. That single line identifies the actual product. This is a paper-production tool. The LaTeX output is not a convenience for reporting; it is the deliverable the workflow is built around, and everything else, the parallel runner, the trajectory plots, the statistical table, exists to get you to a table you can paste into a manuscript.

Which also explains a design choice that would otherwise look odd: there is no programmatic interface described. The algorithms are MATLAB functions you can call from a MATLAB session, but the documented entry point for the experiment workflow is the window.

Two months between releases, and no tests in the tree

The maintenance picture is easy to read from the file list and the release history.

Three releases in 2026, spaced roughly two months: one in January, one in May, one in July. The last push was the same day as the July release. Every release adds algorithms and problems and the release notes live in the documentation folder rather than in the README, which is the right place for something that long.

The repository, though, has no continuous integration configuration, no test directory and no build manifest. There are three directories at the top level and a README. Nothing runs on commit.

For research code this is defensible, and the reason is worth stating plainly: correctness in this field is established by reproducing published results, and a unit test suite cannot tell you whether a decomposition algorithm is implemented correctly. The peer review of the original paper is the test suite, and a reimplementation is checked against the paper by the person using it.

The practical consequences are still real. A refactor that breaks an algorithm is found by whoever runs it next, and the parallel GUI makes that slower to notice rather than faster, because a failed run looks like a bad row in a table rather than an error. And with no pinned version of the platform itself, the sensible practice is to keep your own copy of the archive rather than tracking the branch, which the download badge's link to the master archive makes easy and which the release tags then give you a version to point at.

One last compatibility note, since it is the first thing that will stop you: the platform requires MATLAB 2018a or newer.

Editorial conclusion

Adopt PlatEMO if you are writing a multi-objective paper and need the standard baselines with a statistical comparison, and run it from the GUI with the LaTeX export rather than scripting it. Do not adopt it for a single-objective or constraint-only problem, since it is multi-objective by construction, and do not assume it is open source, because the repository carries no licence file and the copyright section grants research use with a citation requirement. Check that MATLAB 2018a or newer is available to you, since the download is a repository archive rather than a package, and read the disclaimer before you rely on any result for anything other than a comparison.

Frequently asked questions

Official sources

1. BIMK/PlatEMO on GitHub
2. Issues
3. README
4. Releases