@NLconstraint(model, x^1.852 <= 1) not infeasible over |R

[freemin7]

      Status `/tmp/Project.toml`
  [bb8be931] EAGO v0.7.1
  [2e9cd046] Gurobi v0.11.3
  [4076af6c] JuMP v1.1.1

Offending code:

 model = Model(EAGO.Optimizer)
 @variable(model, x)
 @NLconstraint(model, x^1.852 <= 1)
 optimize!(model)

There is nothing surprising about it failing to find a solution numerically. However that a global optimizer reports a wrong result (Infeasible) is surprising and concerning.

There is a solution, although even Mathematica has to rely on a symbolic approach.

[RXGottlieb]

Hi @freemin7. EAGO is a deterministic global optimizer and uses the branch and bound algorithm, so one of the requirements is that x has a compact set as a domain. If x is unbounded, any attempt to branch on its domain will result in NaNs, which are treated as infeasible. If we bound x, EAGO correctly returns a feasible point:

model = Model(EAGO.Optimizer)
@variable(model, -1e20 <= x <= 1e20)
@NLconstraint(model, x^1.852 <= 1)
optimize!(model)

which returns:

Absolute Tolerance Achieved
First Solution Found at Node 5
LBD = 0.0
UBD = 1.0e-5
Solution is :
    X[1] = 0.8417351940480968

[freemin7]

I do not agree with the assessment that branch and bound is only well defined over closed and bounded sets. In addition the extended real number line which Floating Point numbers represent is a compact set. (Yes this would require a limit operation.) However those are unrelated to the underlying issue.

I accept that it is your decision to only support compact intervals whose boundaries are real numbers as restriction on variables.

Can something be done to give the user a better error message so the fix for this user error is obvious to other users in futures?
Would be interested to a pull request with that effect?

How would you feel about the use of nextfloat and prevfloat to tighten lower or upper interval boundaries should the current interval boundary be infeasible?

[RXGottlieb]

Fair points, although I am not aware of a well defined branching rule when the interval bounds contain +/- Inf.

Regarding the use of nextfloat/prevfloat and large real numbers in general, further testing brought up some numerical issues in cases where there are bounds of large magnitude (>1e20), which deserves a closer look. Until those issues can be identified and resolved, I would caution against using bounds with magnitudes much greater than that.

Adding in a warning seems reasonable. I'll add that in shortly, and I'll keep this issue open for addressing high-magnitude bound problems.