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

Attempt at a new API #17

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

kimt33
Copy link

@kimt33 kimt33 commented Apr 10, 2018

So this is the structure that I thought we were talking about.

  1. optimization algorithm solves the subproblem, update the trust region and model, and update x (if condition is satisfied)
  2. subproblem consists of algorithms finds the step that gives the minima within the given trust region and model.
  3. model contains methods that are used to solve the subproblem (inv_hessian_dot and hessian_dot), updating the model, as well as storing information related to the model (e.g. values at each iteration)
  4. trust region contains the methods for updating the trust region and for checking if the given step is a good step. It can also store information related to the trust region (e.g. trust radii at each iteration)

Couple things to highlight:

  1. I'm not sure if line search should go into the subproblem or the trust region module
  2. I'm not sure where to put the steps associated with each quasi-newton methods. For me, the steps are computed by the subproblem algorithm and I'm not sure where the step would be used within the subproblem. Maybe each step will move to its own subproblem.
  3. There is no point class, but all information regarding the model is stored within Model and trust region is stored within TrustRegion. I didn't put in any structure for what will/needs to be stored, but hopefully, this is general enough to support @tczorro 's code. This amounts to moving the parts of the Point class associated with Model and TrustRegion to the corresponding class. The trust region data is assumed to always be independent of the model data. I'm not sure how well this plays with @tczorro 's OptLoop.
  4. Subproblems can be structured as a class or as functions. Doesn't really matter I think. Functions are cleaner and classes show relationships between different subproblems.

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

Successfully merging this pull request may close these issues.

1 participant