About an year ago,
Raniere
started working on a interface for
CUTEst.
He decided to create ugly,
a repository for CUTEst, but following the Unix procedure for
building packages (./configure, make, make install).
Also with ugly, he wanted to enable building a shared library
to be used with Julia.
This approach worked, but maintaining it is troublesome,
since it would require updating and testing of ugly for every
update of CUTEst.
What I decided to do was find a way to create a shared library from a working CUTEst installation. This focuses on another principle: passing the blame, er, I mean, modularity. My package would simply take a working CUTEst and make a working shared library from it. It also served of downloading and installing a new CUTEst installation, since this would be required for testing. The work can be found at cutest-julia-installer.
The second thing Raniere worked was the interface itself, which is a module/package for Julia that enables building a problem from its name, retrieving its parameters, and using its mathematical functions (objective function, gradient, Hessian, constraints, Jacobian, and so on). I continued this work, changing the way the problem is built (to use my shared library), and translating the core functions to Julia. With these additions, the usual functions on CUTEst can be called with little change in Julia.
The next step is to facilitate the use of CUTEst functions
by creating higher-level interfaces.
So, instead of manually verifying if problem is
constrained or not, and then calling
cfn(st, n, m, x, f, c) or ufn(st, n, x, f),
to get the objective function value,
one might simply call
f = obj_fun(prob, x).
This should probably be slower,
if the user, for instance, ends up calling two functions
instead of one, but if it increases development time,
then it has server its purpose.