Add optimization algorithms from GFO

[SimonBlanke]

[fkiraly]

so, going back to the hyperactive.opt.gfo folder structure? Fine with me

[SimonBlanke]

so, going back to the hyperactive.opt.gfo folder structure?

This is an "intermediate" commit for testing stuff out and to see it in practice. The fact, that we provide the opt. algos on the "opt"-directory level (in the init-file of the opt-directory) changes the situation a bit: https://github.com/SimonBlanke/Hyperactive/pull/121/files#diff-20f5f20be4fd0ec4ef23abe4e98a58ce61db42894ea1b94499d66e9687f3c6bf

Because now it is less about the user-experience (since all opt. algos can be imported from the same path anyway) and more about how the code should be structured in the backend.

[fkiraly]

ok, fine with me either way! (let's just ensure it stays consistent)

[fkiraly]

There are three types of failures in this:

1. broken docstrings - I think you changed the imports of the hill climbing optimizers, so you should also change them in the docstrings and elsewhere.
2. For some optimizers, it seems that check_numpy_array(search_space) is being run, and list is not allowed.
3. other failures which look genuine, there is only a small number of these.

[fkiraly]

Hope it is fine to directly commit to this branch - please revert if not and let me know.

• I have moved the default handling from the top level base class to _BaseGFOadapter - we only know the defaults are correct for gfo instances.
• I also added a to_dict_np method that handles the numpy coercion of the search dict for now.

Please let me know of any feedback.

[fkiraly]

Looks like this fixed it. There are 8 left which look deeper, i.e., in gfo.

[fkiraly]

(change made by me are from pair programming remotely)