ScalarLinearFunction and redundancy with scalar constraints

[joaquimg]

We have the following table in the manual:

Linear constraints

Mathematical Constraint	MOI Function	MOI Set
a^Tx \le u	ScalarAffineFunction	LessThan
a^Tx \ge l	ScalarAffineFunction	GreaterThan
a^Tx = b	ScalarAffineFunction	EqualTo
l \le a^Tx \le u	ScalarAffineFunction	Interval
...	...	...

In the first four lines we use a^Tx in the first column and we say ScalarAffineFunction, should we say/use ScalarLinearFunction? This could avoid multiple representations of the same constraint. Since a^Tx - b = 0 is equivalent to a^Tx = b

[mlubin]

@joaquimg, that would require introducing a new category of function. We can't get rid of ScalarAffineFunction because it's needed for conic constraints. And then we'd have the question of if solvers should support both ScalarAffineFunction and ScalarLinearFunction in LessThan or just ScalarLinearFunction in LessThan.
I'm okay with the potential for redundancy here.

[mlubin]

Well, to be more precise, VectorAffineFunction is needed for conic constraints. It seems a bit inconsistent though to have ScalarLinearFunction and VectorAffineFunction.

[mlubin]

ScalarAffineFunction is useful for handling constants in the objective function

[joaquimg]

Sure, I don´t think we should get rid of ScalarAffineFunction. However, since scalar constraints have their own sets (Interval, LessThan ...) they could have their own function and we disallow ScalarAffineFunction only for them...

[mlubin]

What's the difference between introducing ScalarLinearFunction and letting solvers choose to reject ScalarAffineFunctions when the constant is not zero?

[joaquimg]

Querying and modifying these scalar constraints might be a bit "degenerate" and would add more complexity on the solver api side...

[joaquimg]

I am fine with rejecting ScalarAffineFunction when the constant is not zero

[mlubin]

It doesn't bother me if solvers choose to not support this case.

[joaquimg]

But you think that would be solver dependent?

[IssamT]

A minor related issue:

For some reason, we have

modifyconstraint!(m::AbstractSolverInstance, c::ConstraintReference, change::AbstractFunctionModification)

But we don't have

modifyconstraint!(m::AbstractSolverInstance, c::ConstraintReference, change::AbstractSetModification)

So if the solver wants to have a specific behavior if only the right hand side (the constant) of a linear constraint has been modified, it is now only possible if the constant is encoded in the ScalaAffineFunction and not in the LessThan / GreaterThan set.

[mlubin]

@IssamT there's no AbstractSetModification because all of the existing sets are very lightweight and have little data. You're allowed to replace the set entirely (with another set of the same type).

[mlubin]

@IssamT if you encode your constraint in the form Ax + b \in nonnegative then you can modify the constant part of the function to achieve changing the right-hand side.

[mlubin]

@joaquimg, I see MOI as a marketplace for solvers and users to come together and agree on how to encode the problem. MOI is very general and I expect that we'll converge to practical conventions like not supporting constant terms combined with LessThan, GreaterThan, and EqualTo.

[IssamT]

there's no AbstractSetModification because all of the existing sets are very lightweight and have little data. You're allowed to replace the set entirely (with another set of the same type).

But it means that the solver needs to check if the set was of the same type before the modification (GreaterThan before and after) to discover that it was only a constant change.

[mlubin]

@IssamT, a set can only be replaced with another of the same type.