Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap for a more user- and developer-friendly SMAC #859

Closed
renesass opened this issue Jun 29, 2022 · 6 comments
Closed

Roadmap for a more user- and developer-friendly SMAC #859

renesass opened this issue Jun 29, 2022 · 6 comments

Comments

@renesass
Copy link
Collaborator

renesass commented Jun 29, 2022

Since the overall goal is to make SMAC more user- and developer-friendly, I spend some time on how we could improve SMAC in small steps.

  1. Convert Scenario into a dataclass
    → Fix multiple names/variables with the same meaning
    → Remove scenario from the main code (scenario was written for CLI mainly)
    → Eventually rename scenario to config (defining objectives, determinstic behaviour, limitations, how many runs should be executed, etc.)
  2. Pull-out CLI completely and write a wrapper for CLI exclusively
  3. Push transparency
    → FirstRunCrashedException (What happened? e.g. see line SMBO Line 504)
    → Better Pynisher integration (having much better tracebacks for example)
  4. Remove *_kwargs and passing an instantiated model directly (overwrite args directly if needed)
    → Essentially, each facade needs to have a static method for default model/intensifier/... which is called if no model/intensifier/... is passed
    → But since the user can grab this "default" intensifier, the user can change it with default settings to their needs
  5. Renaming classes to make them more obvious
    • roar_facade/hyperband_facade → RandomSearchOptimization
    • smac_hpo_facade → HyperparameterOptimization
    • smac_mf_facade → MultiFidelityOptimization
    • smac_bb_facade → BlackBoxOptimization
    • smac_ac_facade → AlgorithmConfigurationOptimization
    • EPMChooser → ?

Let me know what you think about it. :)

@eddiebergman
Copy link
Contributor

→ But since the user can grab this "default" intensifier, the user can change it with default settings to their needs

class BananaFacade:
    
    def __init__(self, epm: EPM | None = None):
        if epm is None:
           epm = self.default_epm()
           
        self.epm = epm

    @staticmethod
    def default_epm(**kwargs) -> EPM:
        """We could explicitly list the args here for better tool support"""
        config = {"a": "apple", "b": "banana", **kwargs}
        return EPM(**config)
        
# All defaults
mybanana = BananaFacade()

# Specify a modified EPM
mybanana = BananaFacade(
    epm=BananaFacade.default_epm(b="bapple"),
)

# Construct an epm entirely and use that
epm = EPM(a="anaconda", b="burger")
mybanana = BananaFacade(epm=epm)

# Specify your own EPM
class OtherEPM(EPM): ...

mybanana = BananaFacade(epm=OtherEPM(...))

@renesass
Copy link
Collaborator Author

Remove runtime optimization?

@renesass
Copy link
Collaborator Author

Add ask + tell interface

@dengdifan
Copy link
Contributor

Add ask + tell interface

And rename EPMChooser

@renesass renesass mentioned this issue Jun 30, 2022
2 tasks
@renesass
Copy link
Collaborator Author

Please see #860, #861, #862, #863, #864 for detailed info.

@helegraf
Copy link
Contributor

This has been addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

No branches or pull requests

4 participants