Open tmigot opened 3 months ago
If a solver tries to solve an unconstrained problem and, in doing so, evaluates the constraints, there is a serious issue with that solver. We should not encourage that kind of behavior. I think cons!()
should return an error in that case.
For objcons
, the solution I see is easy: we should have objcons
<=> obj
for unconstrained problems.
I agree with the first point, let's add a new error for unconstrained problem when we call the constraints, and error for linear and nonlinear constraints too.
I have a more mixed opinion on the objcons
. Shouldn't this return an error too? Because it is obj and cons, in my mind this function is just trying to optimize both call depening on the models but essentially it is "similar" to call both functions. What I am trying to say if that it feels misleading to call objcons
and irgnoring cons
.
If we keep the version ignoring cons, then we need to update the docstring that right now says:
Evaluate ``f(x)`` and ``c(x)`` at `x`.
Yes I think objcons
should also error if the problem is unconstrained.
This is a corner case, where we should probably on the behavior.
We have several ways to access the constraints function:
cons!/cons
,cons_nln
andcons_lin
, andobjcons
. How should these behave when applied on an unconstrained problems? I see 3 options:A related question is: How should objcons react to this situation?
Connected to https://github.com/JuliaSmoothOptimizers/NLPModelsTest.jl/issues/26 and https://github.com/JuliaSmoothOptimizers/CUTEst.jl/pull/327