Giters

astamm / nloptr

nloptr provides an R interface to NLopt, a free/open-source library for nonlinear optimization providing a common interface to a number of different optimization routines which can handle nonlinear constraints and lower and upper bounds for the controls.

Home Page:https://astamm.github.io/nloptr/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Inequality direction in wrapper functions

hwborchers opened this issue · comments

commented

I am a contributor to the {nloptr} package. I contributed the small 'wrapper' functions --like 'lbfgs', 'auglag', or 'slsqp', etc. - that hopefully made it easier for casual users of the package to call basic routines without the need to understand the API of the main function 'nloptr()'.

I have a concern or request:

For instance, in the 'slsqp' function I interpreted the inequality constraints as hin(x) >= 0 while Jelmer Ypma thought hin(x) <= 0 would be more appropriate in the context of the package. Therefore, he added a message

"For consistency with the rest of the package the inequality sign
 may be switched from >= to <= in a future nloptr version."

This is correct but becomes confusing or annoying when calling this function one or several times. Can we change this behavior, either by removing the message or by reversing the inequality sign?

Reversing the sign will, of course, change the function behavior and will probably lead to "dependency problems". I have just gone through this process, see https://stat.ethz.ch/pipermail/r-help/2023-November/478539.html, and unfortunately, the added message is not an official "deprecated" warning.

I don't mind if you prefer to leave things as they are. In this case, to not confuse the users too much it would be appropriate to remove the message. (I have not checked whether similar messages appear in other wrappers.) Perhaps the direction of the inequality constraint could be emphasized more clearly on the corresponding help pages.

Hans Werner

commented

Hello, @hwborchers. In theory, I would like $\leq$ to be the default for consistency with the rest of the basic definitions, but I would suggest that if we follow that approach it should be a three-step process with suitable time (at least months) between steps:

  1. Deprecate it now whilst building in an "old behavior" option which is the default. If we follow Semantic Versioning we would bump the MINOR version (added functionality but no API change).
  2. Switch the default option to the NEW behavior. If we follow Semantic Versioning we would bump the MAJOR version (breaking API change).
  3. Defunct the old behavior. If we follow Semantic Versioning we would bump the MINOR version (added functionality but no API change).

In the interim, perhaps the simplest thing is to update the help to reference SuppressMessages for those who find it annoying?

commented

I am going to work on this in the devel branch of my fork.

commented

I agree with @aadler. In the long run, we should implement all inequality constraints with the same $\le$ sign. And, yes, we should clarify the help in the meantime and implement a deprecation strategy.

@aadler how far did you manage to go on your fork on this issue?

For the deprecation process, we could implement that with lifecycle.

commented

As I am planning a release to CRAN next week, we also need to decide if step 1 of the deprecation process should appear in this release.

commented

Should be fixed in #157 thanks to @aadler .