migrating

Generally speaking migrating code from Vita isn't too hard: Ultra has a simpler interface but the backbone structure is similar in many respects.

Many of the examples have been ported to Ultra and are a good starting point for understanding the differences.

General aspects

The majority of class specializations have their own namespace. So instead of vita::de_problem, vita::de_search, vita::de_individual, ultra::src_search you should use ultra:de::problem, ultra:de::search, ultra::de::individual, ultra::src::search.

---

You usually haven't to specify template arguments since they're automatically deduced:

vita::de_search<decltype(neg_rastrigin)> search(prob, neg_rastrigin);

is now the simpler:

de::search search(prob, neg_rastrigin);

---

environment class has been renamed to parameters and parameters have been grouped by category. E.g.

environment env;
env.p_mutation = 0.6;
env.tournament_size = 3;

becomes

parameters params;
params.evolution.p_mutation = 0.6;
params.evolution.tournament_size = 3;

---

Return results of a search are contained in a different structure (search_stats defined in kernel/search.h). So, for example, the usual access to the best individual / fitness changes from:

const auto res(search.run());

const auto solution(res.best.solution);
const auto value(res.best.score.fitness);

to

const auto res(search.run());

const auto solution(res.best_individual);
const auto value(*res.best_measurements.fitness);

Note that scores contained in the search_stats struct are optional values hence the * to get the fitness.

---

The threshold for identifying successful runs isn't specified anymore in the environment / parameters structure but is passed to the search::run member functions:

environment env;
env.threshold.fitness = -0.5;
// ...
src_search s(prob);
const auto result(s.run(10));

should be replaced with

model_measurements<double> threshold;
mm.fitness = -0.5;
// ...
src::search s(prob);
const auto result(s.run(10, threshold));

Differences deriving from design choices

Concurrency-related aspects

All the search strategies can be used enabling multiple layers / subgroups (prob.params.population.init_subgroups > 1). Evolution happens in parallel for every subgroup. Many algorithms take advantage of this organization to explore different search spaces, possibly using different parameters; anyway the can be executed in single thread mode.

ALPS, otherwise, is conceived to exchange information among subgroups and, even if started with a single layer, will add further layers during the evolution (thus enabling concurrency).

Concurrency is a great performance boost but makes evolution non-repeatable.

Fitness-related changes

There isn't anymore a fixed type for representing fitness. User can employ the type more appropriate for the specific task provided that it satisfies the Fitness concept. However a fitnd class is available for filling the gap.