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

Consider improving the parameter configuration interface #11

Closed
ili3p opened this issue May 23, 2016 · 2 comments
Closed

Consider improving the parameter configuration interface #11

ili3p opened this issue May 23, 2016 · 2 comments

Comments

@ili3p
Copy link

ili3p commented May 23, 2016

Currently the parameter configuration is being set in this way:

        self.xlow = -15 * np.ones(dim)
        self.xup = 20 * np.ones(dim)
        self.integer = []
        self.continuous = np.arange(0, dim)

This is very cumbersome interface, especially when you have 15 parameters, each with different ranges, and are of different type. It's very easy to make a mistake.
Further if the type of parameter is left unassigned, there is no error or warning. Example

      self.integer = [0, 1, 2]
      self.continuous = [4, 5]

Here the fourth parameter is left without a type (integer or continuous), but there is no error or warning produced, and the algorithm just considers it as continuous.

Also, it would be useful if we can assign a name to a parameter.

I suggest to adopt some JSON configuration file, similar to what other optimization algorithms use. Example:

       {
           parameters:[
                      {
                          name: "learning_rate",
                          low: 10,
                          high: 20,
                          type: "Integer"
                      },
                     ...
           ]
       }

Most importantly produce an error or at least a warning if not all of the configuration properties are set.

Thanks

@dme65
Copy link
Owner

dme65 commented Jun 13, 2016

There is a method for sanity checking your optomization problem setup. The method is named validate and is available in test_problems.py. I agree that this should be checked automatically by the strategy and I'm working on adding some input checking to the strategies.

@dme65
Copy link
Owner

dme65 commented Jun 18, 2016

The optimization problem is sanity checked automatically in 0.1.20

@dme65 dme65 closed this as completed Jun 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants