Math formulation

[ahoarau]

Right now tasks are written as || E + f || , and each task can compute it's own quadratic cost (Hessian and gradient).
All task's costs are summed (+) in the Problem to build the global objective.

@iadev you were thinking of another way of writing the math ?

[iadev]

This formulation is fine, but maybe we can make it otherwise.

Another way to put it is IMHO to take linear constraints, i.e. E.x = f, as the "base" construction object for both tasks and constraints (ignoring the case of inequality constraints for this discussion).
Then an objective can be associated to this constraint, e.g. || E.x - f ||^2.
The advantage is twofold:

• we do not have confusing "minus" signs everywhere;
• we can easily transform any constraint into a task (might be useful for control purposes).

Actually we might have something like functions, constraints on functions, and metrics on constraints:

• [Function, y := foo(x)] <-- [Linear function, y := E.x]
• [Ineq constraint, c := y - f < 0] , [Equality constraint, c := y - f = 0]
• [Square eq constraint norm, || c ||^2]
  (- [Square ineq constraint norm, || c ||^2 if c > 0, 0 otherwise])

A classic quadratic task would then be a "square equality constraint norm" on an "equality constraint".
At any point in time we could convert this task into a constraint if needed, and vice-versa.
That would be useful also to transition on equality constraints activation by creating a task on it temporarily.

Note: this moves the question to whether y = f or y = 0 is the proper way to write an equality constraint. In the former we only need linear functions y := E.x, in the latter affine functions y := Ex +/- f...