Skip to content

Conversation

astamm
Copy link

@astamm astamm commented May 22, 2025

A proposed solution to bug 17703 from group effort with @tdhock @leopoldguyot @ElsLommelen.

obj <- f(theta, ...)
if (s.mu * obj > s.mu * obj.old) break
}
if (optim_failure) {
a$convergence <- 21 # See https://github.com/nashjc/optimx/blob/main/man/optimx.Rd
a$message <- gettextf("Returning solution from outer iteration %d, either because the solution is not in the feasible region or `optim()` provided non-finite outputs. Consider either checking the gradient implementation or using a derivative-free opimizer or reducing `outer.eps`.", i)
Copy link

Choose a reason for hiding this comment

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

I would suggest removing the backticks


a <- optim(theta.old, fun, gradient, control = control,
method = method, hessian = hessian, ...)
r <- a$value
if (is.finite(r) && is.finite(r.old) &&
abs(r - r.old) < (1e-3 + abs(r)) * outer.eps) break
theta <- a$par
totCounts <- totCounts + a$counts

if (any(ui%*%theta-ci<0) || !is.finite(r) || any(!is.finite(theta))) {
Copy link

Choose a reason for hiding this comment

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

please use consistent indentation

Choose a reason for hiding this comment

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

This is strange, the indentation looks fine in local...

image

Copy link
Collaborator

Choose a reason for hiding this comment

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

this could be due to the R sources' inconsistent use of tabs and spaces. Be sure to enable visible whitespace in your editor to help clarify. Generally, I recommend using non-invasive IDEs to work on the R sources to minimize diffs (I typically just use nano, for example, though emacs is also widely used and does better at respecting nearby whitespace choices).

Choose a reason for hiding this comment

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

That was indeed the issue, thank you for your help! I thought neovim would also respect nearby whitespace choices, but apparently it does not :/

@nashjc
Copy link

nashjc commented May 23, 2025

I think the use of code "21" is heroic. In the .Rd file for optimr I have

"Various methods may or may not return sufficient information to allow all the codes to be specified."

In fact, while I use the codes if produced by the solvers, the majority don't return most of them. That's probably a great topic for a GSoC or similar project, but getting the codes into the solvers would be a pretty massive job, and need injection of code in all sorts of programming languages and interaction with other projects.

In particular, I think only my own Rvmmin or its update to nvm will give the 21 code. They could be used when there is a gradient function available. In fact, they'll complain and stop if one is not provided. This would mean changing "BFGS" to "nvm" in the "method = " line for a gradient method. This should be an easy change, but I'm sure there'll be some glitches.

Unfortunately .... the results won't quite match BFGS so you may get revdep hell in commit to CRAN.

@leopoldguyot
Copy link

I added tests, I tried to find the right initial parameters to reproduce the bug (that would now return a convergence code 21).
But it seems like that the reproducibility is also OS/machine dependent. Should I remove the tests?

@nashjc
Copy link

nashjc commented May 23, 2025 via email

@leopoldguyot
Copy link

I posted a comment. The 21 code likely only comes from my Rvmmin and nvm. JN

On 2025-05-23 13:29, Léopold Guyot wrote: leopoldguyot left a comment (r-devel/r-svn#202) <#202 (comment)> I added tests, I tried to find the right initial parameters to reproduce the bug (that would now return a convergence code 21). But it seems like that the reproducibility is also OS/machine dependent. Should I remove the tests? — Reply to this email directly, view it on GitHub <#202 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ AA247LDWQDA7IKU2VAAUSIL275LHBAVCNFSM6AAAAAB5WGVAUWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMBVGIZTKNJZGY>. You are receiving this because you commented.Message ID: @.***>

What would you suggest? Should we return a convergence code of 0 (already returned by optim) or should we create a new code and define it in the documentation?

Thank you for your help :)

@nashjc
Copy link

nashjc commented May 26, 2025 via email

@nashjc
Copy link

nashjc commented May 26, 2025

Sorry: should point to optimx package inst/doc/optcontrol.xls Extra characters in post above.

@nashjc
Copy link

nashjc commented May 26, 2025

FWIW, the attached try doesn't croak, but I've not checked if results are sane.

JN
bug17703xJN.zip

@nashjc
Copy link

nashjc commented May 26, 2025

If it turns out that the use of nvm rather than BFGS is "interesting", I'm willing to work with others to get nvm code directly into constrOptim, since that function is in stats library and not a package. It is about 4* as long a code as constrOptim, so tail wagging the dog.

@tdhock
Copy link

tdhock commented May 27, 2025

Hi John thanks for the idea about nvm, but let's leave that for a separate issue/discussion.
As a next step here, I would suggest sending the patch (perhaps without the test because it seems to be failing) in an email to R-devel. @leopoldguyot can you please write an email with a brief summary of the problem and our proposed solution?

@nashjc
Copy link

nashjc commented May 27, 2025

It may also be feasible to create a function, say "cograd()" that wraps the gradient function of the user and tests for extreme values. That would not be a huge amount of code and could be a sensible workaround. The tricky part might be to pass back the failure information to BFGS and escape.

@leopoldguyot
Copy link

Hi John thanks for the idea about nvm, but let's leave that for a separate issue/discussion. As a next step here, I would suggest sending the patch (perhaps without the test because it seems to be failing) in an email to R-devel. @leopoldguyot can you please write an email with a brief summary of the problem and our proposed solution?

Sure but I will not be able to do it before friday 😅

@hturner
Copy link
Member

hturner commented Aug 20, 2025

@leopoldguyot can you make the report back to Bug 17703 to summarise your work here and what you think the next steps should/could be?

@leopoldguyot
Copy link

Hello, sorry everyone for the long wait, it completely slipped my mind. I've submitted the patch.

@tdhock
Copy link

tdhock commented Sep 5, 2025

looks great thanks!

@astamm
Copy link
Author

astamm commented Sep 6, 2025

Nice ! Thanks @leopoldguyot !

@nashjc
Copy link

nashjc commented Sep 6, 2025

Fixes like this are important to keep the R environment working.
As I've commented before, it should be possible to prepare a more general "safeguarded gradient" function that wraps gradient routines, whether direct evaluations or numerical approximations, both of which can fail in some domains of the parameters. I'm willing to work on this, but to do a good job I need collaborators who can provide user perspective. There is a very mixed bag of optimization and differential equation packages that could benefit, and getting a broad applicability is a challenge, but one that could help users either avoid issues or be notified of them quickly. The central code is probably pretty small. It's working out how to communicate "we have an issue" to calling routines that could be tricky. If interested, contact off-line profjcnash at gmail.com.

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.

6 participants