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

Back away from inequality constraints that evaluate to NaN #38

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

jpritikin
Copy link
Contributor

This permits slsqp to deal with the interaction between inequality constraints and soft feasibility constraints.

@jpritikin
Copy link
Contributor Author

Oops, this change is not passing all of my tests yet.

@jpritikin
Copy link
Contributor Author

Actually these changes are good. The problem I was having was caused by use of ftol instead of xtol on a constrained problem.

@jpritikin
Copy link
Contributor Author

How does this look?

@jpritikin
Copy link
Contributor Author

Hm, do I need to save/restore slsqpb_state if I pick a point from the line search that is not the last point?

@jpritikin jpritikin force-pushed the master branch 2 times, most recently from f232260 to 229e1ff Compare May 10, 2015 11:24
@stevengj
Copy link
Owner

@jpritikin, regarding the SAVE/RESTORE_STATE: if I remember correctly, the original Fortran code was using the equivalent of static C local variables for these things, and I wanted it to be re-entrant & thread-safe. So, the state only needs saving inside the slsqpb_, and should be saved at every exit point from that function (unless you will never come back, e.g. you are exiting because you have converged or there was an error).

@stevengj
Copy link
Owner

Could you squash these (via git rebase --interactive followed by a git push -f) into a single commit? Also be sure to put (for #30) in the commit message so that #30 will be cross-referenced.

@jpritikin
Copy link
Contributor Author

regarding the SAVE/RESTORE_STATE

This question was addressed with jpritikin@356bd27

@stevengj
Copy link
Owner

Should the s[i__] = x[i__] - x0[i__]; loop be executed every time we goto L260, or only from the beginning of the slsqpb_ function? Maybe you should move it before the relevant goto.

+ Preserve starting value if no evaluations were finite

+ Separately track the best minor and major estimate. This change
  ensures that we always move to the best point found during the line
  search even when the best point is not the last point. We also avoid 1
  fit and gradient evaluation by moving the major iteration convergence
  check above the switch statement.

+ Treat failure to find a search direction as convergence

+ Only update minor during line search

+ Unconfuse code that returns the converged details

+ Rename 'x' to 'theSpot'. I loath single letter variable names. X marks
  the spot.
@jpritikin
Copy link
Contributor Author

Should the s[i__] = x[i__] - x0[i__]; loop be executed every time we goto L260, or only from the beginning of the slsqpb_ function?

Sorry, I can't remember. Certainly the code doesn't hurt. It helps preserve an invariant condition that should be preserved.

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.

2 participants