moead {MOEADr} | R Documentation |
MOEA/D
Description
MOEA/D implementation in R
Usage
moead(
preset = NULL,
problem = NULL,
decomp = NULL,
aggfun = NULL,
neighbors = NULL,
variation = NULL,
update = NULL,
constraint = NULL,
scaling = NULL,
stopcrit = NULL,
showpars = NULL,
seed = NULL,
...
)
Arguments
preset |
List object containing preset values for one or more
of the other parameters of the |
problem |
List containing the problem parameters.
See |
decomp |
List containing the decomposition method parameters
See |
aggfun |
List containing the aggregation function parameters
See |
neighbors |
List containing the decomposition method parameters
See |
variation |
List containing the variation operator parameters
See |
update |
List containing the population update parameters
See |
constraint |
List containing the constraint handing parameters
See |
scaling |
List containing the objective scaling parameters
See |
stopcrit |
list containing the stop criteria parameters.
See |
showpars |
list containing the echoing behavior parameters.
See |
seed |
seed for the pseudorandom number generator. Defaults to NULL,
in which case |
... |
Other parameters (useful for development and debugging, not necessary in regular use) |
Details
Component-wise implementation of the Multiobjective Evolutionary Algorithm based on decomposition - MOEA/D.
Value
List object of class moead containing:
information on the final population (
X
), its objective values (Y
) and constraint information list (V
) (seeevaluate_population()
for details);Archive population list containing its corresponding
X
,Y
andV
fields (only ifupdate$UseArchive = TRUE
).Estimates of the ideal and nadir points, calculated for the final population;
Number of function evaluations, iterations, and total execution time;
Random seed employed in the run, for reproducibility
Problem Description
The problem
parameter consists of a list with all necessary
definitions for the multiobjective optimization problem to be solved.
problem
must contain at least the following fields:
-
problem$name
: name of the problem instance function, that is, a routine that calculates Y = f(X); -
problem$xmin
: vector of lower bounds of each variable -
problem$xmax
: vector of upper bounds of each variable -
problem$m
: integer indicating the number of objectives
Besides these fields, problem
should contain any other relevant inputs
for the routine listed in $name
. problem
may also contain the
(optional) field problem$constraints
, which is a list object
containing information about the problem constraints. If present, this list
must have the following fields:
-
problem$constraints$name
- (required) name of the function that calculates the constraint values (see below for details) -
problem$constraints$epsilon
- (optional) a small non-negative value indicating the tolerance to be considered for equality constraints. Defaults to zero.
Besides these fields, problem$constraint
should contain any other
relevant inputs for the routine listed in problem$constraint$name
.
Detailed instructions for defining the routines for calculating the objective and constraint functions are provided in the vignette Defining Problems in the MOEADr Package. Check that documentation for details.
Decomposition Methods
The decomp
parameter is a list that defines the method to be used for the
generation of the weight vectors. decomp
must have
at least the $name
parameter. Currently available methods can be
verified using get_decomposition_methods()
. Check
generate_weights()
and the information provided by
get_decomposition_methods()
for more details.
Neighborhood Strategies
The neighbors
parameter is a list that defines the method for defining the
neighborhood relations among subproblems. neighbors
must have
at least three parameters:
-
neighbors$name
, name of the strategy used to define the neighborhoods. Currently available methods are: -$name = "lambda"
: uses the distances between weight vectors. The calculation is performed only once for the entire run, since the weight vectors are assumed static. -$name = "x"
: uses the distances between the incumbent solutions associated with each subproblem. In this case the calculation is performed at each iteration, since incumbent solutions may change. -
neighbors$T
: defines the neighborhood size. This parameter must receive a value smaller than the number of subproblems defined for the MOEA/D. -
neighbors$delta.p
: parameter that defines the probability of sampling from the neighborhood when performing variation.
Check define_neighborhood()
for more details.
Variation Operators
The variation
parameter consists of a list vector, in which each
sublist defines a variation operator to be used as part of the variation
block. Each sublist must have at least a field $name
, containing the name
of the i
-th variation operator to be applied. Use
get_variation_operators()
to generate a list of available operators, and
consult the vignette Variation Stack in the MOEADr Package
for more
details.
Scalar Aggregation Functions
The aggfun
parameter is a list that defines the scalar aggregation function
to be used. aggfun
must have at least the $name
parameter. Currently
available methods can be verified using get_scalarization_methods()
. Check
scalarize_values()
and the information provided by
get_scalarization_methods()
for more details.
Update Methods
The update
parameter is a list that defines the population update strategy
to be used. update
must have at least the $name
parameter. Currently
available methods can be verified using get_update_methods()
. Check
update_population()
and the information provided by
get_update_methods()
for more details.
Another (optional) field of the update
parameter is update$UseArchive
,
which is a binary flag defining whether the algorithm should keep an
external solution archive (TRUE
) or not (FALSE
). Since it adds to the
computational burden and memory requirements of the algorithm, the use of an
archive population is recommended only in the case of constrained problems
with constraint handling method that can occasionally accept unfeasible
solutions, leading to the potential loss of feasible efficient solutions for
certain subproblems (e.g., constraint_vbr()
with type
= "sr" or "vt").
Constraint Handling Methods
The constraint
parameter is a list that defines the constraint-handling
technique to be used. constraint
must have at least the $name
parameter.
Currently available methods can be verified using get_constraint_methods()
.
Check update_population()
and the information provided by
get_constraint_methods()
for more details.
Objective Scaling
Objective scaling refers to the re-scaling of the objective values at each
iteration, which is generally considered to prevent problems arising from
differently-scaled objective functions. scaling
is a list that must have
at least the $name
parameter. Currently available options are
$name = "none"
, which does not perform any scaling, and $name = "simple"
,
which performs a simple linear scaling of the objectives to the interval
[0, 1]
.
Stop Criteria
The stopcrit
parameter consists of a list vector, in which each
sublist defines a termination criterion to be used for the MOEA/D. Each
sublist must have at least a field $name
, containing the name of the
i
-th criterion to be verified. The iterative cycle of the MOEA/D is
terminated whenever any criterion is met. Use get_stop_criteria()
to
generate a list of available criteria, and check the information provided by
that function for more details.
Echoing Options
The showpars
parameter is a list that defines the echoing options of the
MOEA/D. showpars
must contain two fields:
-
showpars$show.iters
, defining the type of echoing output.$show.iters
can be set as"none"
,"numbers"
, or"dots"
. -
showpars$showevery
, defining the period of echoing (in iterations).$showevery
must be a positive integer.
References
F. Campelo, L.S. Batista, C. Aranha (2020): The MOEADr Package: A
Component-Based Framework for Multiobjective Evolutionary Algorithms Based on
Decomposition. Journal of Statistical Software doi:10.18637/jss.v092.i06
Examples
## Prepare a test problem composed of minimization of the (shifted)
## sphere and Rastrigin functions
sphere <- function(x){sum((x + seq_along(x) * 0.1) ^ 2)}
rastringin <- function(x){
x.shift <- x - seq_along(x) * 0.1
sum((x.shift) ^ 2 - 10 * cos(2 * pi * x.shift) + 10)}
problem.sr <- function(X){
t(apply(X, MARGIN = 1,
FUN = function(X){c(sphere(X), rastringin(X))}))}
## Set the input parameters for the moead() routine
## This reproduces the Original MOEA/D of Zhang and Li (2007)
## (with a few changes in the computational budget, to make it run faster)
problem <- list(name = "problem.sr",
xmin = rep(-1, 30),
xmax = rep(1, 30),
m = 2)
decomp <- list(name = "SLD", H = 49) # <-- H = 99 in the original
neighbors <- list(name = "lambda",
T = 20,
delta.p = 1)
aggfun <- list(name = "wt")
variation <- list(list(name = "sbx",
etax = 20, pc = 1),
list(name = "polymut",
etam = 20, pm = 0.1),
list(name = "truncate"))
update <- list(name = "standard", UseArchive = FALSE)
scaling <- list(name = "none")
constraint<- list(name = "none")
stopcrit <- list(list(name = "maxiter",
maxiter = 50)) # <-- maxiter = 200 in the original
showpars <- list(show.iters = "dots",
showevery = 10)
seed <- 42
## Run MOEA/D
out1 <- moead(preset = NULL,
problem, decomp, aggfun, neighbors, variation, update,
constraint, scaling, stopcrit, showpars, seed)
## Examine the output:
summary(out1)
## Alternatively, the standard MOEA/D could also be set up using the
## preset_moead() function. The code below runs the original MOEA/D with
## exactly the same configurations as in Zhang and Li (2007).
## Not run:
out2 <- moead(preset = preset_moead("original"),
problem = problem,
showpars = showpars,
seed = 42)
## Examine the output:
summary(out2)
plot(out2, suppress.pause = TRUE)
## End(Not run)
# Rerun with MOEA/D-DE configuration and AWT scalarization
out3 <- moead(preset = preset_moead("moead.de"),
problem = problem,
aggfun = list(name = "awt"),
stopcrit = list(list(name = "maxiter",
maxiter = 50)),
seed = seed)
plot(out3, suppress.pause = TRUE)