<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Layered TPOT</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Pieter Gijsbers</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Joaquin Vanschoren</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Randal S. Olson</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Technische Universiteit Eindhoven</institution>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>University of Pennsylvania</institution>
          ,
          <country country="US">USA</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>With the demand for machine learning increasing, so does the demand for tools which make it easier to use. Automated machine learning (AutoML) tools have been developed to address this need, such as the Tree-Based Pipeline Optimization Tool (TPOT) which uses genetic programming to build optimal pipelines. We introduce Layered TPOT, a modi cation to TPOT which aims to create pipelines equally good as the original, but in signi cantly less time. This approach evaluates candidate pipelines on increasingly large subsets of the data according to their tness, using a modi ed evolutionary algorithm to allow for separate competition between pipelines trained on di erent sample sizes. Empirical evaluation shows that, on su ciently large datasets, Layered TPOT indeed nds better models faster.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>
        The eld of Automated Machine Learning (AutoML) aims to automate many
of the tasks required to construct machine learning models, hence lowering the
barrier to entry and yielding better models, faster. AutoML methods typically
automate one or more steps in the creation of useful machine learning pipelines,
such as the selection of preprocessing or learning algorithms, hyperparameter
optimization, or a combination of them. A few methods even construct and
optimize entire pipelines, such as the Tree-based Pipeline Optimization Tool
(TPOT)[
        <xref ref-type="bibr" rid="ref14">14</xref>
        ]. TPOT uses genetic programming to evolve optimal pipelines,
aiming to nd machine learning pipelines yielding accurate predictive models while
trying to keep the pipeline as simple as possible.
      </p>
      <p>In this paper, we introduce a novel improvement of TPOT, aimed at
reducing the time needed to evaluate pipelines, without reducing the quality of the
nal pipeline. Indeed, the most time-consuming part in the optimization process
is evaluating the performance of candidate machine learning pipelines. In our
modi cation, this time is reduced by initially evaluating the pipelines on a small
subset of the data, and only allowing promising pipelines to be evaluated on the
full dataset. In order to do this in a fair manner, modi cations to the
evolutionary algorithm are implemented to prevent direct comparison between pipelines
which are evaluated on di erent subsets of the data. As such, we aim to nd
pipelines of similar quality in much less time, making the tool more accessible
and practical by requiring less computational time. We call this improvement
Layered TPOT (LTPOT).</p>
      <p>This paper is organized as follows. First, we review related work in Sect. 2.
Then, in Sect. 3, we discuss the proposed modi cation to TPOT in detail. Next,
in Sect. 4, we lay out how LTPOT will be evaluated, discuss the results of these
evaluations, and propose aspects of LTPOT which can be researched in future
work. Finally, we conclude the study in Sect. 5.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Related Work</title>
      <p>The eld of AutoML is a culmination of work in the elds of algorithm selection,
hyperparameter optimization and machine learning. Several AutoML systems
support at least some form of automatic pipeline construction.</p>
      <p>
        Auto-WEKA [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ] uses Sequential Model-based Algorithm Con guration
(SMAC) to do combined algorithm selection and hyperparameter
optimization [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ], which is an adaptation of Sequential Model-Based Optimization from
statistical literature. Auto-WEKA uses algorithms from the WEKA library [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ],
to build pipelines with one learner (possibly an ensemble) and optionally a
single feature selection technique.
      </p>
      <p>
        Auto-sklearn [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ], built on the Python library scikit-learn [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ], is a
reimplementation of Auto-WEKA with two extensions. The rst is the use of
meta-learning to warm-start the Bayesian optimization procedure, a technique
which has earlier been proven useful in [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. The second addition is the automatic
construction of ensembles from models evaluated during the optimization
process. Furthermore, auto-sklearn allows for more preprocessing steps to be
included in the pipeline: it allows for one feature preprocessor, which includes
feature extraction techniques as well as feature selection techniques, in addition
to up to three data preprocessor methods, such as missing value imputation
and rescaling.
      </p>
      <p>TPOT di ers from Auto-sklearn and Auto-WEKA by using an evolutionary
algorithm instead of SMAC. Additionally, TPOT uses a tree-based structure to
represent pipelines, and considers pipelines with any number of preprocessing
steps. Hence, TPOT is not constrained in the number nor the order of
preprocessing steps.</p>
      <p>
        The main idea of LTPOT is to rst evaluate pipelines on a subset of the
data, to get an indication of whether or not the pipeline is promising relative
to other pipelines. This idea has been explored before, for example in
Samplebased Active Testing [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ], or algorithm selection using learning curves [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ], where
promising algorithm con gurations are rst evaluated on a smaller data sample
to create a proxy for their performance on the full dataset.
      </p>
      <p>
        The use of subsets to evaluate machine learning con gurations is also used
in Hyperband [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ]. Hyperband dynamically allocates resources to more
promising algorithm con gurations, based on experiments executed on gradually more
resources. One application that is explored is using data samples as a resource,
and using increasingly bigger subsets of the data to evaluate the algorithm
congurations with. In a speci c selection of datasets they showed that using this
technique improved over Random Search, SMAC and Tree-structured Parzen
Estimators, as introduced in [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ].
      </p>
      <p>To the best of our knowledge, however, it was never before used in
combination with evolutionary algorithms for pipeline construction.
3</p>
    </sec>
    <sec id="sec-3">
      <title>Methods</title>
      <p>In this section, we describe the modi cations made to TPOT. First, we give
a brief description of how TPOT constructs and optimizes machine learning
pipelines. Then, we describe the Layered TPOT (LTPOT) structure and
motivate its design.
3.1</p>
      <sec id="sec-3-1">
        <title>Structure of TPOT</title>
        <p>
          To construct and optimize machine learning pipelines, TPOT uses tree-based
genetic programming [
          <xref ref-type="bibr" rid="ref2">2</xref>
          ]. Pipelines are represented by genetic programming trees.
An example of a tree representation of a machine learning pipeline is shown
in Fig. 1. The tree consists of several nodes, which can either be Primitives or
Terminals, in Fig. 1 depicted as squares and ellipses, respectively. Primitives are
operators which require input, such as an algorithm requiring data and
hyperparameter values. Terminals are constants which can be passed to primitives.
Finally, a primitive can also be used as input to a primitive, as can be seen
in Fig.1, where the StandardScaler primitive provides the scaled dataset to the
Bernoulli Naive Bayes algorithm. Information of required input and output types
is used to ensure that only valid pipelines are constructed.
        </p>
        <p>Bernoulli</p>
        <p>Naive Bayes
Standard
Scaler
Dataset</p>
        <p>Alpha = 1.0</p>
        <p>The evolutionary algorithm then works by using these machine learning
pipelines as their individuals. It will perform mutation, for example changing
a hyperparameter or adding a preprocessing step, as well as crossover, by
selecting two pipelines which share a primitive, which allows them to exchange
subtrees or leaves. Finally, pipelines are evaluated and assigned a tness score,
so that a selection procedure can determine which individuals should be in the
next generation.</p>
        <p>As mentioned earlier, in theory these pipeline trees could be arbitrarily large.
However, very extensive machine learning pipelines are often undesirable. With
more hyperparameters, long pipelines can be harder to tune, be more prone to
over tting, hinder understanding of the nal model, and require more time to
be evaluated, slowing down the optimization process.</p>
        <p>
          Because of these reasons, we use a multiobjective optimization technique,
NSGA-II[
          <xref ref-type="bibr" rid="ref4">4</xref>
          ], to select individuals based on the Pareto front of the trade-o
between the pipeline length and its performance.
3.2
        </p>
      </sec>
      <sec id="sec-3-2">
        <title>Layered TPOT Concept</title>
        <p>During the TPOT optimization process, most time is spent on evaluating
machine learning pipelines. Every machine learning pipeline is evaluated on the full
dataset, which can take a lot of time. Layered TPOT (LTPOT) aims to reduce
the amount of pipelines evaluated on the entire dataset by doing a selection
process, so that only the most promising pipelines need to be evaluated on the
full dataset. It achieves this by evaluating pipelines on a small subset of the
data, and only if a pipeline exhibits good performance on that subset it will be
evaluated on more data.</p>
        <p>
          Age-Layered Population To incorporate a fair evaluation of pipelines on
subsets gradually increasing in size, we designed a layered structure to separate
competition among individuals. In this, we were inspired by the Age-Layered
Population Structure (ALPS) [
          <xref ref-type="bibr" rid="ref9">9</xref>
          ], where individuals are segregated into layers to
reduce the problem of premature convergence. The problem of premature
convergence occurs when the individuals in the population converge to a good local
optimum, which means that any new individuals are unlikely to be competitive
with this local optimum, and through selection are ltered out of the population
before they themselves can converge to a local optimum. In ALPS, all individuals
were given an age which would increase as an individual or its o spring would
remain in the population, and perform breeding and selection only in separate
age groups called layers. This segregation is important, because otherwise the
old, locally well optimized, individuals would often prevent young individuals
from being able to survive the multiple generations they needed to get closer to
their local optimum.
        </p>
        <p>Layers in LTPOT In LTPOT, we wish to evaluate pipelines on subsets of
the data. However, the performance of a machine learning pipeline is in uenced
by the amount of training data it receives. This means that when evaluating
individuals on di erent subsets of the data, their performance cannot directly be
compared to one another. Therefore, the individuals are segregated into layers.</p>
        <p>At each layer, individuals will be evaluated on a subset of di erent size. The
layers are ordered, such that in the rst layer the subset used to evaluate the
individuals is the smallest, and every layer above that will increase the subset
size. When an individual performs well in one layer, it will eventually be
transferred to the next. This way, only the best pipelines will be evaluated on the
entire dataset in the last layer. A visual overview of the structure and ow of
LTPOT is given in Fig.2.</p>
        <sec id="sec-3-2-1">
          <title>Layer 1</title>
        </sec>
        <sec id="sec-3-2-2">
          <title>N/8 samples</title>
          <p>new population
new
new
new</p>
        </sec>
        <sec id="sec-3-2-3">
          <title>Layer 2</title>
        </sec>
        <sec id="sec-3-2-4">
          <title>N/4 samples</title>
        </sec>
        <sec id="sec-3-2-5">
          <title>Layer 3</title>
        </sec>
        <sec id="sec-3-2-6">
          <title>N/2 samples</title>
        </sec>
        <sec id="sec-3-2-7">
          <title>Layer 4</title>
          <p>N samples
top k
rest
rest
top k
rest
top k
Correlation of performance between layers In the extreme, the
selection procedure implicitly assumes that the relative performance of two pipelines
is the same when evaluated on a subset of the dataset as it is on the entire
dataset. However, this assumption does not always hold. The learning curves for
two pipelines may cross, meaning that one pipeline performs better after being
trained on a small subset of the data, while the other performs better when
trained on the full dataset. Generally speaking, as the pipelines are evaluated on
more data, the relative performance correlates more strongly with the relative
performance obtained when they are trained on the entire dataset. This is why
our design will evaluate the pipelines on gradually larger subsets of data, so that
when a pipeline performs worse than expected as the dataset increases, it need
not be evaluated on bigger datasets. Unfortunately, in the case where a pipeline
has poor performance on a small subset, but good performance on the entire
dataset, LTPOT will not pick up this pipeline.</p>
          <p>
            We set up an experiment to verify whether or not there is indeed a correlation
between the performance of a pipeline on a sample of the dataset and its
performance on the entire dataset. In this experiment, we evaluated 50 pipelines
on 12 datasets with ten times 10-fold cross-validation, with various samples
sizes of the dataset as well as the entire dataset. All datasets were part of the
Penn Machine Learning Benchmark (PMLB) [
            <xref ref-type="bibr" rid="ref13">13</xref>
            ]. The average AUROC of each
pipeline for each sample size was determined for each dataset. Sample sizes were
fN=21; : : : ; N=25g, where N is the number of instances in the dataset. Because
the evolutionary algorithm performs pipeline selection based on the ranking of
the algorithms, rather than the value of the score metric, we ranked the averaged
scores and computed the correlation of the rankings.
          </p>
          <p>dataset
satimage
clean2
ann-thyroid
twonorm
mushroom
agaricus-lepiota
coil2000
pendigits
nursery
magic
letter
krkopt
instances features</p>
          <p>In Table 1 the Spearman -values are displayed, that signify the correlation
between the ranking of pipelines trained on a sample of the dataset, and the
ranking of pipelines when trained on the entire dataset. The p-values are omitted
because in all cases they are smaller than 0:0001 and all correlations are thus
signi cant. From Table 1 we see that that there is a positive correlation between
the rankings for all sample sizes and datasets, and the correlation gets stronger
as the sample size gets closer to the full dataset size.</p>
          <p>
            We experimented with various curve tting methods to extrapolate the
learning curves of pipelines so that crossing learning curves might be predicted earlier,
but they did not improve the results. In future work the use of meta-learning for
learning curve extrapolation, such as in [
            <xref ref-type="bibr" rid="ref16">16</xref>
            ], will be tried.
3.3
          </p>
        </sec>
      </sec>
      <sec id="sec-3-3">
        <title>Layered TPOT Algorithm</title>
        <p>We will now give a more in-depth break down of the algorithm used in
LTPOT. Algorithm 1 shows the core of the layered algorithm LayeredEA, and
Algorithm 2 gives descriptions of the subroutines called from LayeredEA.
Algorithm 1 Layered Evolutionary Algorithm
. Denote the number of layers.</p>
        <p>. Denote population size.</p>
        <p>Selecting parameter values Before calling LayeredEA, the number of layers
as well as their sample size is de ned. The sample size of a layer dictates how
many instances are sampled from the dataset, to create the subset that the
pipelines in that layer will be evaluated on. The subset is created by strati ed
Algorithm 2 Functions called in Layered EA
1: function VarOr(P opulation; N )</p>
        <p>Performs mutation and crossover on the individuals in P opulation, creating N new
individuals.</p>
        <p>end function
2: function Evaluate(P opulation; s; D)</p>
        <p>Evaluates each individual on a subset of dataset D, created by taking s instances
by strati ed sampling. Individuals are evaluated based on 3-fold CV accuracy and
number of components in the pipeline. Results are saved as attributes of
individuals.3
end function
3: function Selection(P opulation; p)</p>
        <p>Creates pareto-fronts based on the accuracy-pipeline complexity trade-o . Then
takes the rst p individuals after ordering the population by which pareto-front
they are in (individuals in the rst front come rst).</p>
        <p>end function
4: function Top(P opulation; k)</p>
        <p>Returns the k best individuals of the population, by constructing a pareto-front
based on the accuracy-pipeline complexity trade-o .</p>
        <p>end function
5: function NewPopulation(P )</p>
        <p>Creates a new population of P individuals.</p>
        <p>end function
uniform random sampling without replacement, and pipelines will be evaluated
on this subset with 5-fold cross-validation. In this study, the sample sizes used
in each layer are dictated by the size of the dataset. Let the dataset contain N
instances, then the nal layer will always train on the entire dataset, and each
subsequent layer will use half of the data the layer above did. In this study, the
number of layers used is 4, for every dataset. The respective sample sizes used
at each layer are thus N8 , N4 , N2 and N . In this paper we use the term higher
layer loosely to denote layers which sample more of the entire dataset (i.e. the
layer with sample size N2 is higher than the layer with sample size N4 ).</p>
        <p>There are two ways to specify for how long the main loop of lines 7 through 20
should run: a set amount of generations G, or an amount of time. We chose not
to work with a speci c number of generations G, but instead let the main loop in
lines 7 through 20 run for eight hours. For parameter g, the amount of generations
between transfer, we experimented with values 2 and 16. With a g value of 2,
LTPOT acts almost as a lter, allowing only very little optimization in early
layers. A value of 16, however, allows many generations of early optimization,
before passing individuals through to the next layer.</p>
        <p>For the nal part of the initialization, a population of size P is generated
randomly.</p>
        <p>LayeredEA When calling LayeredEA, as shown in Algorithm 1, the rst step
is to denote constants based on the input, speci cally the number of layers M
(line 1) and the size of the population P (line 2), as well assigning the initial
population to the rst layer (line 4) and marking all other layers as empty (line
5).</p>
        <p>Then, the evolutionary algorithm will start iterating through the generations
(line 6-20), at each generation again progressing the evolutionary algorithm in
each layer (line 7-13) and then if required transferring individuals from one layer
to the next (line 14-19).</p>
        <p>Progressing the evolutionary algorithm in each layer (line 7-13), only happens
for layers which are active. This means that there must be a population in the
layer ( rst clause on line 8), which it may not yet have if not enough transfers
have taken place yet. Additionally, layers which evaluate on more data are not
active every generation (second clause on line 8), this is motivated below.</p>
        <p>When progressing the evolutionary algorithm, it executes the same steps as
TPOT would. First, a new population is created from the individuals evaluated
during the last generation in the same layer, by performing mutation and
crossover (line 9). However, every time a layer is passed new individuals from a
previous layer, as well as in the very rst generation, the provided population is
taken as is without creating o spring.4 The new individuals are then evaluated
based on the sample of the data as de ned by their layer (line 10). Finally, based
on the Pareto-front of the trade-o between the performance score of the pipeline
as well as the pipeline length, the best individuals are picked among the new
4 This is not incorporated in the pseudo-code of algorithm 1, to keep the general
structure clear.
individuals as well as last generation's (line 11). Then, every g generations, the
best individuals from each layer get passed to the next one. In our con guration
we chose to transfer half of the layer's population.</p>
        <p>The nal pipeline chosen by LTPOT is the pipeline which has the best score in
the highest layer (line 21).</p>
        <p>Optimizations There are a few scenario's that either require some additional
clari cation, or deviate from the above algorithm:</p>
        <p>The rst time a layer receives individuals from the layer before it, the
selection procedure will oversample from this population so that the population in
the layer will also grow to size P (line 11). This is done so that in subsequent
generations, more variations of the original pipelines will exist, allowing for a
better search for optimal pipelines.</p>
        <p>Secondly, if LTPOT runs for a speci ed amount of generations, layers will
be turned o whenever their population can no longer reach the highest layer.
For example, let LTPOT be con gured with 4 layers. When LTPOT is less than
3 g generations away from completion, any individual in the lowest layer will
never reach the highest layer, thus rendering any results obtained in this layer
useless. Whenever this happens, the respective layer will no longer have their
individuals evaluated or transferred to a next layer.</p>
        <p>Next, there is the earlier mentioned restriction on activating layers as shown
in the second clause on line 8. LTPOT has a selection process in place for which
pipelines will be evaluated on the entire dataset. This means that at higher
layers, the pipelines in the population are likely already quite good. Because of
these two factors, we want to limit the exploration in higher layers. To do this,
instead of running the evolutionary algorithm in each layer every generation,
higher layers can be turned o for some generations. In this study, for a layered
structure with M layers, layer l is progressed for min(2(M l+1); g) generations
every g generations, with l 2 f1; ; M g. This is demonstrated with g = 12 and
M = 4 in Fig.3, and checked in the second clause on line 8. We have not yet
evaluated if this leads to signi cant improvements.</p>
        <p>Finally, to prevent any one pipeline from halting the algorithm, a pipeline's
evaluation is automatically stopped if it exceeds a given time limit. If the
evaluation is stopped this way, the pipeline is marked as failure and will not be
considered as parent for the next generation. This behavior is present in the
original TPOT, and adopted to LTPOT by further decreasing the time limit
by layer. In the top layer, each individual is allowed the same evaluation time
as it would in TPOT. However, for lower layers, the time allowed is decreased
quadratically proportional to the sample size (a layer with half the data gets a
fourth of the time per individual).</p>
        <p>Layer 1</p>
        <p>Layer 2</p>
        <p>Layer 3</p>
        <p>Layer 4</p>
        <p>On
Off</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>Empirical evaluation</title>
      <sec id="sec-4-1">
        <title>Experimental Questions</title>
        <p>The goal of LTPOT is to nd pipelines at least as good as TPOT's, but in
less time. This also means that, given the same amount of time, LTPOT could
very well nd better pipelines. To assess whether or not this is achieved, we will
evaluate LTPOT in three ways.</p>
        <p>
          First, we want to evaluate if, given the same amount of time, LTPOT will
outperform TPOT when their best found pipelines are compared. To do this, a
ranking is constructed between TPOT and LTPOT for each dataset over time,
by ranking the performance of the best pipeline found so far at regular time
intervals. We omit a comparison to Random Search, as TPOT compared favorably
to Random Search in earlier work [
          <xref ref-type="bibr" rid="ref12">12</xref>
          ].
        </p>
        <p>Secondly, to quantify how much faster LTPOT is, we compare the time
needed for LTPOT to nd a pipeline at least as good as the best pipeline found
by TPOT. We then compare it to the time TPOT needs to nd this pipeline.</p>
        <p>Finally, we will also compare the Area Under the Receiver Operating
Characteristic curve (AUROC) of the nal pipelines found by each method, so we
can quantify the di erence in model quality between the methods.
4.2</p>
      </sec>
      <sec id="sec-4-2">
        <title>Experimental setup</title>
        <p>
          We compare LTPOT to the original TPOT by evaluating both on a selection of
18 large datasets. We speci cally chose larger datasets so that there will be a
distinct di erence in time needed to evaluate individuals on the entire dataset
versus just a subset. All datasets in the selection contain at least one hundred
thousand instances, though most contain exactly one million. The selection
includes pseudo-arti cial datasets described in [
          <xref ref-type="bibr" rid="ref17">17</xref>
          ]. The datasets are available for
download and inspection on OpenML5, an open database for machine learning
5 https://www.openml.org/s/69
experiments [
          <xref ref-type="bibr" rid="ref19">19</xref>
          ]. We previously evaluated LTPOT on a selection of datasets
from the Penn Machine Learning Benchmark [
          <xref ref-type="bibr" rid="ref13">13</xref>
          ], which TPOT was initially
evaluated on. Because those datasets were relatively small, pipeline evaluations
were quick even on the full dataset, so there was no signi cant bene t of using
LTPOT. On each dataset, each method is evaluated nine times, starting with a
di erent initial generation each time.
        </p>
        <p>As described earlier, there are many hyperparameters with which to tune
LTPOT. In this study, we only experiment with g, the amount of generations
between transfer. The choices for g will be 2 and 16, and these con gurations
will be referred to as LTPOT-2 and LTPOT-16, respectively. This is meant to
give insight in the e ectiveness of two functions of LTPOT: ltering and early
optimization. For LTPOT-2, layers act almost solely as a lter, by passing the
best individuals to the next layer every other iteration, not much optimization
takes place in lower layers, but it does allow for the early discarding of pipelines
which seem to perform poorly. With LTPOT-16, we instead see that a lot of
optimization can take place based on results found in lower layers, as relatively
more time is spent evaluating and improving individuals in lower layers
compared to LTPOT-2. In other words, LTPOT-2's rst layer allows for more early
exploration, while LTPOT-16's rst layer is more focused on exploitation.</p>
        <p>The amount of individuals transferred, k, will be set to 15, which is half of the
total population size P = 30. Each LTPOT con guration, as well as TPOT, is
run nine times per dataset, each time with a di erent random seed, guaranteeing
a di erent initial population and subsequent choices for crossover and mutation.
Each run set to last 8 hours, but each individual pipeline may only be evaluated
for at most 10 minutes. We explored di erent values for P and di erent amounts
of evaluation time per individual, while keeping the total run time constant at
8 hours, and found that for the chosen datasets these values strike a balance
between having a diverse enough population and being able to evaluate enough
generations.
4.3</p>
      </sec>
      <sec id="sec-4-3">
        <title>Results</title>
        <p>
          First, we compare the various con gurations by their average rank over time,
which can be seen in Fig. 4. In this gure, for each con guration, for every
dataset and seed, the best found pipelines so far are ranked against each other
every minute. For each method, the average Friedman rank [
          <xref ref-type="bibr" rid="ref5">5</xref>
          ] across all these
datasets and seeds is calculated based on the highest AUROC score achieved by
the best pipeline so far, using the xed hyperparameter values stated above. To
calculate the rank, we consider the result a tie if the di erence in AUROC values
is smaller than 0.1. A lower rank is better.
        </p>
        <p>In Fig. 4, we see that LTPOT on average achieves the best scores throughout
the entire 8 hour period. LTPOT-16 starts by outperforming LTPOT-2 slightly,
but as time goes on its relative performance drops, even being surpassed by
TPOT. From this, it seems that while LTPOT works well as a lter, optimization
in early layers does not pay o beyond the early stages. Thus, a lower value for g
is better based on these results. Furthermore, we see that towards the end TPOT
is decisively improving over LTPOT-16, but only very slowly over LTPOT-2, as
the average rank of LTPOT-2 increases only very slowly.</p>
        <p>A di erent rank does not necessarily mean the found model performance
di ers a lot. To clarify this, we look at the di erence in AUROC by dataset per
con guration, as seen for 9 of 18 datasets in Fig. 5.6</p>
        <p>In Fig. 5 we show a boxplot that describes the distribution of AUROC scores
of the nal pipelines by each method. No single method is dominant over the
others, and di erences in AUROC scores are small for almost all datasets. Using
a student t-test, we determined that there is no statistically signi cant di erence
(p &lt; 0:05) between the nal pipelines (after the full 8 hour time budget).</p>
        <p>However, looking at the average ranking by con guration in Fig. 4, we see
that under smaller time budgets LTPOT-2 often nds pipelines which are better
than TPOT. In this scenario, it is interesting to see how much time LTPOT
needs to nd a pipeline at least as good as the best pipeline TPOT found. We
compared LTPOT-2 to TPOT for each dataset and seed, and looked at how
long it took for the method which found the best pipeline to nd a pipeline at
least as good as the best found pipeline by the other method. Figure 6 shows
the time di erence (in minutes) between nding these equally good pipelines.
Positive values indicate that LTPOT is faster. Yellow distributions correspond
to seeds where LTPOT eventually found the best pipeline, and show how much
sooner LTPOT found a pipeline at least as good as the best pipeline of TPOT.
6 A similar gure for the other 9 datasets can be found in Appendix A.</p>
        <p>Blue distributions correspond to cases where TPOT eventually found the best
pipeline, and show how much later TPOT found a pipeline at least as good as
LTPOT's best.</p>
        <p>In general, when LTPOT nds the best pipeline, it nds a pipeline at least
as good as TPOT's best pipeline much sooner. In particular for LTPOT-16 we
see that it often is at least 200 minutes faster. Even in the cases where TPOT
eventually nds the best pipelines, we see that it often nds a pipeline at least
as good as LTPOT's best only after LTPOT already found it. This again is
especially true for LTPOT-16, where almost all yellow distributions are entirely
positive.</p>
        <p>However, even when one method nds a pipeline at least as good as the
other method's eventual best pipeline, it can still be the case that the eventual
worst method at that same time already has quite a good pipeline. Therefore,
we compare the performance of the best pipeline of each method found at time t,
where time t is the time where the best method nds a pipeline at least as good
as the eventual best pipeline of the worst method. Between 18 datasets and 9
seeds, there are 162 comparisons between TPOT and LTPOT-2 or LTPOT-16.
The comparison in AUROC at time t is shown in Figure 7.</p>
        <p>We see that when TPOT nds a pipeline at least as good as LTPOT's best,
in most cases it does so when LTPOT already has found a pipeline at most
11a6ir9lines BN1G1 s8p0ect_test B1N18G2 adult BNG1 2m0ushroComlick_p1r2e1d7iction_smaBlN1G24 credit­a BN1G26 credit­g B1N31G sick B1N3G2 sonar BNG1 3s5pambase  B1N3G9 trains
Fig. 7: Shows the AUROC di erence at time t, which is the time the best method
(color coded) nds a pipeline at least as good as the other method will nd.
0.01 AUROC worse. However, when LTPOT nds a pipeline at least as good
as TPOT's best, TPOT has relatively worse pipelines more often, and in some
cases as much as over 0.2 AUROC worse.</p>
        <p>From this we conclude that in many cases LTPOT nds good pipelines faster.
While LTPOT-2 does not always nd the best pipeline, when it doesn't, it nds
comparable pipelines at least as quickly as TPOT. LTPOT-16 nds comparable
pipelines even quicker, although it becomes less competitive under larger time
budgets.
The structure of Layered TPOT allows for more hyperparameters to be tuned,
and their e ect remains unexplored at this point. The number of layers as well
as the e ect of their granularity could possibly be tuned to the dataset. Whether
or not to turn o higher layers, and with which frequency, should be explored
as well. The amount of individuals to transfer between layers may also change
how quickly higher layers can optimize pipelines. The choice of the amount
of generations before transfer, g, will in uence how much optimization will be
done in the lower layers. Perhaps these parameters should change over time in a
single run. All of these choices come in addition to the hyperparameters already
available for TPOT, such as the population size, mutation rate and crossover
rate.</p>
        <p>Finally, there are possible changes not yet captured in hyperparameters. For
instance, it might be better to favor crossover over mutation in higher layers, so
that the focus of exploration shifts to combining promising pipelines in higher
layers. It could be that having a big population in the higher layers is
unnecessary, and shrinking population size there might yield similar results in a faster
time frame. Currently, the way to evaluate individuals quickly is to sample a
number of instances of the data. Instead, one could create a subset by selecting
features, or apply compression techniques to represent the data. We will explore
these aspects in subsequent work.</p>
        <p>Results of this study will be made available on OpenML7, and the code for
Layered TPOT can be found on Github8.
5</p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>Conclusion</title>
      <p>In this paper we presented an extension to TPOT called Layered TPOT. In the
extension, instead of evaluating each pipeline on all data, only pipelines which
have shown good results on subsets of the data are evaluated on all data. It
does this by introducing layers. In each layer a distinct group of individuals is
subject to the evolutionary algorithm, but individuals are only evaluated on a
subset of the data as de ned by the layer. Each subsequent layer will evaluate
7 www.openml.org
8 https://github.com/PG-TUe/tpot/tree/layered
the individuals on more data, and if an individual performs well in one layer, it
will be transferred to the next, to be trained on more data and compete with
other promising pipelines trained on the same subset size.</p>
      <p>To determine the usefulness of LTPOT, two con gurations have been
compared to TPOT, on a selection of 18 large datasets. The results showed that
LTPOT is not strictly better than TPOT, but it often nds good pipelines much
faster, and under smaller time budgets, it outperforms TPOT on average.
Moreover, LTPOT allows for a lot of exibility in the con guration of its structure,
and the e ects of changes to these con gurations remain to be explored.</p>
    </sec>
    <sec id="sec-6">
      <title>A Additional Experiment Results</title>
      <p>Below is a gure similar to Figure5 for the other 9 datasets in the benchmark.
126
77
1502
140
0.296
0.294
C0.292
RO0.290
U0.288
A
 
 ­ 0.286
1
0.284
0.282
0.125
C
O0.120
R
U
  ­A0.115
10.110
0.105
0.0085
C0.0080
RO0.0075
U0.0070
A
 
 ­10.0065
0.0060
0.0055
0 50 100 150 200 250 300 350 400 450
time (minutes)
0
100
400</p>
      <p>500
0
100
400</p>
      <p>500
0
100
400</p>
      <p>500
CO0.090
R
U
  ­A0.085
1
0.054
0.053
C0.052
RO0.051
U0.050
A
 
 ­ 0.049
1
0.048
0.047
CO0.06
RU0.05
0.0042
C
O0.0041
R
U
  ­A0.0040
10.0039
0.328
0
100
400</p>
      <p>500
0
100
400</p>
      <p>500
0
100
400</p>
      <p>500
Fig. 10: Shows per dataset per seed per method when the best pipeline was found,
and its '1-AUROC' score.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Abdulrahman</surname>
            ,
            <given-names>S.M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Brazdil</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Van Rijn</surname>
            ,
            <given-names>J.N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vanschoren</surname>
          </string-name>
          , J.:
          <article-title>Algorithm selection via meta-learning and sample-based active testing</article-title>
          .
          <source>In: Proceedings of the 2015 International Conference on Meta-Learning and Algorithm</source>
          Selection - Volume
          <volume>1455</volume>
          . pp.
          <volume>55</volume>
          {
          <fpage>66</fpage>
          . MetaSel'15,
          <string-name>
            <surname>CEUR-WS</surname>
          </string-name>
          .org, Aachen, Germany, Germany (
          <year>2015</year>
          ), http://dl.acm.org/citation.cfm?id=
          <volume>3053836</volume>
          .
          <fpage>3053845</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Banzhaf</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Francone</surname>
            ,
            <given-names>F.D.</given-names>
          </string-name>
          , Keller, R.E.,
          <string-name>
            <surname>Nordin</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <article-title>Genetic Programming: An Introduction: on the Automatic Evolution of Computer Programs</article-title>
          and
          <string-name>
            <given-names>Its</given-names>
            <surname>Applications</surname>
          </string-name>
          . Morgan Kaufmann Publishers Inc., San Francisco, CA, USA (
          <year>1998</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Bergstra</surname>
            ,
            <given-names>J.S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bardenet</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bengio</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kegl</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          :
          <article-title>Algorithms for hyper-parameter optimization</article-title>
          . In:
          <string-name>
            <surname>Shawe-Taylor</surname>
          </string-name>
          , J.,
          <string-name>
            <surname>Zemel</surname>
            ,
            <given-names>R.S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bartlett</surname>
            ,
            <given-names>P.L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Pereira</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Weinberger</surname>
            ,
            <given-names>K.Q</given-names>
          </string-name>
          . (eds.)
          <source>Advances in Neural Information Processing Systems</source>
          <volume>24</volume>
          , pp.
          <volume>2546</volume>
          {
          <fpage>2554</fpage>
          . Curran Associates, Inc. (
          <year>2011</year>
          ), http://papers.nips.cc/paper/4443- algorithms
          <article-title>-for-hyper-parameter-optimization</article-title>
          .pdf
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Deb</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Pratap</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Agarwal</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Meyarivan</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          :
          <article-title>A fast and elitist multiobjective genetic algorithm: Nsga-ii</article-title>
          .
          <source>IEEE Transactions on Evolutionary Computation</source>
          <volume>6</volume>
          (
          <issue>2</issue>
          ),
          <volume>182</volume>
          {197 (Apr
          <year>2002</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Demsar</surname>
          </string-name>
          , J.:
          <article-title>Statistical comparisons of classi ers over multiple data sets</article-title>
          .
          <source>Journal of Machine Learning Research 7</source>
          ,
          <issue>1</issue>
          {
          <fpage>30</fpage>
          (
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Feurer</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Klein</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Eggensperger</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Springenberg</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Blum</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hutter</surname>
          </string-name>
          , F.:
          <article-title>E cient and robust automated machine learning</article-title>
          . In: Cortes,
          <string-name>
            <given-names>C.</given-names>
            ,
            <surname>Lawrence</surname>
          </string-name>
          ,
          <string-name>
            <given-names>N.D.</given-names>
            ,
            <surname>Lee</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.D.</given-names>
            ,
            <surname>Sugiyama</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            ,
            <surname>Garnett</surname>
          </string-name>
          ,
          <string-name>
            <surname>R</surname>
          </string-name>
          . (eds.)
          <source>Advances in Neural Information Processing Systems</source>
          <volume>28</volume>
          , pp.
          <volume>2962</volume>
          {
          <fpage>2970</fpage>
          . Curran Associates, Inc. (
          <year>2015</year>
          ), http://papers.nips.cc/paper/5872-e cient-and
          <article-title>-robustautomated-machine-learning</article-title>
          .pdf
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Feurer</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Springenberg</surname>
            ,
            <given-names>J.T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hutter</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          :
          <article-title>Initializing bayesian hyperparameter optimization via meta-learning</article-title>
          .
          <source>In: Proceedings of the Twenty-Ninth AAAI Conference on Arti cial Intelligence</source>
          . pp.
          <volume>1128</volume>
          {
          <fpage>1135</fpage>
          . AAAI'
          <fpage>15</fpage>
          , AAAI Press (
          <year>2015</year>
          ), http://dl.acm.org/citation.cfm?id=
          <volume>2887007</volume>
          .
          <fpage>2887164</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Hall</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Frank</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Holmes</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Pfahringer</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Reutemann</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Witten</surname>
            ,
            <given-names>I.H.</given-names>
          </string-name>
          :
          <article-title>The weka data mining software: An update</article-title>
          .
          <source>SIGKDD Explor. Newsl</source>
          .
          <volume>11</volume>
          (
          <issue>1</issue>
          ),
          <volume>10</volume>
          {18 (Nov
          <year>2009</year>
          ), http://doi.acm.
          <source>org/10</source>
          .1145/1656274.1656278
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Hornby</surname>
            ,
            <given-names>G.S.</given-names>
          </string-name>
          : Alps:
          <article-title>The age-layered population structure for reducing the problem of premature convergence</article-title>
          .
          <source>In: Proceedings of the 8th Annual Conference on Genetic and Evolutionary Computation</source>
          . pp.
          <volume>815</volume>
          {
          <fpage>822</fpage>
          . GECCO '06,
          <string-name>
            <surname>ACM</surname>
          </string-name>
          , New York, NY, USA (
          <year>2006</year>
          ), http://doi.acm.
          <source>org/10</source>
          .1145/1143997.1144142
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Hutter</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hoos</surname>
            ,
            <given-names>H.H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Leyton-Brown</surname>
          </string-name>
          , K.:
          <article-title>Sequential model-based optimization for general algorithm con guration (extended version)</article-title>
          .
          <source>Tech. Rep. TR-2010-10</source>
          , University of British Columbia, Department of Computer Science (
          <year>2010</year>
          ), available online: http://www.cs.ubc.ca/~hutter/papers/10-TR-SMAC.pdf
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Li</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Jamieson</surname>
            ,
            <given-names>K.G.</given-names>
          </string-name>
          , DeSalvo, G.,
          <string-name>
            <surname>Rostamizadeh</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Talwalkar</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>E - cient hyperparameter optimization and in nitely many armed bandits</article-title>
          .
          <source>CoRR abs/1603</source>
          .06560 (
          <year>2016</year>
          ), http://arxiv.org/abs/1603.06560
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Olson</surname>
            ,
            <given-names>R.S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bartley</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Urbanowicz</surname>
            ,
            <given-names>R.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Moore</surname>
            ,
            <given-names>J.H.</given-names>
          </string-name>
          :
          <article-title>Evaluation of a tree-based pipeline optimization tool for automating data science</article-title>
          .
          <source>CoRR abs/1603</source>
          .06212 (
          <year>2016</year>
          ), http://arxiv.org/abs/1603.06212
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Olson</surname>
            ,
            <given-names>R.S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Cava</surname>
            ,
            <given-names>W.L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Orzechowski</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Urbanowicz</surname>
            ,
            <given-names>R.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Moore</surname>
            ,
            <given-names>J.H.</given-names>
          </string-name>
          :
          <article-title>PMLB: A large benchmark suite for machine learning evaluation and comparison</article-title>
          .
          <source>CoRR abs/1703</source>
          .00512 (
          <year>2017</year>
          ), http://arxiv.org/abs/1703.00512
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Olson</surname>
            ,
            <given-names>R.S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Urbanowicz</surname>
            ,
            <given-names>R.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Andrews</surname>
            ,
            <given-names>P.C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lavender</surname>
            ,
            <given-names>N.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kidd</surname>
            ,
            <given-names>L.C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Moore</surname>
            ,
            <given-names>J.H.</given-names>
          </string-name>
          :
          <article-title>Applications of Evolutionary Computation: 19th European Conference</article-title>
          ,
          <source>EvoApplications</source>
          <year>2016</year>
          , Porto, Portugal, March 30 { April 1,
          <year>2016</year>
          , Proceedings,
          <string-name>
            <surname>Part</surname>
            <given-names>I</given-names>
          </string-name>
          , chap.
          <source>Automating Biomedical Data Science Through Tree-Based Pipeline Optimization</source>
          , pp.
          <volume>123</volume>
          {
          <fpage>137</fpage>
          . Springer International Publishing (
          <year>2016</year>
          ), http://dx.doi.
          <source>org/10.1007/978-3-319-31204-0 9</source>
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Pedregosa</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Varoquaux</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gramfort</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Michel</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Thirion</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Grisel</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Blondel</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Prettenhofer</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Weiss</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dubourg</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vanderplas</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Passos</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Cournapeau</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Brucher</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Perrot</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Duchesnay</surname>
          </string-name>
          , E.:
          <article-title>Scikit-learn: Machine learning in python</article-title>
          .
          <source>J. Mach. Learn. Res</source>
          .
          <volume>12</volume>
          ,
          <issue>2825</issue>
          {2830 (Nov
          <year>2011</year>
          ), http://dl.acm.org/citation.cfm?id=
          <volume>1953048</volume>
          .
          <fpage>2078195</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16. van Rijn,
          <string-name>
            <given-names>J.</given-names>
            ,
            <surname>Abdulrahman</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            ,
            <surname>Brazdil</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            ,
            <surname>Vanschoren</surname>
          </string-name>
          , J.:
          <article-title>Fast algorithm selection using learning curves</article-title>
          .
          <source>In: Lecture Notes in Computer Science (IDA</source>
          <year>2015</year>
          ). vol.
          <volume>9385</volume>
          , pp.
          <volume>298</volume>
          {
          <issue>309</issue>
          (
          <year>2015</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17. van Rijn,
          <string-name>
            <given-names>J.</given-names>
            ,
            <surname>Holmes</surname>
          </string-name>
          ,
          <string-name>
            <given-names>G.</given-names>
            ,
            <surname>Pfahringer</surname>
          </string-name>
          ,
          <string-name>
            <given-names>B.</given-names>
            ,
            <surname>Vanschoren</surname>
          </string-name>
          , J.:
          <source>Algorithm selection on data streams. Lecture Notes in Computer Science (Proceedings of Discovery Science</source>
          <year>2014</year>
          )
          <volume>8777</volume>
          ,
          <fpage>325</fpage>
          {
          <fpage>336</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18.
          <string-name>
            <surname>Thornton</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hutter</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hoos</surname>
            ,
            <given-names>H.H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Leyton-Brown</surname>
          </string-name>
          , K.:
          <article-title>Auto-weka: Combined selection and hyperparameter optimization of classi cation algorithms</article-title>
          .
          <source>In: Proceedings of the 19th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining</source>
          . pp.
          <volume>847</volume>
          {
          <fpage>855</fpage>
          . KDD '13,
          <string-name>
            <surname>ACM</surname>
          </string-name>
          , New York, NY, USA (
          <year>2013</year>
          ), http://doi.acm.
          <source>org/10</source>
          .1145/2487575.2487629
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          19.
          <string-name>
            <surname>Vanschoren</surname>
            , J., van Rijn,
            <given-names>J.N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bischl</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Torgo</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          :
          <article-title>Openml: Networked science in machine learning</article-title>
          .
          <source>SIGKDD Explorations</source>
          <volume>15</volume>
          (
          <issue>2</issue>
          ),
          <volume>49</volume>
          {
          <fpage>60</fpage>
          (
          <year>2013</year>
          ), http://doi.acm.
          <source>org/10.1145/2641190.2641198 0.130 200 300 time (minutes) 0 100 400 500 200 300 time (minutes) 200 300 time (minutes) 0 100 400 500 200 300 time (minutes) 0 100 400 500 200 300 time (minutes) 200 300 time (minutes) 0 100 400 500 200 300 time (minutes) 0 50 100 150 200 250 300 350 400 450 time (minutes) 0.080 0.08 0.07 0.02 0.050 0.045 C0</source>
          .040
          <string-name>
            <given-names>O</given-names>
            <surname>R0.035</surname>
          </string-name>
          <string-name>
            <surname>U</surname>
          </string-name>
           ­
          <source>A0.030 10.025 0.020 0.0043 0.0038 0.340 0.338 124 132 269 143 135 200 300 time (minutes) 0 100 400 500 200 300 time (minutes) 0 100 400 500 200 300 time (minutes) 200 300 time (minutes) 400 500 0 100 400 500 200 300 time (minutes) 200 300 time (minutes) 0 50 100 150 200 250 300 350 400 450 time (minutes)</source>
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>