Coder Social home page Coder Social logo

automl / smac3 Goto Github PK

View Code? Open in Web Editor NEW
1.0K 41.0 217.0 145.48 MB

SMAC3: A Versatile Bayesian Optimization Package for Hyperparameter Optimization

Home Page: https://automl.github.io/SMAC3/v2.0.2/

License: Other

Python 99.17% Shell 0.38% Makefile 0.46%
bayesian-optimization bayesian-optimisation hyperparameter-optimization hyperparameter-tuning hyperparameter-search configuration algorithm-configuration automl automated-machine-learning random-forest

smac3's Introduction

SMAC3: A Versatile Bayesian Optimization Package for Hyperparameter Optimization

Tests Documentation codecov Status

SMAC offers a robust and flexible framework for Bayesian Optimization to support users in determining well-performing hyperparameter configurations for their (Machine Learning) algorithms, datasets and applications at hand. The main core consists of Bayesian Optimization in combination with an aggressive racing mechanism to efficiently decide which of two configurations performs better.

SMAC3 is written in Python3 and continuously tested with Python 3.8, 3.9, and 3.10. Its Random Forest is written in C++. In further texts, SMAC is representatively mentioned for SMAC3.

Documentation

Roadmap

Important: Changes in v2.0

With the next big major release of SMAC, we drastically boosted the user experience by improving the APIs and how the pipelining is done (see changelog). All facades/intensifiers support multi-objective, multi-fidelity, and multi-threading natively now! That includes having an ask-and-tell interface and continuing a run wherever you left off. pSMAC is removed because when specifying the number of workers, SMAC automatically uses multi-threading for evaluating trials. When cleaning the code base, however, we removed the command-line interface (calling a target function from a script is still supported), and runtime optimization. Also, python 3.7 is not supported anymore. If you depend on those functionalities, please keep using v1.4.

We are excited to introduce the new major release and look forward to developing new features on the new code base. We hope you enjoy this new user experience as much as we do. 🚀

Installation

This instruction is for the installation on a Linux system, for Windows and Mac and further information see the documentation.

Create a new environment with python 3.10 and make sure swig is installed either on your system or inside the environment. We demonstrate the installation via anaconda in the following:

Create and activate environment:

conda create -n SMAC python=3.10
conda activate SMAC

Install swig:

conda install gxx_linux-64 gcc_linux-64 swig

Install SMAC via PyPI:

pip install smac

If you want to contribute to SMAC, use the following steps instead:

git clone https://github.com/automl/SMAC3.git && cd SMAC3
make install-dev

Minimal Example

from ConfigSpace import Configuration, ConfigurationSpace

import numpy as np
from smac import HyperparameterOptimizationFacade, Scenario
from sklearn import datasets
from sklearn.svm import SVC
from sklearn.model_selection import cross_val_score

iris = datasets.load_iris()


def train(config: Configuration, seed: int = 0) -> float:
    classifier = SVC(C=config["C"], random_state=seed)
    scores = cross_val_score(classifier, iris.data, iris.target, cv=5)
    return 1 - np.mean(scores)


configspace = ConfigurationSpace({"C": (0.100, 1000.0)})

# Scenario object specifying the optimization environment
scenario = Scenario(configspace, deterministic=True, n_trials=200)

# Use SMAC to find the best configuration/hyperparameters
smac = HyperparameterOptimizationFacade(scenario, train)
incumbent = smac.optimize()

More examples can be found in the documentation.

Visualization via DeepCAVE

With DeepCAVE (Repo, Paper) you can visualize your SMAC runs. It is a visualization and analysis tool for AutoML (especially for the sub-problem hyperparameter optimization) runs.

License

This program is free software: you can redistribute it and/or modify it under the terms of the 3-clause BSD license (please see the LICENSE file).

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

You should have received a copy of the 3-clause BSD license along with this program (see LICENSE file). If not, see here.

Contacting us

If you have trouble using SMAC, a concrete question or found a bug, please create an issue. This is the easiest way to communicate about these things with us.

For all other inquiries, please write an email to smac[at]ai[dot]uni[dash]hannover[dot]de.

Miscellaneous

SMAC3 is developed by the AutoML Groups of the Universities of Hannover and Freiburg.

If you have found a bug, please report to issues. Moreover, we are appreciating any kind of help. Find our guidelines for contributing to this package here.

If you use SMAC in one of your research projects, please cite our JMLR paper:

@article{JMLR:v23:21-0888,
  author  = {Marius Lindauer and Katharina Eggensperger and Matthias Feurer and André Biedenkapp and Difan Deng and Carolin Benjamins and Tim Ruhkopf and René Sass and Frank Hutter},
  title   = {SMAC3: A Versatile Bayesian Optimization Package for Hyperparameter Optimization},
  journal = {Journal of Machine Learning Research},
  year    = {2022},
  volume  = {23},
  number  = {54},
  pages   = {1--9},
  url     = {http://jmlr.org/papers/v23/21-0888.html}
}

Copyright (C) 2016-2022 AutoML Group.

smac3's People

Contributors

8uurg avatar aaronki avatar aaronkimmig avatar aaronkl avatar anatolfernandez avatar andrebiedenkapp avatar ashraaghav avatar benjamc avatar brenting avatar cyprienc avatar dengdifan avatar dependabot[bot] avatar eddiebergman avatar franchuterivera avatar gsakkis avatar helegraf avatar jeschment avatar keggensperger avatar kolanich avatar meain avatar mfeurer avatar michidk avatar mlindauer avatar phmueller avatar renesass avatar sarah-segel avatar sfalkner avatar shukon avatar stokasto avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

smac3's Issues

KeyError

Originally reported by: Matthias Feurer (Bitbucket: mfeurer, GitHub: mfeurer)


I got this error:

KeyError                                  Traceback (most recent call last)
<ipython-input-10-a9f6024df581> in <module>()
     38 smbo = SMBO(scenario=scenario, rng=1, tae_runner=taf)
     39 Stats.scenario = scenario
---> 40 smbo.run(max_iters=100)
     41 
     42 print("Final Incumbent: %s" % (smbo.incumbent))

/home/feurerm/virtualenvs/ml2016/local/lib/python2.7/site-packages/smac/smbo/smbo.pyc in run(self, max_iters)
    291                 run_history=self.runhistory,
    292                 objective=self.objective,
--> 293                 time_bound=max(0.01, time_spend))
    294 
    295             # TODO: Write run history into database

/home/feurerm/virtualenvs/ml2016/local/lib/python2.7/site-packages/smac/smbo/intensification.pyc in intensify(self, challengers, incumbent, run_history, objective, time_bound)
    226                 chall_inst_seeds = set(map(lambda x: (
    227                     x.instance, x.seed), run_history.get_runs_for_config(challenger)))
--> 228                 chal_perf = objective(challenger, run_history, chall_inst_seeds)
    229                 run_history.update_cost(challenger, chal_perf)
    230 

/home/feurerm/virtualenvs/ml2016/local/lib/python2.7/site-packages/smac/smbo/objective.pyc in average_cost(config, run_history, instance_seed_pairs)
    116     float
    117     """
--> 118     return np.mean(_cost(config, run_history, instance_seed_pairs))
    119 
    120 def sum_cost(config, run_history, instance_seed_pairs=None):

/home/feurerm/virtualenvs/ml2016/local/lib/python2.7/site-packages/smac/smbo/objective.pyc in _cost(config, run_history, instance_seed_pairs)
     93     for i, r in instance_seed_pairs:
     94         k = run_history.RunKey(id_, i, r)
---> 95         costs.append(run_history.data[k].cost)
     96     return costs
     97 

KeyError: RunKey(config_id=36, instance_id='2', seed=931243971)

I'll try to reproduce this.


SMAC calls TA with negative cutoff time

Originally reported by: Marius Lindauer (Bitbucket: mlindauer, GitHub: mlindauer)


I observed the following TA call -- current dev branch:

python -u ./target_algorithms/sat/scripts/SATCSSCWrapper.py --mem-limit 1024 --script ./target_algorithms/sat/spear-python/spearCSSCWrapper.py instances/sat/data/SPEAR-QCP/qcplin2006.58625.cnf 0 -16184172830.8

In this case, spear will never terminate :-/

I would guess that something in adaptive capping is broken...


Dependency on RoBO

Originally reported by: Matthias Feurer (Bitbucket: mfeurer, GitHub: mfeurer)


The main code base does not include any dependency on RoBO any more, but the unit tests do, as well as a commit in the automl branch. Two questions arise:

  • Do we want to keep the dependency on RoBO in:
    • smac.test.test_local_search
    • smac.test.test_smbo
    • test_files/example_branin.py
  • Should [https://bitbucket.org/aadfreiburg/smac3/commits/36706bef6b093c43b82f3d5db2b665e0798e8ade?at=development](this commit) still be merged or can I actually delete the branch automl?

runhistory in choose next

Originally reported by: Aaron Klein (Bitbucket: aaron_klein, GitHub: Unknown)


The choose_next() method in the SMBO class accesses the runhistory, which is initialized in the run() method. However, in some cases (such as labwatch) we only use the choose_next() functionality of SMAC without ever calling the run method. Because of that, we should either avoid accessing the runhistory object in choose_next() or initializing it in the constructor.


choice of next instance not deterministic

I just found the following code snippet in intensification.py. Instead of using the instance of the random number generator, it uses a global instance of random:

if available_insts:
    # Line 5 (here for easier code)
    next_instance = random.choice(list(available_insts))

Output and trajectory files don't match

When running rosenbrock.py I get the output shown below. The output suggests that there are at least 4 incumbents (not even listing the initial incumbent), but the trajectory file only lists three (including the incumbent). Which one is correct?

Default Value: 120048.00
/home/eggenspk/virtualEnvs/virtual3SMAC/lib/python3.4/site-packages/smac-0.1.0-py3.4.egg/smac/smbo/acquisition.py:173: RuntimeWarning: divide by zero encountered in true_divide
INFO:intensifier:Challenger (69492.7391) is better than incumbent (120048.0000) on 1 runs.
INFO:intensifier:Changing incumbent to challenger: Configuration:
  x1, Value: -4.656907303634218
  x2, Value: -3
  x3, Value: 2
  x4, Value: -2

INFO:intensifier:Challenger (677.3422) is better than incumbent (69492.7391) on 1 runs.
INFO:intensifier:Changing incumbent to challenger: Configuration:
  x1, Value: -0.8297799529742598
  x2, Value: 2
  x3, Value: 2
  x4, Value: 3

INFO:intensifier:Updated estimated performance of incumbent on 1 runs: 677.3422
INFO:intensifier:Updated estimated performance of incumbent on 1 runs: 677.3422
INFO:intensifier:Updated estimated performance of incumbent on 1 runs: 677.3422
INFO:intensifier:Challenger (511.8286) is better than incumbent (677.3422) on 1 runs.
INFO:intensifier:Changing incumbent to challenger: Configuration:
  x1, Value: -0.23478815616176085
  x2, Value: 0
  x3, Value: -2
  x4, Value: 5

INFO:intensifier:Challenger (410.7729) is better than incumbent (511.8286) on 1 runs.
INFO:intensifier:Changing incumbent to challenger: Configuration:
  x1, Value: 0.17154408126871612
  x2, Value: 0
  x3, Value: -2
  x4, Value: 4

INFO:intensifier:Updated estimated performance of incumbent on 1 runs: 410.7729
INFO:intensifier:Updated estimated performance of incumbent on 1 runs: 410.7729
INFO:intensifier:Updated estimated performance of incumbent on 1 runs: 410.7729
INFO:intensifier:Updated estimated performance of incumbent on 1 runs: 410.7729
INFO:intensifier:Updated estimated performance of incumbent on 1 runs: 410.7729
INFO:Stats:##########################################################
INFO:Stats:Statistics:
INFO:Stats:#Target algorithm runs: 204
INFO:Stats:Used wallclock time: 7.05 sec
INFO:Stats:Used target algorithm runtime: 0.55 sec
INFO:Stats:##########################################################
Final Incumbent: Configuration:
  x1, Value: 0.17154408126871612
  x2, Value: 0
  x3, Value: -2
  x4, Value: 4

Optimized Value: 410.77

The trajectory file looks like that:

"CPU Time Used","Estimated Training Performance","Wallclock Time","Incumbent ID","Automatic Configurator (CPU) Time","Configuration..."
0.004036, 999999999.000000, 0.012154, 1, 0.008118, x1='5.0', x2='5', x3='5', x4='5'
0.034413, 677.342200, 0.387002, 3, 0.352589, x1='-0.8297799529742598', x2='2', x3='2', x4='3'
0.210829, 410.772936, 2.789726, 5, 2.578898, x1='0.17154408126871612', x2='0', x3='-2', x4='4'

Make runhistory picklable

Does not work right now because the RunKey and RunValue class cannot be accessed on a module level.

Incumbent in Acquisition Function

Originally reported by: Marius Lindauer (Bitbucket: mlindauer, GitHub: mlindauer)


Hi Aaron,

If I understand the code of the acq. module correctly, I would say that the determination of the incumbent (BestObservation) does not consider the multi-instance case.
Since we keep track of the incumbent its performance anyway, we could provide this information directly without any code in the acq module.

What do you think?

Best,
Marius


Feature Request: Detection Mode

Originally reported by: Marius Lindauer (Bitbucket: mlindauer, GitHub: mlindauer)


Feature request by Norbert Manthey (Dresden):

[...]
Danach kam mir die Idee, dass das evtl direkt in
SMAC Sinn machen würde, also hier die Idee:

Wenn ich Riss in SMAC laufen lasse, und es fehlerhafte Konfigurationen
gibt, dann bricht SMAC (wenn ich es so einstelle) ab, sobald er was
findet. Die Konfiguration bekomm ich aus den Logdatein raus, und kann
sie dann (momentan mit einem Python-Skript) minimieren, d.h. die
Anzahl der gesetzten Parameter (heuristisch) minimieren wobei der
Fehler erhalten bleibt. Diese "kleinste" Kombination von Parametern
füge ich der Parameterspezifikation als verbotene
Parameterkonfiguration hinzu, und kann dann normal weiter tunen (oder
mit ROAR Fehler suchen).

Für Werkzeugentwickler wäre so ein Framework sehr hilfreich, vor allem
wenn man so viele Parameter hat wie ich ;)


Performance of initial incumbent

The trajectory (file) always starts with the first evaluated configuration (which is the default) with a cost of 999999999, but it never updates or adds a new entry with the real initial incumbent performance after evaluating it.

Example from rosenbrock.py:

"CPU Time Used","Estimated Training Performance","Wallclock Time","Incumbent ID","Automatic Configurator (CPU) Time","Configuration..."
0.004036, 999999999.000000, 0.012154, 1, 0.008118, x1='5.0', x2='5', x3='5', x4='5'
0.034413, 677.342200, 0.387002, 3, 0.352589, x1='-0.8297799529742598', x2='2', x3='2', x4='3'
0.210829, 410.772936, 2.789726, 5, 2.578898, x1='0.17154408126871612', x2='0', x3='-2', x4='4'

OverflowError: cannot convert float infinity to integer

Traceback (most recent call last):
  File "../../scripts/smac", line 20, in <module>
    smac.main_cli()
  File "/home/lindauer/git/SMAC3/smac/smac_cli.py", line 50, in main_cli
    smbo.stats.print_stats()
  File "/home/lindauer/git/SMAC3/smac/stats/stats.py", line 103, in print_stats
    log_func("#Target algorithm runs: %d / %d" %(self.ta_runs, self.__scenario.ta_run_limit))
OverflowError: cannot convert float infinity to integer

sorry, my mistake. I will fix it.

Replace Rosenbrock 4d by Rosenbrock 2d

Currently, the Rosenbrock 4d function seems to wrong if compared to wikipedia. It should read like:

(100 (x1**2 - x2) + (x1 - 1) **2) + (100 (x3**2 - x4) + (x3 - 1)**2)

Since the Rosenbrock 2d function seems to be more common, I propose to replace the 4d version with the 2d version which reads like:

100. * (x2 - x1 ** 2.) ** 2. + (1 - x1) ** 2.

We can then also easily compare our results to the results on wikipedia.

Scenario class 'in_reader' referenced before assignment

Originally reported by: Saskia Rabald (Bitbucket: saskiara, GitHub: Unknown)


in_reader variable is not assigned when Scenario() is called with a dict instead of a string

Error Message:

#!python

scen = Scenario(scenargs)
File "build/bdist.linux-x86_64/egg/smac/scenario/scenario.py", line 92, in __init__
    self.train_insts = in_reader.read_instance_file(
UnboundLocalError: local variable 'in_reader' referenced before assignment


Add mapping from status type to human readable text

Currently, the status is an integer between 1 and 5. It cannot be easily displayed to the user without explaining it. It would be helpful to add a mapping back to a human readable string, so that I can do:

>>> print(mapping[status])
Memout

In the course of implementing this, we could also start using the Enum class which was added in python3.4.

Intensify: IndexError

Traceback (most recent call last):
  File "/home/feurerm/ihome/projects/2016_epm/scripts/generate_data/adaboost//run.py", line 21, in <module>
    core.run_smac_on_task(cs, task_id, 10, output_directory)
  File "/home/feurerm/ihome/projects/2016_epm/epm/data_gathering/core.py", line 316, in run_smac_on_task
    smbo.run(max_iters=999)
  File "/home/feurerm/virtualenvs/2016_epm/lib/python3.4/site-packages/smac/smbo/smbo.py", line 293, in run
    time_bound=max(0.01, time_spend))
  File "/home/feurerm/virtualenvs/2016_epm/lib/python3.4/site-packages/smac/smbo/intensification.py", line 130, in intensify
    max_runs = inc_inst[0][1]
IndexError: list index out of range

So far no idea, how this happened.

Start from a random configuration

Hi,

for comparing against other systems, it is sometime necessary to start SMAC from a random configuration instead of from a default configuration.

Best,
Marius

Extend PCS format

Hi,

we (i.e., Frank, Holger, Kevin, Thomas, Manuel and I) extensively discussed at the Dagstuhl seminar, that
the new pcs format (see AClib 2.0 format spec or the latest SMAC pcs format) will be the standard in AClib in the near future.
Therefore, I think, it will be also crucial to support it in SMAC3.
Irace does already support it.

Best,
Marius

One run multiple times in runhistory

Originally reported by: Marius Lindauer (Bitbucket: mlindauer, GitHub: mlindauer)


Hi Tobi,

you wrote in the runhistory code:

"TODO JTS: We might have to execute one config multiple times
since the results can be noisy and then we can't simply
overwrite the old config result here!"

Unfortunately, I don't understand the problem.
If you have noisy runs, I would expect that you set a random seed (which is also important for SMAC to know to reduce a degree of variance) and the random seed is part of the runhistory keys.
So, I would say that we already support this feature.

Best,
Marius


SMAC crashes when trying to abort when the first run crashes

In default_configuration_design, if the status of the first run is CRASHED or ABORT, SMAC tries to exit, but crashs itself in the following code:

if status in [StatusType.CRASHED or StatusType.ABORT]:
    self.logger.critical("First run crashed -- Abort")
    sys.exit(1)

Reasons are a missing import of sys and a missing logger.

support_memory_limit not initialized

Traceback (most recent call last):
  File "/home/lindauer/git/SMAC3/scripts/smac", line 20, in <module>
    smac.main_cli()
  File "/home/lindauer/git/SMAC3/smac/smac_cli.py", line 47, in main_cli
    smbo.run(max_iters=args_.max_iterations)
  File "/home/lindauer/git/SMAC3/smac/smbo/smbo.py", line 282, in run
    self.incumbent = self.run_initial_design()
  File "/home/lindauer/git/SMAC3/smac/smbo/smbo.py", line 239, in run_initial_design
    instance_specific=self.scenario.instance_specific.get(rand_inst, "0"))
  File "/home/lindauer/git/SMAC3/smac/tae/execute_ta_run.py", line 103, in start
    if self._supports_memory_limit is True:
AttributeError: 'ExecuteTARunOld' object has no attribute '_supports_memory_limit'

The new feature with memory limit broke the command line target algorithm classes.

The problem is that _supports_memory_limit is not inherited by its children.
The super() is wrongly used.
It should be something like:

        super().__init__(ta=ta,
                         stats=stats,
                         run_obj=run_obj)

We need to fix this asap since the current release cannot be used with the command line interface

Exhausted ConfigSpace

If SMAC3 tried all possible configurations in the ConfigSpace (and the target algorithm is deterministic), but the configuration budget is not yet exhausted (e.g., number of function evaluations), SMAC3 will never terminate.

Having an approximation of the configspace size would help to terminate SMAC, if the configspace is exhausted.

Related to this issue, even if the configuration budget is appropriated, it can be hard for SMAC to sample a new configuration which it has not yet run. The SMAC2 solution for this case is to count the number of calls of intensify without adding a new algorithm run in the runhistory. Do we want to also include this check in SMAC3?

I added the example leadingones.py to reproduce these issues.

Make run_obj a mandatory argument

I think we should make arguments where users can really screw up the setting mandatory. One example is run_obj, which can make the algorithm behave totally wrong for a scenario. By making a few important choices required, we lower the chance of accidental misconfiguration.

Challenger identical with Incumbent

Originally reported by: Marius Lindauer (Bitbucket: mlindauer, GitHub: mlindauer)


We can again sample the incumbent as a challenger. I have observed this in particular in the beginning with the default configuration. We should check why this happens.

Since incumbent and challenger are the same, the intensification method will return that the challenger has changed (to the same incumbent again). This can be very confusing for users.


runcount-limit ignored

The value set for runcount-limit in scenario is ignored. It seems like SMAC checks the runcount value only after each iteration and not after each target algorithm run, therefore SMAC might do more runs than it is supposed to do.

Make a Target Algorithm runner that works directly with python functions

Originally reported by: Tobias Springenberg (Bitbucket: stokasto, GitHub: stokasto)


Currently the Scenario needed to create an SMBO instance directly requires parsed command line arguments and parses a pcs file.
Furthermore the code assumes that the target algorithm will be a file that is executed (and results are shoved through a pipe).

Both of these are often not the case, as a result we had to specialize Scenario in auto-sklearn and in other places.
This is not really user friendly. We probably way to to have a scenario sub-class that can be instantiated solely within python without external files.

What is more important though is that we need a runner that can directly execute python functions.


Define version number, authors etc in __init__

Right now the version number, copyright and authors are defined in both the setup.py and the doc/conf.py. We should keep them only once in the init.py file and use that information in setup.py and doc/conf.py.

Func facade is not a drop-in replacement for current optimization packages

The newly added facade for direct optimization is only partially compatible with common minimization algorithms such as the ones in scipy.minimize, direct, cma-es etc... The two most striking differences I found is the invocation, which should be a function instead of a class, and the second is the signature of the target algorithm. I have worked on a small example on how a function fmin_smac could look like. It is a refactoring of the current FuncSMAC class:

def fmin_smac(func: callable,
              x0: list,
              bounds: list,
              maxfun: int=-1,
              maxtime: int=-1,
              rng: np.random.RandomState=None):
    """Minimize a function func using the SMAC algorithm.

    This method is a convenience wrapper for the SMAC class.

    Parameters
    ----------
    func : callable f(x)
        Function to minimize.
    x0 : list
        Initial guess/default configuration.
    bounds : list
        ``(min, max)`` pairs for each element in ``x``, defining the bound on
        that parameters.
    maxiter : int, optional
        Maximum runtime in seconds.
    maxfun : int, optional
        Maximum number of function evaluations.
    rng : np.random.RandomState, optional
            Random number generator used by SMAC.

    Returns
    -------
    x : list
        Estimated position of the minimum.
    f : float
        Value of `func` at the minimum.
    r : :class:`smac.runhistory.runhistory.RunHistory`
        Information on the SMAC run.
    """

    aggregate_func = average_cost
    # initialize empty runhistory; needed to pass to TA
    runhistory = RunHistory(aggregate_func=aggregate_func)

    # create configuration space
    cs = ConfigurationSpace()
    for idx, (lower_bound, upper_bound) in enumerate(bounds):
        parameter = UniformFloatHyperparameter(name="x%d" % (idx + 1),
                                               lower=lower_bound,
                                               upper=upper_bound,
                                               default=x0[idx])
        cs.add_hyperparameter(parameter)

    # create scenario
    scenario_dict = {"run_obj": "quality",  # we optimize quality
                     "cs": cs,  # configuration space
                     "deterministic": "true",
                     }
    if maxfun > -1:
        scenario_dict["runcount_limit"] = maxfun
    if maxtime > - 1:
        scenario_dict["wallclock_limit"] = maxtime
    scenario = Scenario(scenario_dict)

    smac = SMAC(scenario=scenario, tae_runner=func, rng=rng)
    smac.logger = logging.getLogger("fmin_smac")
    incumbent = smac.optimize()

    config_id = smac.solver.runhistory.config_ids[incumbent]
    run_key = RunKey(config_id, None, 0)
    incumbent_performance = smac.solver.runhistory.data[run_key]
    incumbent = [incumbent['x%d' % (idx + 1)] for idx in range(len(bounds))]
    return incumbent, incumbent_performance.cost, \
           smac.solver.runhistory

When I tried to replace scipy.optimize.fmin_l_bfgs_b with fmin_smac I figured that the target algorithms actually have a quite different signature. While SMAC expects func(dict, seed), scipy.optimize expects func(array-like). To make using the code as easy as possible, I suggest that we also add a target algorithm executer for this case, which does nothing except calling the target algorithm with an array-like and without a seed .

Restructure SMBO

Hi,

I would like to propose the following restructuring. In particular, the smbo class is right now responsible for too much stuff.

  • extra module for initial design
  • a smac-builder class which plugs all stuff together (right now in __init__ of smbo)
  • new entries to the runhistory should be only added in ExecuteTARun.start

btw: we have some methods in the BaseSolver which we never use, e.g., init_last_iteration, from_iteration, save_iteration and create_save_dir. Should we delete these?

Best,
Marius

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.