Skip to content

Nonmonotone variant of linesearch methods #96

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

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

Conversation

aldma
Copy link
Collaborator

@aldma aldma commented May 16, 2025

This PR adds the possibility to run algorithms with a linesearch procedure in a nonmonotone variant. In particular,

  • this feature addresses algorithms such as PANOC, PANOCplus, ZeroFPR and DRLS;
  • a kwarg monotonicity is added to control the level of monotonicity required, with 0 < monotonicity <= 1;
  • the default monotonicity = 1 coincides with the current implementation (monotone descent);
  • a scalar value merit is included in the state, monitoring progress instead of objective or envelope values.

@aldma aldma requested a review from lostella May 18, 2025 05:54
@lostella
Copy link
Member

@aldma thanks, I should be able to review this over the weekend.

I’m wondering about the test failures: the test dependency on AbstractOperators we could remove; regarding RecursiveArrayTools, not sure, I’ll need to look into it.

Copy link
Member

@lostella lostella left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rebasing should get rid of the failing tests!

Comment on lines 195 to 199
# retrieve merit and set threshold
FBE_x = state.merit
sigma = iter.beta * (0.5 / state.gamma) * (1 - iter.alpha)
tol = 10 * eps(R) * (1 + abs(FBE_x))
threshold = FBE_x - sigma * norm(state.res)^2 + tol
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do the assignment FBE_x = state.merit here? It seems to be giving an inappropriate name to this quantity. Should you not directly use state.merit where needed in the lines that follow?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also wondering whether merit is a good name here: this quantity appears to be an exponential moving average of the values of the merit function we're minimizing, is that correct?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, I just wanted to minimize the changes relative to the monotone version. The assignment FBE_x = state.merit has been removed now with dbdd5c1, where possible.
In ZeroFPR and PANOCplus I left an assignment to FBE_x before the loop because the tests where failing otherwise; I did not understand why the variable FBE_x was not available at the final update of state.merit.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, and the value of merit is the one considered as baseline for accepting or rejecting an update in the linesearch. Also the objective function and the envelope are used as merit functions, but they can decrease nonmonotonically, whereas what is called merit decreases monotonically also in the nonmonotone variant.
I am happy to change nomenclature if you have a more appropriate one.

@aldma
Copy link
Collaborator Author

aldma commented May 25, 2025

I hope I didn't mess things up with the rebasing. I am still learning gitology.

@aldma aldma force-pushed the nonmonotone-feat branch from dbdd5c1 to ab5b058 Compare May 26, 2025 06:14
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