Ticket #129 (closed task: fixed)
allow calling Solve() multiple times on same solver
Reported by: | altafang | Owned by: | mmckerns |
---|---|---|---|
Priority: | major | Milestone: | mystic-0.2a2 |
Component: | mystic.solvers | Keywords: | |
Cc: |
Description
I think it would be good to either create a clear_results() method for solvers or write a warning in the documentation for users not to call Solve() on the same solver instance multiple times, since it may be easy for users to forget to create a new solver object when running a new optimization. I sometimes make the mistake of creating a solver object, setting up initial conditions, bounds constraints, etc., running solver.Solve() on one cost function, getting the answer, and then running solver.Solve() again on another cost function, thus avoiding setting up the solver again. However, for solvers like the differential evolution solvers, attributes such as bestEnergy and population are stored and re-used, giving incorrect results if you call Solve() twice like that. Thus, even if you want to run an optimization with the same solver, same initial conditions, etc., you have to create a new solver and re-initialize it if you want the right answer. This is difficult for users to debug, too, since no error is thrown, and it looks like the results are legitimate when you call Solve() twice.
Change History
comment:2 Changed 6 years ago by mmckerns
- Summary changed from Calling Solve() multiple times on same solver to allow calling Solve() multiple times on same solver
comment:3 Changed 6 years ago by mmckerns
this brings about an even better design opportunity...
1) changing some set-up condition, or the cost function, or whatever, and then running solver.Solve again could be desired behavior if you want to start from the endpoint of the previous call to the solver. This could be very useful in addressing tricky problems, or building strategies that automatically switch between methods or solver conditions.
2) calling solver.Solve a second time "clears" out the last run, and resets the solver to the initial state (i.e. post-configuration, but pre-run). This seems to be in conflict with the above point, which is more powerful. So maybe a solver.Reset() method could handle this.