You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The public API of a high-level interface to PRIMA can be one of the three:
Provide a single function prima, and make the individual solvers available with an option/argument solver (used in MATLAB) or method (used in SciPy).
Provide five individual solvers lincoa etc.
Provide both prima and the five individual solvers.
The Python binding takes 1, PRIMA.jl currently takes option 2, and the MATLAB interface chose 3, which is inherited from PDFO.
According to my 4-plus-year experience working on PRIMA and PDFO (the predecessor of PRIMA), 1 is ideal, 2 is OK, and 3 is wrong.
Let me first explain why option 3 is wrong: prima and lincoa correspond to two different abstraction levels, and hence it is radically wrong to expose both of them to the end users. For example, both prima and the user can call lincoa, which leads to unnecessarily complicated logic in the code. This is a bitter lesson learned from PDFO and the current MATLAB binding.
Option 2 is much better than option 3, because its logic is simpler. All the functions exposed to the end users in parallel to each other, lying on the same level of abstraction.
Option 1 is the best. It provides a simple and uniform interface to all solvers. It reduces the burden of maintaining the public API, which contains only one function. In addition, it avoids code repetition when we need to do preprocessing and postprocessing.
For these reasons, PDFO has deprecated calling the individual solvers directly, and it now supports only calling the solvers via the uniform interface called pdfo. The MATLAB binding of PRIMA will do the same, switching from option 3 to option 1.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
This is related to
#183
libprima/PRIMA.jl#29
The public API of a high-level interface to PRIMA can be one of the three:
prima
, and make the individual solvers available with an option/argumentsolver
(used in MATLAB) ormethod
(used in SciPy).lincoa
etc.prima
and the five individual solvers.The Python binding takes 1,
PRIMA.jl
currently takes option 2, and the MATLAB interface chose 3, which is inherited from PDFO.According to my 4-plus-year experience working on PRIMA and PDFO (the predecessor of PRIMA), 1 is ideal, 2 is OK, and 3 is wrong.
Let me first explain why option 3 is wrong:
prima
andlincoa
correspond to two different abstraction levels, and hence it is radically wrong to expose both of them to the end users. For example, bothprima
and the user can calllincoa
, which leads to unnecessarily complicated logic in the code. This is a bitter lesson learned from PDFO and the current MATLAB binding.Option 2 is much better than option 3, because its logic is simpler. All the functions exposed to the end users in parallel to each other, lying on the same level of abstraction.
Option 1 is the best. It provides a simple and uniform interface to all solvers. It reduces the burden of maintaining the public API, which contains only one function. In addition, it avoids code repetition when we need to do preprocessing and postprocessing.
For these reasons, PDFO has deprecated calling the individual solvers directly, and it now supports only calling the solvers via the uniform interface called
pdfo
. The MATLAB binding of PRIMA will do the same, switching from option 3 to option 1.Beta Was this translation helpful? Give feedback.
All reactions