Improve handling of internal nonlinear_constraints

[gauravmanmode]

• optimagic version used, if any:
• Python version, if any: 3.10
• Operating System: Linux

What would you like to enhance and why? Is it related to an issue/problem?

A user-provided nonlinear constraint a <= g(x) <= b is transformed to h(x) >= 0, where h(x) is
- h(x) = g(x), if a == 0 and b == inf
- h(x) = g(x) - a, if a != 0 and b == inf
- h(x) = (g(x) - a, -g(x) + b) >= 0, if a != 0 and b != inf.

Issue:

For example

om.NonlinearConstraint(
       selector=lambda params: params[2:4],
       func=lambda x: np.prod(x),
       upper_bound=-12,
       
   ),

when only upper_bound is mentioned, it is transformed with _transformation_type = "stack"
the internal representation is
{"type":"ineq", ...
"n_constr" : 2} and lower_bound is implicity set to zero.

Describe the solution you'd like

Improve this by handling the -inf case,
Then a <= g(x) <= b is transformed to h(x) >= 0 where h(x) is
- h(x) = g(x), if a == -inf and b == inf
- h(x) = g(x) - a, if a != 0 and b == inf
- h(x) = -g(x) + b, if a == -inf and b != inf
- h(x) = (g(x) - a, -g(x) + b) >= 0, if a != -inf and b != inf.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've
considered and why you have discarded them.

[janosg]

Hi @gauravmanmode, thanks for creating the issue. This is indeed a problem we need to fix.

[gauravmanmode]

After handling the -inf case ,

om.NonlinearConstraint(
       selector=lambda params: params[2:4],
       func=lambda x: np.prod(x),
       upper_bound=-12,
   ),

now implicity sets lower_bound = -np.inf .
in test_with_nonlinear_constraints.py,
test_general_example[ipopt-True] is failing with

E       AssertionError: 
E       Arrays are not almost equal to 4 decimals
E       
E       Mismatched elements: 2 / 4 (50%)
E       Max absolute difference among violations: 0.11270167
E       Max relative difference among violations: 1.
E        ACTUAL: array([ 9.9997e-01, -1.8781e-13, -1.8781e-13,  2.7872e-05])
E        DESIRED: array([0.8873, 0.1127, 0.    , 0.    ])

[janosg]

@timmens will have to look into the failure when he is back next week.

We can use this as a chance to simplify the test and make them more self contained. The fixtures are too complicated to understand what is going on.

[timmens]

@gauravmanmode thanks for raising the issue, you are totally right, we have a missing case here!

Those are some good ideas. We want to improve and redesign the constraint handling for the linear and non-linear case in the very near future anyways. Once I start working on this I will let you know here!