Add wrappers for Nevergrad

[janosg]

Wrap the gradient free optimizers from nevergrad in optimagic.

Nevergrad implements the following algorithms:

• NgIohTuned is "meta"-optimizer which adapts to the provided settings (budget, number of workers, parametrization) and should therefore be a good default.
• TwoPointsDE is excellent in many cases, including very high num_workers.
• PortfolioDiscreteOnePlusOne is excellent in discrete settings of mixed settings when high precision on parameters is not relevant; it's possibly a good choice for hyperparameter choice.
• OnePlusOne is a simple robust method for continuous parameters with num_workers < 8.
• CMA is excellent for control (e.g. neurocontrol) when the environment is not very noisy (num_workers ~50 ok) and when the budget is large (e.g. 1000 x the dimension).
• TBPSA is excellent for problems corrupted by noise, in particular overparameterized (neural) ones; very high num_workers ok).
• PSO is excellent in terms of robustness, high num_workers ok.
• ScrHammersleySearchPlusMiddlePoint is excellent for super parallel cases (fully one-shot, i.e. num_workers = budget included) or for very multimodal cases (such as some of our MLDA problems); don't use softmax with this optimizer.
• RandomSearch is the classical random search baseline; don't use softmax with this optimizer.

In the long run we want to wrap all of them, but if you are tackling this as your first issue you should focus on one. In that case please coment below which optimizer you are going to work on so we don't duplicate efforts.

[AashifAmeer]

Hi @janosg , Under the Nevergrad library which optimization algorithm you would suggest me to include here, One plus one? OR CMA-ES , Random search , PSO?

[janosg]

Hi @AashifAmeer, I you can use any optimizer. Start with the one that seems easiest to do. Long run we want all of them!

[janosg]

@AashifAmeer I extended the issue description a bit so more people can work simultaneously on the issue. Please comment below which optimizer you picked.

[gulshan-123]

Hi @janosg , I want to work on this issue. I will work on OnePlusOne algorithm. I have read the documentation from nevergrad. So, the nevergrad wrapper is expected to similar that of scipy algorithms, right? From where should I start working?

[janosg]

This should help you to get started: https://optimagic.readthedocs.io/en/latest/how_to/how_to_add_optimizers.html

[r3kste]

PSO is excellent in terms of robustness, high num_workers ok.

Hi. I have opened #579 which implements a wrapper for the PSO algorithm.

[janosg]

@gulshan-123 and @r3kste, thanks for your PRs. In both PRs we currently have the problem that they way you implement parallelism is not compatible with our history collection. I first thought that the only way around this is to use the lower level ask-and-tell inferface, but I think there is a better solution you can try.

Background

Optimagic's InternalOptimizationProblem automatically adds history collection to the objective function. The collected history forms the basis of om.criterion_plot and other important visualizations. For history collection to work in a parallel case, it is important to use problem.batch_fun (which automatically parallelizes) instead of just using multiprocessing on problem.fun.

Implementation Idea

Nevergrad has the batch_mode and executor arguments for parallelization. An example is here. The executor needs to be compatible with the Executor interface from concurrent.futures.

I think the simplest way to make history collection work with nevergrad is to implement a custom Executor that calls problem.batch_fun internally.

[r3kste]

Hello @janosg. Thanks for the feedback.

we currently have the problem that they way you implement parallelism is not compatible with our history collection.

I want to point out that in #579, I actually set disable_history=True for PSO. This is because PSO is a swarm algorithm, and it seems like internally nevergrad calls the objective for each particle in the population. Due to this, I believe that maintaining history for PSO doesn't make much sense, similar to the case of other optimizers like scipy_brute and scipy_differential_evolution.

As disable_history=True, I believe there is no need of the custom Executor implementation. I would love to hear your thoughts on this.

[janosg]

We actually want to collect histories for all optimizers. The main benefit of history collection is to compare how efficient different optimizers are, i.e. how fast (in terms of function evaluations) they make progress.

There are a few optimizers where we have not found ways to do it yet, but in nevergrad it seems to be quite easy, so we definitely want to do it.

This would for example allow users to compare the efficiency of PSO with a random search algorithm.