Single-parameter linear constraints

[AdrianSosic]

We might consider forbidding the creation of single-parameter linear constraints since the same logic can be activated by placing appropriate parameter bounds. Going via constraints could have negative effects for the optimizer?

[AVHopp]

I'm against this since interpoint constraints make the most sense with a single parameter: "For my batch, I can in total only use 100ml of this substance". If we keep the design of interpoint constraints as they currently are (that is, by having a field is_interpoint), then we should at least allow single-point interpoint constraints. If we want to re-design interpoint, we can still do that (currently waiting for #448 as I still need to test the interplay between interpoint and cardinality constraints)

[Scienfitz]

Sounds reasonable for normal use cases of parameters/cosntraints being fully controlled by suers.

But how about other situations like ones that can happen eg in cardinality context: In situations like described in #448 it might happen that a single parameter constraint is created by the parameter dropping and not the user. The solution to adjust bounds would require a subtantially more complicated logic than just using the single param constraint I guess?

[AdrianSosic]

@AVHopp: yes, interpoint excluded from what I said 👍🏼

@Scienfitz: Agree. Whatever we do, the outcome should be "we are certain that the optimizer is not constrained in unnecessary ways". And there are three ways to achieve this – which is the right one remains to be figured out:

1. Perhaps no adjustment is needed at all, if things are already properly passed down to the numerical routines even in the current state.
2. If not, we might still keep the single-parameter constraint interface for convenience but make sure that we pass it on in the right way to the consuming internal code
3. Or, the approach you mentioned, where single-parameter constraints really need to be turned into adjusted parameters on the fly.

Let's see what we figure out.

[Scienfitz]

ok but we can exclude 1), right? Currently a single parameter constraint would be passed as part of the constraints and not as apprropriate bounds. So the treatment is not optimal and needs to change.

how would 2) and 3) even differ? Reads same to me

What I meant is:

• forbid single parameter linear constraints with the appropriate instructive error
• internal methods that drop parameters need to distinguish the cases whether 1 or more parameters are left over after dropping. This is currently not done. This could be added on searchspace _drop_parameters level as it would allow adjusting the parameter list with the required updated parameter.

I don't see it easily possible that constraints can automatically turn on the needed machinery in a self-contained way as it needs adjusting the searchspace, a concept only available outside of of the constraint class.