Preprocessing and postprocessing in PRIMA

[zaikunzhang]

• Preprocessing

  -- Preprocessing means validating the user's inputs, and defaulting parameters to proper values if the user does not specify them (correctly).
  -- You can simply understand it as "cleaning the inputs" before sending them to the solver.
  -- As an example, see preprima.m for the MATLAB implementation of the preprocessing. A complete and careful preprocessing takes more than 2000 lines of MATLAB code!

• Postprocessing

  -- Postprocessing means validating the solver's outputs, and putting them into the form that are the most useful to the user.
  -- You can simply understand it as "cleaning the outputs" before sending them to the user.
  -- As an example, see postprima.m for the MATLAB implementation of the postprocessing. A complete and careful preprocessing takes more than 800 lines of MATLAB code!

• The complication of preprima.m and postprima.m partially comes from the fact that the MATLAB interface exposes both prima and the individual solvers newuoa etc, which is a bad design inherited from PDFO. preprima and postprima need always remember "who is calling me" and "whom I am reporting to". I regret this design so much and I do not want it to happen again in any other language.

• More concrete examples of pre/postprocessing.

  -- Scaling the problem and unscaling it before returning the result. PRIMA.jl already does this, although without explicitly calling it preprocessing and postprocessing.

  -- Removing linear equality constraints. This is needed because the LINCOA algorithm (the mathematical one, not the code) expects all linear constraints to be inequalities. We need to rewrite a problem with constraints $A_1 x = b_1, A_2 x \le b_2$ to a problem with $A y \le b$ by a certain linear transformation $x = By$. Without doing so, LINCOA still works (by treating $A_1 x = b_1$ as two inequalities), but not in the most efficient way. See Section 4.3 of the PDFO paper. This is preprocessing, and it obviously necessitates postprocessing, as the solver returns the solution in terms of $y$, but the user expects $x$.

  -- Removing variables that are almost fixed by bound constraints (i.e., $l \le x \le u$ with $l \approx u$). This is needed by BOBYQA. This is another preprocessing that necessitates a corresponding postprocessing.

  -- Projecting the initial point to the feasible region for linearly constrained problems. See For bound-constrained and linearly constrained problems, project the starting point to the feasible region PRIMA.jl#10

  -- Wrapping up the objective and constraint functions to handle failures and abnormal returns properly. See Wrap the objective & constraint function evaluation and catch exceptions if any  PRIMA.jl#15

There are many many others ... I hope you get a feeling why pre/postprocessing needs more than 2000 lines of code.

The MATLAB interface has implemented all of these. The Python interface will implement them as well, mostly by inheriting what PDFO has done. Without doing so, the interfaces would only be half-baked (better than nothing). See again my post about what an interface is.

I do acknowledge that proper pre/postprocessing is nontrivial to implement. Hence other interfaces may not implement all of these. In that case, we essentially leave the pre/postprocessing to the user, which is not ideal, but better than nothing.